Wymagania: IT w pigułce

Bogdan Bereza „Wymagania: IT w pigulce”
Wymagania: IT w pigułce
28 stycznia 1986 roku: w 73 sekundzie lotu promu kosmicznego „Challenger” nastąpiła eksplozja
– cała załoga zginęła. W komisji, badającej przyczyny katastrofy, uczestniczył między innymi
laureat Nagrody Nobla, słynny fizyk Richard Feynman. To jego przede wszystkim zasługą było
wykrycie przyczyny śmiertelnej awarii: uszczelki w silnikach pomocniczych nie działały
poprawnie w niskich temperaturach, o czym wprawdzie dobrze wiedzieli szeregowi pracownicy
projektu, ale ta wiedza jakoś nie dotarła to kadry zarządzającej, lub została przez nią
zignorowana.
1996: w wyniku błędu oprogramowania, misja 501 rakiety „Ariane 5” kończy się zaraz po starcie
efektowną eksplozją – na szczęście nikt nie zginął, ale z dymem poszło kilkaset milionów
dolarów.
Rok 2012: pawilon „Emilia” w centrum Warszawy, kupiony od miasta przez spółkę
deweloperską, zostaje – bez wiedzy kupujących – wpisany na listę zabytków, co dramatycznie
obniża wartość tej nieruchomości. Konserwator zabytków tłumaczy się, że „nie przyszło mu do
głowy” zawiadomić właściciela, zaś rzecznik Ministerstwa Kultury mówi: „nie było złej woli,
zabrakło procedur”.
Przyczyny pomyłek, błędów i awarii
Co mają ze sobą wspólnego te trzy, opisane powyżej, tak na pozór różne, historie? Temu
zagadnieniu poświęcona jest znakomita książka Dietricha Dörnera „The Logic of Failure”. Jest to
książka… psychologiczna o tym, jak ludzie systematycznie i spektakularnie mylą się, podejmują
złe i głupie decyzje, tak samo w IT, jak w administracji, w przemyśle, w rolnictwie. Pewnie to
prawda… tylko co nam, ludziom IT, z tej gorzkiej wiedzy? Cóż, dzięki niej mamy szansę przestać
się łudzić, że dobre wyniki projektów IT osiągnie się za pomocą natchnienia, uduchowienia,
intuicji albo najnowszego języka programowania o dziwacznej nazwie. Sorry, folks, niezbędne są
procedury – nie biurokracja i papierologia, ale elastyczne, sprawne i w miarę możliwości
automatyczne procedury, zabezpieczające nas przed skutkami naszych – w 100% ludzkich –
pomyłek.
Procedury, to nie kosztowny luksus, lecz wręcz przeciwnie – oszczędność. Dzięki nim wykryjemy
skutki ludzkich pomyłek – błędy – jak najwcześniej, kiedy ich usunięcie jest jeszcze względnie
tanie. Dzięki procedurom projekty będą przebiegały sprawniej, a programiści, testerzy i – co
najważniejsze – Klienci – będą szczęśliwsi. Jak piękny jest świat, kiedy nie musimy marnować
czasu i nerwów na borykanie się ze skutkami cudzych pomyłek, ani na maskowanie własnych!
Strona 1 z 9
Bogdan Bereza „Wymagania: IT w pigulce”
Inżynieria wymagań – splot słoneczny IT
Procedury, to jakby drogi, prowadzące nas jak najlepiej do celu. Pojemne określenie „jak
najlepiej” czasem oznacza autostradę, czasem wąską ścieżkę, czasem kolejkę linową, a czasem
nawet przedzieranie się z kompasem przez bezdroża – zależnie och celu.
Uwaga: w dwóch powyższych zdaniach dwukrotnie użyłem słowa „cel”. Cel trzeba znać, aby
wiedzieć, dokąd idziemy, ale również, aby wybrać jak najlepszą drogę, która tam – do celu –
prowadzi. Polecam małe ćwiczenie: wpisać w Google wyrażenie „definicja celu” i pooglądać
wyniki wyszukiwania. Cel, to wiedza o tym, co chce się zrobić, dokąd dojść, co zrealizować.
Cel, czyli wymagania wobec systemu IT. To nie jest popularna nazwa: częściej mówi się o
warunkach, o celach, założeniach, projektach, właściwościach. Zaś nazwa dziedziny wiedzy,
uczącej, jak znajdować, określać i skutecznie realizować cele – inżynieria wymagań – to już –
niestety! – zupełna rzadkość. Szukając na portalach pośrednictw pracy, znajdujemy oferty dla
analityków, sprzedawców, projektantów, programistów, nawet testerów! – ale ze świecą szukać
firmy, ogłaszającej potrzebę zatrudnienia inżyniera wymagań. Trochę lepiej wygląda to na
uczelniach, gdzie zdarzają się studia podyplomowe dla inżynierów wymagań.
Tymczasem inżynieria wymagań, to w istocie rzeczy dziedzina, obejmująca wszystkie kluczowe
dla powodzenia przedsięwzięć IT obszary, których nazwy atakują nas dziś ze wszystkich stron:
analizę biznesową, techniki sprzedaży, metodyki agile, metody zarządzania, technologie
programowania, sposoby testowania, i nawet prawo IT. Niepowodzenia projektów, zarówno IT,
jak innych, nieodmiennie wynikają z deficytów inżynierii wymagań, choć łatwiej nam mówić o…
pomyłkach prezesa Lato, bezmyślnych urzędnikach czy niestarannych programistach.
„Nie było złej woli – zabrakło procedur”, a procedury to wszakże drogi, prowadzące do celu,
czyli zabrakło umiejętności określenia celu i sposobów jego realizacji: zabrakło inżynierii
wymagań.
Analiza biznesowa, to właśnie inżynieria wymagań
Niby to samo, a jednak nie to samo: zależy, jak zdefiniuje się zakres obu pojęć. W praktyce,
analityk (analityk biznesowy), to osoba, która bada i opisuje (modeluje) procesy biznesowe, te
istniejące obecnie, jak i te, które chce się mieć w przyszłości. Na razie jakby niewiele ma to
wspólnego z informatyką? - tyle że w dzisiejszych czasach wszelkie zmiany procesów
biznesowych oznaczają albo zmiany istniejących systemów IT, albo wdrażanie nowych rozwiązań
IT, czyli analiza biznesowa to dyscyplina na wskroś informatyczna.
Z punktu widzenia inżynierii wymagań (pojęcie stosowane wyłącznie w IT, podczas gdy analiza
biznesowa jest określeniem używanym w wielu branżach), analiza biznesowa to albo pierwszy
etap inżynierii wymagań, albo proces ją poprzedzający, źródło wiedzy dla tak zwanego procesu
pozyskiwania wymagań.
Często spotyka się opisy, gdzie nazwa „inżynieria wymagań” w ogóle nie występuje: następnym
krokiem po analizie biznesowej jest projektowanie systemów (czasem między nimi pojawia się
Strona 2 z 9
Bogdan Bereza „Wymagania: IT w pigulce”
jeszcze analiza systemowa). Nieważne są nazwy – problem w tym, że jakże często chaos w
nazewnictwie sprzyja chaosowi w projektach:
Analiza
biznesowa
A miracle
happens…
Projektowanie
systemu
Jak przemysł IT często widzi proces oprogramowania
Ponieważ jednak cuda zdarzają się nieczęsto, skutkiem takiego podejścia informatycy –
projektanci, architekci, programiści – słabo orientują się, co właściwie mają skonstruować.
Przykłady w obfitości każdy znajdzie we własnym doświadczeniu, a ponadto w komiksach
Dilberta…
Oto, jak naprawdę wyglądają relacje między analizą biznesową, inżynierią wymagań i
projektowaniem:
Inne
wymagania
biznesowe
Analiza
biznesowa
Pozyskiwanie
wymagań
Inżynieria
wymagań
(proces
wymagań)
Projektowanie
systemu
Wymagania
techniczne
A tak jest naprawdę – nawet jeśli te procesy inaczej się nazywają!
Sprzedaż, to – o dziwo! - inżynieria wymagań
Aż w głowie się kręci, tyle jest rozmaitych teorii sprzedaży, metod sprzedaży, technik sprzedaży i
szkoleń dla sprzedawców! Z lewej strony naciera marketing i zagadnienia tworzenia marki, z
prawej – techniki sprzedaży, z dołu – reklama, a z góry – zarządzanie doświadczeniem klienta1.
1
Customer Experience Management (CEM).
Strona 3 z 9
Bogdan Bereza „Wymagania: IT w pigulce”
I wszędzie powtarzane jest jak mantra: poznać potrzeby klienta, odkryć potrzeby klienta,
stworzyć nowe potrzeby klienta, ukierunkować potrzeby klienta na swój produkt,
zidentyfikować ukryte – autentyczne – długofalowe potrzeby klienta…
Czy chodzi o proszek do prania, samochód, film, biuro podróży czy system komputerowy2, sedno
sprawy to wykryć, zrozumieć, opisać i przełożyć na język operacyjny wykonanie produktu czy
usługi, które będziemy realizować i z zyskiem sprzedawać. Czyli innymi słowy, sprzedaż to w
gruncie rzeczy forma inżynierii wymagań, a psychologiczne zagrywki, potrzebne do złapania
klienta, wykładane na szkoleniach sprzedawców jako wiedza tajemna, omawia się na kursach
analizy biznesowej oraz inżynierii wymagań pod skromną nazwą technik pozyskiwania
wymagań. Inna rzecz, że tradycyjna inżynieria wymagań też mogłaby się niejednego nauczyć od
marketingu oraz reklamy: a dlaczego niby nie robić spotkań JRP przy muzyce i występach dobrze
zbudowanych tancerzy płaci obojga!? 
Niech jednak lepiej zostanie, tak jak jest – bo bez tej otoczki czarnej magii, NLP, freudyzmu i
guślarstwa, dostawcy szkoleń dla sprzedawców poszliby wkrótce z torbami! Ale czytelnicy tego
artykułu niech wiedzą, jak jest naprawdę.
Metodyki agile, to - wbrew mitom - inżynieria wymagań
Wymagania kojarzą się wielu osobom z opasłymi, zakurzonymi - fizycznym lub wirtualnym
kurzem - tomami dokumentacji, której nikt nie czyta, która zawsze jest nieaktualna,
niepotrzebna i nieczytelna, oraz z paraliżującą biurokracją.
Natomiast metodyki zwinne – agile, extreme programming, TDD – same już nazwy brzmią
radośnie, luzacko, nowocześnie!
Lecz to tylko przesądy. Podobnie jak nie każdy homoseksualista jest wesoły (gay), a nie każdy
heteroseksualista jest ponurym katoendekiem, tak samo porządna inżynieria wymagań nie musi
być przygnębiającym nudziarstwem, zaś metody agile nie tylko nie obywają się bez inżynierii
wymagań – one są wręcz częścią inżynierii wymagań!
Co wykryli i ogłosili światu sygnatariusze Manifestu Agile (www.agilemanifesto.org)? Otóż
odkryli proste i w gruncie rzeczy dobrze znane, choć powszechnie ignorowane zasady inżynierii
wymagań i zarządzania projektami, a mianowicie:

Wymagania są zwykle zmienne (często – ogromnie zmienne!) i potrzebny jest sprawny,
elastyczny proces zarządzania tymi zmianami;

Klienci – użytkownicy często nie są w stanie od początku zdefiniować i jednoznacznie
określić swoich potrzeb oraz wymagań, a skuteczną metodą, jak im pomóc, jest
2
W gruncie rzeczy chodzi o to samo, bowiem produkcja i dystrybucja proszku do prania, funkcjonalność
samochodu, produkcja i dystrybucja filmu oraz logistyka biura podróży realizowane są w 90% przy
pomocy systemów IT.
Strona 4 z 9
Bogdan Bereza „Wymagania: IT w pigulce”
prototypowanie: tworzenie dla nich małych fragmentów funkcjonalności, które ułatwiają
klientom odkrycie, czego tak naprawdę chcą;

W takiej sytuacji, próby kurczowego trzymania się modelu kaskadowego cyklu wytwarzania
oprogramowania, oraz próby szczegółowego opisania wymagań zanim przystąpi się do
tworzenia kodu, są nieskuteczne i szkodliwe.
Oto cała koncepcja agile w pigułce, a reszta – humanistyczna frazeologia („ludzie są ważniejsi niż
dokumentacja”), rozmaite rytuały (np. programowanie parami) oraz ostentacyjnie dziwaczna
terminologia (np. „młyn” i „przebieg” w terminologii agile scrum) – to tylko szczegóły.
Podsumowując – metodyki zwinne przyniosły IT cenne odkrycie, że wymagania można i niekiedy
ogromnie warto odkrywać (pozyskiwać) przy pomocy prototypowania i bardzo częstych
kontaktów z klientem; że dobrą definicją wymagania może być czasem zaakceptowany przez
klienta kawałek kodu, a nie pracochłonny opis, który rozmija się z rzeczywistymi potrzebami
użytkowników. Znakomicie! – tylko niech nikt nie twierdzi, że podejście agile eliminuje
inżynierię wymagań, skoro jest przeciwnie – metody zwinne wprowadzają inżynierię wymagań
w procesy projektowania i programowania w znacznie większym stopniu, niż odważały się
metody tradycyjne!
Zarządzanie projektami, to nic innego, jak inżynieria
wymagań
PRINCE-2, PMI, zarządzanie projektami, przez cele, procesowe, humanistyczne, zasobami
ludzkimi – wow! Wielki świat, pełen wypasionych metodyk, monopoli, guru, mistrzów, szkół,
certyfikatów, trzyczęściowych garniturów, NLP, BMW i nawiedzonych przywódców!
A jednak… spróbujmy przyjrzeć się dokładnie: a nuż król jest nagi?
Zarządzanie projektami to:
1. Określenie, co jest celem projektu;
2. Oszacowanie pracochłonności projektu;
3. Identyfikacja zadań do wykonania, przydzielenie ich ludziom i budowa harmonogramu;
4. Nadzorowanie przebiegu projektu, jego statusu, zgodności z harmonogramem i
podejmowanie działań zaradczych, kiedy projekt zaczyna się walić.
Teraz spójrzmy na te zadania z perspektywy inżynierii wymagań.
1 – określenie celu – to jest inżynieria wymagań w 100%;
2 – oszacowanie pracochłonności – to zestaw metod, pozwalających na podstawie wymagań
szacować pracochłonność ich realizacji; klasycznym przykładem jest np. analiza punktów
funkcyjnych;
Strona 5 z 9
Bogdan Bereza „Wymagania: IT w pigulce”
3A – identyfikacja zadań, to podział wymagań głównych (nadrzędnych) na mniejsze, cząstkowe;
3B – przydzielenie zadań i harmonogramowanie nie należą – przyznaję - do inżynierii wymagań,
ale ich wyniki przekładają się na atrybuty wymagań (np. czas wykonania, osoba odpowiedzialna
za realizację wymagania);
4 – nadzorowanie, to określanie statusu (stopnia) realizacji poszczególnych wymagań.
Celem powyższego wywodu nie jest udowadnianie naciąganej tezy, że inżynieria wymagań oraz
zarządzanie projektami to w 100% jedno i to samo – bo tak nie jest. Należy jednak koniecznie
zrozumieć, że te dwa procesy są ze sobą ogromnie powiązane, w związku z czym nie ma –
cokolwiek twierdzą modne teorie i VIP-certyfikaty dla kierowników projektów – nie ma dobrego
kierowania projektem bez zaangażowania się w inżynierię wymagań!
Każdy zaś kierownik projektu, który bawi się w wielkiego lidera, nie dbając o wymagania
(„Umiecie przecież sami napisać program! Czy trzeba was prowadzić za rączkę? Klient nie ma
czasu określić swoich wymagań!”), tylko pozoruje kierowniczą pracę i przynosi więcej szkody niż
pożytku.
Programowanie, to też inżynieria wymagań
Jeśli programowania, to inżynieria wymagań, czy wobec tego wbijanie gwoździ lub układanie
cegieł, to architektura czy wręcz biznesplan dla nowego wieżowca?
I tak, i nie. Oczywiście, czynności wykonywane przez osobę trzymającą młotek lub kielnię, są
dramatycznie odmienne od czynności, wykonywanych przez osoby pracujące w z
modelowaniem biznesowym w MS Excel, lub przy pomocy CAD architekta. Niemniej, w dobrze
zorganizowanym projekcie każde uderzenie młotka i położenie każdej cagły powinny wynikać
precyzyjnie z wcześniejszej dokumentacji, z projektu architektury, z wymagań – w przeciwnym
razie zagrożenia projektu są ogromne.
Sytuacja w IT jest o tyle szczególna, że podczas gdy w budownictwie nie ma szans na
zbudowanie gmachu przy pomocy samych murarzy, bez planistów i architektów, o tyle w IT w
jakimś sensie daje się to zrobić – tyle że znacznie gorzej i znacznie drożej. Co więcej,
kompetencje planisty, architekta, operatora dźwigu i murarza to zupełnie różne światy,
natomiast między inżynierem wymagań, projektantem i programistą nie ma aż tak dużych
różnic.
Stąd bierze się wiele chronicznych problemów IT. Pokusa pisania kodu na łapu-capu jest wielka –
program, w przeciwieństwie do mostu, można poprawiać wielokrotnie, nawet po
widowiskowym zawaleniu się – i za uleganie tej pokusie przychodzi nam nieraz drogo płacić.
Strona 6 z 9
Bogdan Bereza „Wymagania: IT w pigulce”
Testowanie, to po prostu inżynieria wymagań
Testowanie, to kontrola, czy to, jak jest, zgadza się z tym, jak ma być. Na przykład, czy aplikacja
poprawnie dodaje albo steruje urządzeniem, czy dokument zgodny jest ze swoim celami z
dokumentami źródłowymi, czy funkcja pomocy w programie wyświetla właściwe informacje.
Skąd jednak wiadomo, jak ma być? To jest właśnie zapisane w wymaganiach! Doprawdy? –
zaoponuje ktoś.To jakim cudem odbywa się testowanie w tysiącach projektów, gdzie wymagania
są niepełne, błędne, niespójne, nigdzie nie zapisane?
Cóż, wtedy albo testowanie jest najzupełniej bezcelowym marnowaniem czasu (skoro każdy
wynik testu daje się na siłę wyinterpretować jako „w zasadzie poprawny”…), albo brakujące
wymagania de facto zdobywa się podczas testowania. Testerzy domyślają się, jaki ma być
zgodny z niezapisanymi wymaganiami wynik oczekiwany. Czasem domyślają się dobrze, czasem
źle, często – inaczej niż programiści, czasem – inaczej niż użytkownicy. Jest nawet cała, modna
szkoła „testowania eksploracyjnego”, która uczy, jak kreatywnie domyślać się, mimo braku
wymagań, co jest OK, a co nie jest, lub niestandardowo zdobywać wymagania ze starych
manuali, z rozmów przy piwie, w saunie… Pięknie, ale czasochłonnie, drogo… i nie zawsze
skutecznie.
Prawnicy, to zamaskowani inżynierowie wymagań
7 marca 2008 roku zorganizowaliśmy 1-dniową konferencję „SoftLex – prawne aspekty inżynierii
oprogramowania”. Okazało się wtedy, jak liczne są podobieństwa – mimo wielkich różnic
terminologii – podejścia prawników, inżynierów wymagań oraz testerów projektujących testy
akceptacyjne.
Kontrakt na „wdrożenie systemu” (tak w języku prawniczym nazywa się budowa systemu na
zlecenie) określa warunki, które muszą być spełnione, aby zadanie dostawcy uznać za
wykonane. Propozycja jednego z dostawców, opisania warunków odbioru systemu zdaniem
„oprogramowanie w zasadzie będzie działać”, skontrowana przez prawnika strony zamawiającej
propozycją, że w tej sytuacji zamawiający „w zasadzie zapłaci za aplikację”, okazało się
niedostatecznie precyzyjne…  Jednym słowem, zrozumienie podstaw inżynierii wymagań orzez
prawników i podpisujących kontrakty menedżerów jest potrzebne.
Nauka i certyfikacja inżynierii wymagań
Zasad inżynierii wymagań oraz analizy biznesowej można się nauczyć. Istnieje szereg kursów
uczących konkretnych metod modelowania tak procesów biznesowych, jak i wymagań (m.in.
popularne UML), ale tutaj podamy kilka znanych na świecie certyfikacji ogólnych,
wykraczających poza jedną technikę.
Strona 7 z 9
Bogdan Bereza „Wymagania: IT w pigulce”
IREB – Intenational Requirements Engineering Board
Certyfikaty inżynierii wymagań oferuje międzynarodowa organizacja IREB (www.ireb.org).
Polska gupa działaczy IREB (www.ireb.org.pl) zajmuje się promocją wiedzy na temat inżynierii
wymagań w Polsce i udostępnieniem sylabusów oraz egzaminów na certyfikaty IREB po polsku.
W tej chwili na świecie certyfikaty IREB oferowane są w sześciu językach, w wielu krajach
Europy, Ameryki oraz Azji. Certyfikat podstawowy – CPRE Foundation Level – ma dziś na świecie
10.000 osób. IREB oferuje także certyfikaty zaawansowane (Advanced Level).
Listę firm prowadzących szkolenia przygotowujące do egzaminów na certyfikaty IREB można
znaleźć na www.ireb.org (zakładka „Training”), zaś firmy szkoleniowe w Polsce na
www.ireb.org.pl/szkolenia.
QAI – Quality Assurance Institute
QAI Software Certifications (www.softwarecertifications.org) oferuje dwa ciekawe certyfikaty:

CABA – Certified Associate Business Analyst

CSBA – Certified Software Business Analyst
IIBA – International Institute of Business Analysis
IIBA (www.iiba.org) także ma dwa poziomy certyfikacji:

CCBA – Certification of Competency in Business Analysis

CBAP – Certified Business Analysis Professional
Opisy tych certyfikacji ma na swojej stronie po polsku IIBA Warsaw Chapter
(www.warsaw.iiba.org) – polska organizacja IIBA.
Zapraszamy do tańca!
Konferencja poświęcona inżynierii wymagań i analizie biznesowej Dobre Wymagania
(breq2013.wymagania.org.pl) odbędzie się 18-19 kwietnia 2013 w Warszawie.
Jak to było z testowaniem? W roku 2000 mało kto w Polsce słyszał o testowaniu – to znaczy,
testowano oczywiście, ale testowanie nie było postrzegane jako odrębna specjalność, nie
istniały szkolenia dla testerów. Tematyka testowania pojawiła się po raz pierwszy na konferencji
KKIO w 2000 roku, potem na konferencjach zorganizowanych przez autora artykułu we
współpracy z IIR w 2002 i 2003 roku. Ruszyły pierwsze w Polsce szkolenia na tzw. certyfikaty
ISEB (dziś ISTQB), w 2003 roku założono stowarzyszenie testerów SJSI. Dziś testowanie w Polsce
staje się big business.
Tak samo będzie – z mniej więcej 10-letnim opóźnieniem – z inżynierią wymagań! Za 10 lat, w
2022 roku, trudno będzie sobie wyobrazić, że kiedyś „inżynier wymagań” był niemal nieznanym
zawodem. Dlatego serdecznie zapraszamy wszystkich zainteresowanych na zebranie
Strona 8 z 9
Bogdan Bereza „Wymagania: IT w pigulce”
założycielskie SIW – Stowarzyszenia Inżynierii Wymagań (wymagania.org.pl), które odbędzie się
we czwartek, 24 stycznia 2013 roku w Warszawie (enter.wymagania.org.pl).
Bogdan Bereza, [email protected]
Strona 9 z 9