Inżynieria wymagań wychodzi z ukrycia

Czająca się w zarządzaniu projektami

Zarządzanie projektem IT oznacza planowanie, monitorowanie i nadzór nad wysiłkami, służącymi do osiągnięcia konkretnego celu. Ponieważ ten cel określają i opisują wymagania, są one osią, wokół której zarządzanie projektami się obraca. Nic dziwnego, że elementy inżynierii wymagań wchodzą w skład wzorców zarządzania. Popularne standardy zarządcze, takie jak PMI i PRINCE 2, w znacznej części o niej właśnie mówią, co trafnie odzwierciedla fakt, że w projektach, w których inżynierii wymagań, jako osobnej aktywności pozornie nie ma, zwykle uprawiają ją właśnie kierownicy projektów.

Co w tym złego? Takie rozwiązanie sprawdza się do pewnego stopnia. W niewielkich projektach łączenie wielu ról przez jedną osobę jest pożądane, nawet konieczne: programista jest zarazem architektem i testerem, a kierownik projektu wykonuje obowiązki analityka systemowego oraz inżyniera wymagań. Jednak to ryzykowne rozwiązanie. Jeśli inżynieria wymagań kryje się pod innymi rolami, często prowadzi do jej zaniedbywania, do licznych błędów, niełatwych do wykrycia. Czasem łączenie ról kierownika projektu oraz inżyniera wymagań jest sposobem na pozorne zaoszczędzenie czasu i pracy, co skutkuje błędami i koniecznością późniejszych kosztownych przeróbek. Wiele typowych problemów w projektach IT bierze się z tego PM-centrycznego sposobu uprawiania inżynierii wymagań.

Ukryta w testowaniu

Jeśli testerzy nie znają wymagań, muszą je sami znaleźć lub się ich domyślać, co jest powszechną praktyką. Stąd bierze się popularne w kręgach testerów określnie: „Tester nie jest odkurzaczem” – forma bezsilnego, ironicznego protestu przeciwko temu, że testerzy zbyt często muszą naprawiać błędy popełniane przez innych. Istnieje nawet odrębna szkoła testowania, zwana testowaniem eksploracyjnym, obarczająca testerów zadaniami identyfikowania interesariuszy, znajdowania brakujących wymagań, domyślania się ukrytych założeń, a nawet priorytetyzacji potrzeb klienta. To rozpaczliwe rozwiązanie, mające uzasadnienie tylko w niektórych sytuacjach, powinno być nazywane po imieniu. Testowanie eksploracyjne jest swego rodzaju inżynierią wymagań stosowaną wstecz – nazywajmy je formą inżynierii wymagań, a nie nową filozofią testowania! Jest duże ryzyko, że testowanie eksploracyjne nie zdoła wykonać swoich obowiązków zastępczej inżynierii wymagań. Nawet w projektach, w których inżynieria wymagań jest dobrze realizowana, testowanie ponosi znaczną odpowiedzialność za wymagania. Między innymi kluczowy obszar testowania, czyli projektowanie testów, jest uzupełnieniem na wyższym poziomie szczegółowości zarówno pozyskiwania, jak i analizy wymagań.

Projektowanie testów oznacza określanie warunków (przypadków testowych), które oprogramowanie ma spełniać, a które nie są dokładnie opisane przez wymagania. Przykładowo, jeśli wymaganie określa, że w danym polu mogą być wprowadzane wyłącznie znaki literowe, wówczas projektowanie testów uzupełnia i rozszerza to twierdzenie o konkretne dane, głoszące, że w polu nie mogą znajdować się ani puste ciągi znaków, ani ciągi znaków z cyframi, spacjami, znakami kontrolnymi.

Nic w tym złego, przeciwnie, tak właśnie być powinno, tyle że mało kto zdaje sobie z tego sprawę, na czym cierpi zarówno inżynieria wymagań, jak i samo testowanie. Niezrozumienie powoduje błędy.

Wykonywana pod płaszczykiem metod zwinnych

Paradygmat agile to specyficzny, skuteczny, iteracyjny proces wytwarzania oprogramowania. Jeśli pominąć nowomowę agile i najzupełniej gołosłowne twierdzenie, że agile to nie tylko proces, ale cała nowa filozofia tworzenia oprogramowania, główną siłą i zaletą agile jest jego koncentracja na wymaganiach.

Rzeczywisty ogromny potencjał i realne sukcesy metod zwinnych biorą się stąd, że okazały się one skutecznym sposobem przełamania tradycyjnego sceptycyzmu, a nawet wrogości zarówno biznesu, jak i programistów wobec inżynierii wymagań. Agile wymusza staranną inżynierię wymagań.


TOP 200