Z drugiej strony, ta łatwość okazywała się niebezpieczna. Względnie nieskomplikowane algorytmy programów w latach 40. i 50., tworzone od początku do końca przez ludzi wybitnych, nawet laureatów nagrody Nobla, nie wymagały stosowania ani analizy biznesowej, ani inżynierii wymagań. Od tego czasu sytuacja zmieniła się diametralnie: wielomilionowej rzeszy twórców oprogramowania nie daje się już obsadzić geniuszami, a dla większości aplikacji oraz systemów IT o wiele ważniejsza jest ich zgodność z potrzebami biznesowymi niż stosowanie trudnych, matematycznych algorytmów. Dlatego od podejścia charakteryzującego lata 50. i 60. - od pojmowania tworzenia programów jako rzemiosła artystycznego, IT przeszło do nowej fazy - inżynierii oprogramowania. Ta faza trwa do dziś i niesie nas w przyszłość. Inżynieria wymagań jest jednym ze składników inżynierii oprogramowania.

W dziedzinie inżynierii wymagań widać odmienność między światem akademickim a realiami przemysłu IT.

W świecie akademickim określenie "inżynieria wymagań" (jako gałąź szeroko rozumianej inżynierii systemów oraz inżynierii oprogramowania) jest powszechnie znane. Najpoważniejsze czasopismo w tej dziedzinie - "Requirements Engineering Journal" - wydawane jest regularnie od 1996 r., a więc już od 17 lat. Jeszcze starsza jest konferencja: "IEEE International Requirements Engineering Conference", która odbędzie się w tym roku już po raz dwudziesty pierwszy. Historia i materiały ze wszystkich wcześniejszych konferencji, począwszy od roku 1993, znajdują się na portalu requirements-engineering.org.

Między analizą biznesową a oprogramowaniem

Ciekawe porównanie - największa w Europie konferencja na temat testowania oprogramowania, EuroSTAR, też po raz pierwszy odbyła się w 1993 r. w Londynie. W tym czasie testowanie stało się i modą, i biznesem: przykładowo, quasi-monopolistyczna organizacja ISTQB, działająca od 2003 r., chwali się dziś ponad dwustutysięczną armią osób mających tzw. certyfikat podstawowy testowania oprogramowania, podczas gdy analogiczna organizacja inżynierii wymagań, IREB, dopiero niedawno przekroczyła liczbę 10 tys. członków z certyfikatem podstawowym inżynierii wymagań.

A przecież kluczowe znaczenie inżynierii wymagań dla biznesu i dla IT wydaje się nie budzić najmniejszych wątpliwości. Przeszkoliwszy wiele tysięcy osób w zakresie testowania, w tym na niezmiernie popularny certyfikat ISTQB, autor tego artykułu wielokrotnie zetknął się z opiniami osób zajmujących się testowaniem, że źródłem wszelkich kłopotów, które skrupiają się na testerach i testowaniu, są niedostatki właśnie inżynierii wymagań. Zatem wiedza na ten temat istnieje w przemyśle IT, ale nie przekłada się na żadne działania. Czemu?

Wyjaśnienie, moim zdaniem, ma charakter bardziej antropologiczny i socjologiczny niż informatyczny. Nazwijmy je tak: górne obszary inżynierii wymagań zadomowiły się pod nazwą analizy biznesowej względnie wysoko w świecie organizacyjnych i korporacyjnych hierarchii; słusznie zresztą, bo trudno oczekiwać, że analizą biznesową będą się zajmować osoby z niewielkim doświadczeniem, bez całościowej wizji działania firmy.

Z drugiej strony, znów posłużę się ryzykowną nazwą, dolne rejony inżynierii wymagań zadomowiły się w świecie projektowania, architektury systemów, w niełatwych technicznie zagadnieniach modelowania, UML, DDD…

To, co pośrodku, taka czysta inżynieria wymagań, jakoś nie może dobić się uznania. Oczywiście, istnieje w rzeczywistości, bo magiczny, cudowny skok od wyników analizy biznesowej do diagramów UML ani tym bardziej do gotowego, działającego kodu, nie istnieje. Czyli zadania inżynierii wymagań wykonują kierownicy projektów, dbający, żeby produkt końcowy jakoś dał się wcisnąć odbiorcom; inżynierami wymagań są też członkowie zespołów agile, zwłaszcza "mistrzowie młyna".

Co dalej, czyli świt inżynierii

Szkolenia przygotowujące do certyfikacji IREB CPRE (Certified Professional in Requirements Engineering) będą za dwa, trzy lata szły jak świeże bułeczki. Na wyższych piętrach spopularyzują się certyfikaty IIBA oraz QAMP. W tej sytuacji wzrośnie rola polskiego oddziału IREB (www.ireb.org.pl). W Polsce okrzepnie Stowarzyszenie Inżynierii Wymagań (www.wymagania.org.pl). Przyczynić się do tego może konferencja "Dobre Wymagania 2013" (breq2013.wymagania.org.pl), która odbędzie się 18-19 kwietnia.

Opisywane w "Computerworld" wielokrotnie ADP (Automated Defect Prevention). jako metoda zarządzania projektami IT, stanie się czymś powszechnie stosowanym, oczywiście pod lepszą marketingowo nazwą. Skoro "chmura" jest już zajęta, to może inne duże zjawisko naturalne, np. "wulkan" albo "śnieżyca"? Ta metodyka za pięć czy dziesięć lat może stać się powszechna i usunąć z zarządzania projektami zarówno magię i szarlatanerię, jak i biurokrację, zamiast nich wprowadzając automatyzację czynności powtarzalnych i prostych, oraz śledzenie statusu projektu na podstawie wymagań.