Inżynieria wymagań jako uzupełnienie kompetencji testerskich

Inżynieria wymagań coraz częściej pojawia się jako propozycja poszerzenia kompetencji testera oprogramowania – alternatywna, mniej oczywista ścieżka rozwoju kariery niż automatyzacja. Tester jest jednym z zawodów, w którym im szerszą wiedzę z różnych obszarów posiadamy, tym lepiej. Często zdarza się, że testerzy na co dzień pracują z wymaganiami projektowymi: muszą walidować nie tylko wyniki pracy programistów, ale również właśnie wymagania. Dlatego też podstawowa wiedza z obszaru inżynierii wymagań może być dla nich bardzo przydatna. Z tego artykułu dowiecie się jakie są podstawowe obszary i zagadnienia inżynierii wymagań oraz dlaczego warto zgłębić tę wiedzę.

Czym jest inżynieria wymagań i czym się zajmuje?

Aby zrozumieć czym jest inżynieria wymagań należy najpierw poznać kilka kluczowych dla niej pojęć. Wymaganie to w skrócie potrzeba interesariusza. Przekłada się ona na to, co system musi robić albo jaką mieć właściwość aby osiągnąć dany cel interesariusza.  Z kolei interesariusz to po prostu osoba, grupa osób lub organizacja, która może wywierać wpływ na projekt, bądź być pod jego wpływem. Jest to więc nie tylko klient, ale także na przykład pracownicy firmy klienta lub kierownicy działów. To prowadzi nas do tego, czym jest sama inżynieria wymagań. Otóż, jest ona podejściem do zarządzania wymaganiami. Głównymi działaniami wchodzącymi w jego skład są: pozyskiwanie wymagań, ich dokumentacja, walidacja, oraz negocjowanie w razie konfliktu, a także zarządzanie wymaganiami podczas trwania całego projektu. Zadania inżynierii wymagań to zebranie i utrzymywanie celów oraz wymagań. Mogą one pochodzić z różnych źródeł. Ważne jest aby wymagania były kompletne oraz dobrze odzwierciedlały oczekiwania klienta.

Dlaczego inżynieria wymagań jest ważna?

Bardzo wiele błędów projektowych powstaje już na etapie zbierania wymagań. Koszty ich późniejszego naprawienia mogą okazać się bardzo wysokie, a czas projektu może się wydłużyć. Jeśli założenia od początku będą błędne, w efekcie powstanie produkt, który finalnie nie spełni oczekiwań klienta. Dlatego ważne jest, aby już na samym początku projektu przeprowadzić dokładną analizę wymagań oraz doprecyzować te niejasne i niepełne z nich.  Jedną z przyczyn późniejszych błędów w wymaganiach jest założenie, że wiele spraw to oczywistości, niewymagające wyjaśniania i precyzowania. Niestety, wydające się nam oczywistym wyrażenie może dla klienta oznaczać zupełnie inne rzeczy lub być używane przez niego w zupełnie innym kontekście – wszystko to może prowadzić do nieporozumień i błędów w implementacji. 

Komu przyda się wiedza z obszaru inżynierii wymagań?

Wbrew pozorom będzie ona przydatna nie tylko analitykom biznesowym i systemowym, ale również wszystkim osobom odpowiedzialnym za tworzenie dokumentacji projektów IT. Inżynieria wymagań jest więc dobrą okazją do poszerzenia kompetencji zarówno dla osoby zarządzającej projektem jak i testera oprogramowania – on też często pracuje z dokumentacją oraz ją tworzy (np. poprzez tworzenie przypadków testowych). Dodatkowo, jeśli tester został włączony w projekt już na jego wczesnym etapie, może on testować nie tylko sam system, ale również wymagania i dokumentację. Pomaga to zapobiegać późniejszym błędom w wymaganiach, które jak wiemy mogą być bardziej kosztowne.

Jakie cechy osobowości pomagają w inżynierii wymagań?

Cechy przydatne na stanowisku inżyniera wymagań są częściowo podobne do cech, które powinien posiadać tester. Jedną z najważniejszych jest umiejętność analitycznego myślenia. Ważne są różne umiejętności miękkie, takie jak: umiejętności komunikacyjne, empatia oraz zdolność rozwiązywania konfliktów, a także umiejętność mediacji i zdolność przekonywania. Inżynieria wymagań jest więc dobrym kierunkiem rozwoju dla testera oprogramowania, ponieważ z dużym prawdopodobieństwem sprawdzi się również w tym obszarze.

Wyzwania inżynierii wymagań

Przyjrzymy się teraz głównym problemom, które pojawiają się podczas etapu pozyskiwania wymagań oraz możliwościom ich rozwiązania, jakie oferuje inżynieria wymagań. Jedną z przyczyn błędów powstałych w wymaganiach jak i tworzonych rozwiązaniach jest założenie, że wiele kwestii i zagadnień jest oczywistych i nie ma potrzeby ich wyjaśniania czy precyzowania. W rzeczywistości jednak to samo wyrażenie używane nawet w obrębie jednej organizacji może być rozumiane w różny sposób przez poszczególne osoby/działy. Nieporozumienia odnośnie pojęć mogą powodować poważne błędy na późniejszych etapach projektu. Zakładanie, że wszyscy są zgodni co do stosowanych pojęć bez ich potwierdzenia i udokumentowania jest przykładem nieodpowiedniego podejścia do inżynierii wymagań. Innymi wyzwaniami, z którymi może mierzyć się inżynier wymagań są problemy komunikacyjne a także brak zaangażowania interesariuszy w etap pozyskiwania wymagań. Negatywny wpływ ma również nacisk, aby szybko ukończyć produkt. 

Jak zapobiec błędnemu założeniu, że wszyscy jednakowo rozumiemy pojęcia?

Ustalenie wspólnej terminologii jest jedną z najistotniejszych czynności w całej inżynierii wymagań. W ustaleniu wspólnego zrozumienia pomocne jest stworzenie słownika. Jest to dokument zawierający zbiór definicji i pojęć związanych z danym projektem. Może on składać się z terminów, skrótów czy synonimów i homonimów. Powinny znaleźć się w nim wszystkie pojęcia, które są nieznane dla osób pracujących nad projektem lub istnieje ryzyko, że mogą być różnie interpretowane. Dostęp do słownika powinien być powszechny, aby każdy uczestnik projektu mógł rozszerzać zawarte w nim terminy oraz je weryfikować. Jednak, aby zapewnić jakość słownika warto określić kto za niego odpowiada. Dobrą praktyką jest też podawanie źródeł terminów, żeby w razie niejasności można było w łatwy i szybki sposób doprecyzować dany termin. Słownik należy regularnie uaktualniać przez cały czas trwania projektu. Interesariusze powinni być zgodni co do treści, aby wyeliminować nieporozumienia na tle terminologii. 

Podstawowe typy wymagań

W inżynierii wymagań wyróżnia się następujące typy wymagań:

• wymagania funkcjonalne – dotyczą tego, co system ma robić, jakie będą jego funkcje,
• wymagania jakościowe (inaczej zwane niefunkcjonalnymi) – określają pożądane cechy systemu,
• ograniczenia – wskazują granice tego, co będzie implementowane.

Pośród wymagań jakościowych znajdują się wymagania bezpieczeństwa, użyteczności, wydajności, niezawodności, przenaszalności, dostępności i utrzymywalności. Jako testerzy również musimy zebrać informacje na temat wymagań niefunkcjonalnych (np. wydajność, bezpieczeństwo, użyteczność) aby wiedzieć co należy przetestować w ramach projektu poza samymi funkcjonalnościami. Ważne jest aby dokumentować nie tylko wymagania funkcjonalne, ale również i te niefunkcjonalne. 

Co wpływa na wymagania systemu?

Źródło wymagań dla systemu jest zawarte w jego kontekście. Kontekst systemu to część rzeczywistości, która ma wpływ na wymagania systemu. Wymagania można pozyskiwać przede wszystkim od interesariuszy, ale również mogą być ukryte w działających systemach i funkcjonujących procesach, jak również w dokumentach. Zdefiniowanie kontekstu jest podstawą do pozyskiwania wymagań. Całkowite zdefiniowanie granic systemu i kontekstu często możliwe jest dopiero pod koniec procesu wymagań, ponieważ wtedy mamy większy pogląd na planowane właściwości systemu oraz pożądane funkcje.

Techniki pozyskiwania wymagań

Aby stworzyć produkt satysfakcjonujący dla interesariuszy i użytkowników należy określić nie tylko ich świadome wymagania, ale również odnaleźć te nieświadome i podświadome. W tym celu stosowane są różne techniki. Pośród nich można wyróżnić:

• techniki sondażowe (wywiady, kwestionariusze, ankiety),
• techniki kreatywności (burza mózgów, zmiana perspektywy),
• techniki na podstawie dokumentów (archeologia systemu, ponowne wykorzystanie wymagań),
• techniki obserwacyjne (obserwacja terenowa, praktyki)
• oraz techniki pomocnicze (mapa myśli, prototypy, warsztaty, nagrania audio/wideo).

Modele pomocne w dokumentowaniu wymagań

W zrozumieniu informacji oraz powiązań między nimi pomocne są modele. Model to po prostu abstrakcja rzeczywistości. Pozwalają na szybsze dokumentowanie oraz selektywne przedstawienie informacji, dlatego mogą stanowić łatwiej przyswajalną formę dokumentacji. Jednym z modeli, z którymi można się spotkać to diagram przypadków użycia. Przedstawia aktorów (użytkowników), możliwe akcje oraz relacje między nimi a czynnościami. Przypadki użycia najczęściej przedstawiają funkcjonalności systemu. Diagram przypadków użycia może być wsparty specyfikacją przypadków użycia. Specyfikacja dodatkowo zawiera scenariusz z poszczególnymi krokami, warunki wstępne i końcowe. Tego typu dokumentacja wymagań stanowi dobre źródło do wyprowadzenia przypadków testowych. Diagram klas jest jednym z ważniejszych modeli. Przedstawia on informacje o klasach oraz statycznych związkach między nimi. Dodatkowo w inżynierii wymagań stosuje się również diagram przepływu danych, diagram aktywności czy diagram maszyny stanowej.

Testowanie wymagań i dokumentów wymagań. Garść porad

Po zebraniu wymagań należy dokonać ich walidacji, celem sprawdzenia czy spełniają zdefiniowane kryteria jakości i czy na pewno nadają się do wykorzystania. Podczas walidacji można wykryć błędy i niejednoznaczności i poprawić je na wczesnym etapie, zanim zdążą wpłynąć negatywnie na projekt. Ważne jest, aby żadne z wymagań nie było sprzeczne z innym wymaganiem. Dobrą praktyką odnośnie wymagań jest przestrzeganie zasady aby w jednym zdaniu znajdowało się jedno wymaganie. Dodatkowo, zdania oraz akapity powinny być możliwie krótkie.

W jaki sposób walidować wymagania? 

W walidacji wymagań stosowane są następujące techniki:

• komentowanie (opinia ekspercka), czyli ocena wymagań dokonana przez osobę inną niż autor,
• inspekcja, czyli formalny proces walidacji wymagań,
• przejrzenie, czyli mniej formalna technika identyfikacji błędów,
• czytanie oparte na perspektywie, czyli sprawdzenie dokumentu pod kątem konkretnej perspektywy, konkretnych aspektów,
• walidacja za pomocą prototypów,
• walidacja z użyciem list kontrolnych.

Model Kano, czyli czynniki satysfakcji

Zebrane wymagania oraz stworzone rozwiązanie wpływają w różny sposób na satysfakcję interesariuszy. W celu określenia jej poziomu stosuje się model Kano, który obrazuje czynniki podstawowe, czynniki wydajnościowe oraz czynniki entuzjazmu (o nich zaraz). Podczas, bądź po zakończeniu pozyskiwania wymagań, należy określić, które wymagania są kluczowe aby osiągnąć satysfakcję interesariuszy.  Czynniki podstawowe to inaczej czynniki wzbudzające niezadowolenie w przypadku ich zaniedbania; funkcjonalności, które są niezbędne, aby zaspokoić podstawowe potrzeby klienta.  Czynniki wydajnościowe zwane są inaczej czynnikami świadomymi. Są to wymagania, których interesariusze są świadomi i potrafią je zdefiniować. Ich spełnienie wzbudza zadowolenie, które jest proporcjonalne do natężenia cechy. Niespełnienie wymagań z tej grupy skutkuje niezadowoleniem interesariuszy.  Ostatnim poziomem zadowolenia są czynniki entuzjazmu, zwane czynnikami nieświadomymi. Są to wymagania, które nie są świadome, ale powodują duże zadowolenie w przypadku ich spełnienia. Czynniki entuzjazmu mogą być odkryte podczas pracy z systemem lub prototypem. Niespełnienie czynników z tej grupy nie skutkuje niezadowoleniem, a ich spełnienie powoduje zachwyt interesariuszy. Ważną cechą poziomu satysfakcji jest fakt iż maleje wraz z czasem. Oznacza to, że czynniki, które wcześniej wzbudzały zachwyt, po pewnym czasie przechodzą w czynniki wzbudzające tylko zadowolenie. 

Jak się uczyć i skąd czerpać wiedzę?

Warto wspomnieć, że ten artykuł stanowi jedynie wstęp do zagadnień związanych z inżynierią wymagań. Jedną z możliwych opcji poszerzenia wiedzy na temat inżynierii oprogramowania są kursy oferujące certyfikację IREB. Podczas kursu uczestnicy zapoznają się z niezbędną teorią, poznają modele przedstawiania danych oraz przygotowują się do egzaminu z inżynierii wymagań.  Jednym z nich jest IREB Foundation Level – 3-dniowe szkolenie, zakończone certyfikacją. Tutaj dowiesz się o nim więcej: https://testuj.pl/karta-szkolenia/szkolenie-ireb-foundation-level 

Podsumowanie

Wiedza z obszaru inżynierii wymagań może stanowić wartościowe poszerzenie kompetencji testera oprogramowania. Dzięki znajomości zagadnień z tego obszaru można efektywniej sprawdzać jakość na wcześniejszych etapach projektu – im wcześniej tester oprogramowania zostanie wdrożony w projekt, tym większe może to przynieść korzyści. O czym mowa? Przede wszystkim o zwiększeniu możliwości wychwycenia błędów w dokumentacji wymagań i w samych wymaganiach, co pozwala uniknąć późniejszych kosztów naprawy oraz wydłużenia czasu projektu.

Angelika Mikiciuk

Certyfikowana testerka, absolwentka kierunku User Experience/Product Design, filolog. W swojej codziennej pracy zajmuje się m.in. testowaniem dostępności. Związana z Fundacją Klub Kontra, która obsługuje informator dla osób z niepełnosprawnościami „Katowice bez barier”. W wolnych chwilach prowadzi bloga o swoich początkach w branży - Nauczyciel w IT.