OD AUTORÓW

Skąd wziął się pomysł napisania książki o inżynierii wymagań? Dlaczego zajęliśmy się tematem tak pozornie oczywistym i niewymagającym głębszej analizy? Powody wynikają bezpośrednio z naszych doświadczeń projektowych, wskazujących na to, że wbrew pozorom inżynieria wymagań nie jest dziedziną prostą i oczywistą, w projekcie nie "zrobi się sama" i wymaga pewnego usystematyzowania oraz porządku. Można by zapytać, po co? Otrzymaliśmy od klienta wymagania (lub wydaje nam się, że je mamy), to wystarczy, by rozpocząć wytwarzanie produktu. Otóż nie do końca.

Wyobraźmy sobie następującą sytuację - planujemy budowę domu. Co robimy najpierw? Oczywiście ustalamy budżet, planowany czas odbioru itp. - określamy ograniczenia. Następnie definiujemy parametry domu - liczbę pięter, okien, pomieszczeń itd. Teraz zadajmy sobie pytanie - czy powyższe informacje wystarczą do zbudowania domu? Każdy rozsądnie myślący człowiek odpowie, że nie - potrzebny jest dokładny projekt. W innym przypadku mogłoby okazać się, że zaczynamy budowę od komina czy okien, ponieważ wydają się najłatwiejsze do wytworzenia. Możemy też zacząć od stawiania ścian i po pewnym czasie dojść do wniosku, że udały nam się one wspaniale, jednak zapomnieliśmy o fundamentach... Kuriozalne, prawda? Dla większości osób i z pewnością dla wszystkich inżynierów logiczne jest, że wytworzenie czegokolwiek wymaga analizy danych, jak również opracowania dokładnych założeń i kształtu projektu. Dlaczego więc zastosowanie takiego sposobu myślenia w przypadku oprogramowania nastręcza takie trudności? Oprogramowanie to też produkt, z reguły nawet bardziej złożony i skomplikowany niż inne typy produktów. Czemu tak często neguje się potrzebę zastosowania inżynierii wymagań w projektach informatycznych? Typową przyczyną takiego postępowania jest bezmyślne dążenie do oszczędzania czasu trwania i budżetu projektu kosztem prac analitycznych. Działanie takie przynosi szczególnie szkodliwe skutki, jeśli jest spowodowane brakiem znajomości dziedziny inżynierii wymagań i jej wpływu na prace projektowe oraz nieznajomością podstawowych zasad wytwarzania produktu.

Jakie są tego konsekwencje? Według wielu źródeł (np. Standish Group) najczęstszymi powodami niepowodzeń projektów są ciągłe zmiany wymagań wynikające ze zmieniających się celów klienta, brak definicji potrzeb klienta, wymagania niekompletnie udokumentowane lub niekompletne[1]. Problemy te wynikają w równej mierze z nieznajomości dziedziny, jak i pewnego rodzaju ignorancji przejawiającej się w upartym powtarzaniu błędów popełnionych przez inne organizacje, z wiarą, że "nam się uda". Częstym problemem jest również fakt, że w produkcję oprogramowania zaangażowane są wyłącznie osoby z podłożem technicznym, bez znajomości realiów biznesu, otoczenia klienta, jego rzeczywistych potrzeb. Takie osoby rzadko będą miały chęć, odwagę, potrzebę czy możliwość poznania realnych potrzeb klienta (nie informacji, co klientowi wydaje się, że chce otrzymać), a następnie ich systematycznego uszczegóławiania w trakcie często czasochłonnych uzgodnień i dyskusji. W przypadku wielu projektów osoby bezpośrednio odpowiedzialne za wymagania nie są odpowiednio przygotowane do pełnienia tych obowiązków i nawet mimo najlepszych intencji ciężko im sprostać postawionym wyzwaniom bez odpowiednich szkoleń, doświadczeń i wsparcia. Efekt takiego stanu rzeczy jest zapewne znany wszystkim Czytelnikom, a podsumować go można padającym ze strony klienta po przedstawieniu mu zbudowanego produktu stwierdzeniem - "to nie jest to, o co nam chodziło".

Inżynieria wymagań była i nadal pozostaje istotnym i aktualnym tematem w obszarze wytwarzania wielu produktów, w tym informatycznych, i oprogramowania. Jest to szczególnie widoczne w organizacjach, które - nauczone doświadczeniem ciągłego wytwarzania kolejnych produktów - zdały sobie sprawę z tego, że prawdziwy sukces nie jest możliwy bez zorganizowanej inżynierii wymagań.

Jeśli w procesie tworzenia oprogramowania zaniedbamy aspekt biznesowy (a takim jest inżynieria wymagań) oraz sprawną komunikację, to okaże się, że kwestie typowo techniczne mają drugorzędne znaczenie. Uporządkowanie stanu wiedzy w dziedzinie inżynierii wymagań oraz rozwijanie umiejętności analitycznych i nauka systematycznego podejścia do pracy z wymaganiami były głównymi przesłankami dla stworzenia tej książki, która ma być kompendium wiedzy dla osób zaangażowanych w procesy wytwarzania oprogramowania oraz zainteresowanych tematyką inżynierii wymagań.

Publikacja powstała dzięki spotkaniu dwóch osób zafascynowanych zagadnieniami inżynierii wymagań oraz wytwarzania oprogramowania. Jest rezultatem miesięcy cieżkiej pracy, sporów oraz wyjaśniania zagadnień, które były różnie definiowane i interepretowane w publikacjach specjalistycznych oraz przez ekspertów. Wynikiem tej współpracy jest książka opisująca proces i zagadnienia inżynierii wymagań oraz dostarczająca praktycznych przykładów, które pozwalają zrozumieć bardziej skomplikowane zagadnienia. Nie stanowi ona przeglądu wszystkich metod, technik i narzędzi wspierających inżynierię wymagań i nie taki były cel jej powstania. Zamiast opisywać niemal nieskończony zbiór środków wspomagających proces, skupiliśmy się na wyjaśnieniu samego procesu, jako że to proces inżynierii wymagań jest istotnym czynnikiem sukcesu przy wytwarzaniu produktu.

Warszawa-Szczecin, wrzesień 2014

Przypisy