Inżynieria wymagań to określenie, które odnosi się nie tylko do projektów IT. Choć samo pojęcie inżynierii wymagań jest stosunkowo nowe, to kłopoty, jakie powoduje lekkomyślne traktowanie wymagań, czyli niestosowanie zasad inżynierii wymagań, znane są od wieków.

Toną statki i projekty

10 sierpnia 1628 r. przewrócił się i zatonął, kilkanaście minut po odbiciu od nadbrzeża, nowo zbudowany okręt flagowy marynarki szwedzkiej "Wasa". Przyczyny? Okręt z powodu ambicji króla był potężniejszy niż inne ówczesne jednostki - dwupokładowy. Takie było życzenie króla, któremu nikt nie ośmielił się przeciwstawić. Tu od razu nasuwa się całkiem współczesna wątpliwość, czy na pewno klient ma zawsze rację? Dwupokładowy okręt miał znacznie wyżej środek ciężkości i okazał się przez to niezwykle wywrotny. Analiza biznesowa wskazała wprawdzie, że potrzebne są dwa pokłady z działami, ale zbyt szybko przeskoczono od potrzeby biznesowej do jej implementacji - budowy kadłuba. Zaniedbano etapy pośrednie: inżynierię wymagań, która m.in. zajmuje się takimi ich atrybutami, jak wykonalność (feasibility) oraz projektowanie: nie umiano wówczas precyzyjnie wyliczyć stabilności statku na podstawie informacji o jego wymiarach i rozkładzie ciężaru. Zastosowano metodę, którą można nazwać mega-agile: po prostu pracowici cieśle-programiści dobudowali jeszcze jeden pokład, zgodnie z życzeniem zleceniodawcy-króla!

Tak popełniono kardynalny błąd już w początkowej fazie projektu. Wynika on z powszechnego i wtedy, blisko 400 lat temu, i dzisiaj podejścia "po co marnować czas na jakiś SRS, bierzmy się do roboty".

Kiedy projekt popada w kłopoty - albo wręcz, jak "Wasa", kończy się spektakularną klęską - zwykle przyczyn szuka się wszędzie, tylko nie w braku inżynierii wymagań. Cichutko, bo wtedy jeszcze nie zniesiono kary śmierci, obwiniano króla-zleceniodawcę i jego idiotyczne pomysły. Ktoś powie: z takich pozornie idiotycznych pomysłów biorą się wielkie sukcesy biznesowe, zgodnie z zasadami strategii błękitnego oceanu. Owszem, tylko trzeba umieć sobie z nimi radzić. Na przykład stosując inżynierię wymagań.

Obwiniano też głównego konstruktora, Henrika Hybertssona. Gdyby statek zatonął choćby pół roku później, Hybertsson zbierałby pochwały. Ocena kierowników projektów zawsze jest przeraźliwie krótkowzroczna, oparta na pozornym sukcesie albo na równie pozornej, byle spektakularnej, klęsce.

Jak zwykle, obwiniano też procedury testowania. Ale testy przeprowadzono. Stabilność kadłuba sprawdzano w ten sposób, że gromada kilkuset robotników stoczni biegała po pokładzie z jednej strony na drugą, próbując rozkołysać kadłub. W przypadku "Wasy" testy przerwano, gdyż kadłub zaczął się kołysać zbyt niebezpiecznie, grożąc wywrotką. Króla zaś nie zawiadomiono, bo… obawiano się jego gniewu.

No i oskarżano Polaków, bo to z nami głównie wojował król Gustaw II Adolf. Polski sabotaż był więc wyjaśnieniem.

Sam król, nakazując śledztwo, wskazał jako przyczynę awarii "głupotę i niedbalstwo". Bingo, proszę króla! Budując wielkie, skomplikowane rzeczy, ludzie z definicji są głupi, bo rozum niewsparty narzędziami nie radzi sobie z nimi, zaś niedbalstwo jest naszą cechą przyrodzoną - geny pieczołowitości i staranności wyginęły dawno temu, stając się pokarmem tygrysów szablastozębnych, przed którymi nasi przodkowie nie uciekali, zajęci regułami i rytuałami. Wiedząc o tym, wprowadzamy procesy i procedury, które tę staranność gwarantują. Albo ich nie wprowadzamy bądź nie przestrzegamy, wtedy albo tonie "Wasa", albo projekt IT kończy się klęską. Można powiedzieć, że pod pewnymi względami inżynieria wymagań jest bardzo stara.

Programistyczny pięściak

Pięściak albo inaczej tłuk pięściowy wykonywano z twardego krzemienia. To oznacza, że nasz jaskiniowy prapraprzodek w swoim interesie musiał realizować trochę inżynierii wymagań, żeby jego wielodniowe wysiłki nie poszły na marne. Źle wykonany pięściak trudno było przerobić na coś innego.

W latach 40. i 50. ubiegłego wieku nauczyliśmy się wytwarzać pięściaki z miękkiego krzemu zamiast krzemienia. Sam krzem, pierwiastek, nie jest specjalnie użyteczny, ale w układach scalonych i budowanych z nich komputerach - jak najbardziej. Komputery umożliwiają wykonywanie oprogramowania, które można modyfikować i przerabiać o wiele łatwiej i taniej niż krzemienne pięściaki czy budowane z drewna żaglowce. Oferowana przez oprogramowanie łatwość robienia nowych rzeczy i ich zmieniania jest podłożem olbrzymiego skoku cywilizacyjnego, jaki zanotowaliśmy właśnie od lat 50. zeszłego wieku.