Inżynieria wymagań wychodzi z ukrycia

Chociaż pochłania nawet 40% zasobów każdego projektu i decyduje o jego powodzeniu, to czasem słyszy się o analizie biznesowej, ale nie o inżynierii wymagań.

Inżynieria wymagań wychodzi z ukrycia

Nie jest łatwo znaleźć osoby mające na wizytówce słowa „inżynier wymagań”. Mimo to inżynieria wymagań istnieje, a nawet – biorąc pod uwagę ogromną rolę, jaką oprogramowanie odgrywa we współczesnym świecie – jest dość dobrze realizowana w wielu projektach. Dzieje się to w jakiś niejawny sposób, bo na powierzchni jej nie widać. Na czym polega ta zagadka i jakie są jej konsekwencje?

Obserwacja

Zdecydowana większość projektów IT kończy się względnym powodzeniem. To byłoby niemożliwe, gdyby w tych projektach zabrakło inżynierii wymagań. W czym się ona przejawia?

Istnieje wiele dowodów, wprawdzie anegdotycznych, że inżynieria wymagań jest uprawiana w ramach działań projektowych, wykonywanych przez osoby mające zupełnie inne tytuły niż inżynierowie wymagań. Częściowo to kwestia nazewnictwa. Szukając w sieci frazy „requirements engineering”, dostajemy około 150 mln wyników, podczas gdy przy „business analysis” otrzymuje się 1,2 mld. Podobne procentowo, choć liczbowo niższe wyniki uzyskamy w polskich źródłach.

Ponieważ analiza biznesowa stanowi tylko część inżynierii wymagań, to odwrócenie proporcji zadziwia, chyba że powszechne, i po angielsku, i po polsku, jest jakieś dziwne rozumienie obu tych określeń. Szukajmy dalej. Łączna liczba certyfikatów testowych ISTQB oraz QAI przekracza znacznie 400 tys., podczas gdy certyfikatów IREB, najważniejszych w świecie inżynierii wymagań, wydano nieco ponad 13 tys. Czyżby projekty potrzebowały 30-krotnie więcej testerów niż specjalistów wymagań? To niemożliwe, a więc specjaliści wymagań ukrywają się pod innymi tytułami.

Tę sytuację znamy dobrze sprzed 30 lat, gdy podobnie pozornie nie było testerów, bo ukrywali się jako programiści, integratorzy, użytkownicy. Potem to się zmieniło. Pora na wyjście z ukrycia inżynierii wymagań.

Założenia

Inżynieria wymagań ukrywa się nie w jednym, a we wielu miejscach. W końcu standard inżynierii wymagań ISO/IEC/IEEE 29148 nie bez powodu nazywa inżynierię wymagań dziedziną interdyscyplinarną. W jej skład wchodzą zagadnienia z socjologii, psychologii, prawa, zarządzania projektami oraz informatyki. Widać więc wiele miejsc, gdzie inżynieria wymagań może się ukryć pod mylącymi pseudonimami.

Ukryta wśród programistów

Spotkałem niejeden zespół programistów głoszący: jesteśmy tak dobrzy, że niepotrzebna nam żadna inżynieria wymagań – po prostu sami wiemy albo umiemy się domyślić, co ma być zrobione.

To, co osiągają takie zespoły, aby odnieść sukces, to pełna samowystarczalność. Koszt – mniej efektywne działanie. Sami rozmawiają z klientami i użytkownikami, czytają starą dokumentację albo wykorzystują swoje wcześniejsze doświadczenia. Wymagań można się też domyślać, stworzyć je w wyniku burzy mózgów, zrealizować je metodą prób i błędów. Jednym słowem, takie zespoły przeprowadzają pozyskiwanie wymagań, ich analizę i walidację, zarządzanie zmianami, a wszystko to niemal podświadomie – podziwu godne osiągnięcie! Nie jest to dobry sposób pracy.

Dla wielu programistów takie działanie stało się wręcz natręctwem. Nudno brzmiącą inżynierię wymagań ukrywają za połyskliwą fasadą skrótów i dynamicznie brzmiących przymiotników. Jest XP (oczywiście, „ekstremalne”), TDD, FDD, BDD i ATDD… Wszystko to dobre metody, tyle że ich zalety nie biorą się ani z ekstremalności (cokolwiek ona znaczy), ani ze stosowania języka Java, ani nie z modnych narzędzi testowych o fascynujących warzywnych nazwach (np. Cucumber), tylko z tego, że postępują według dobrych, starych zasad inżynierii wymagań: określania dostatecznie precyzyjnych wymagań z góry, ścisłego powiązania struktury wymagań z architekturą systemu, wreszcie z zastosowania systematycznej walidacji samych wymagań i ich realizacji, poprzez prototypowanie.


TOP 200