Czym zajmuje się inżynieria wymagań?

Inżynieria wymagań dostarcza informacji o kształcie budowanego systemu z punktu widzenia klienta (np. użytkowników). W ramach inżynierii wymagań konieczne jest uwzględnienie takich czynników jak: środowisko, w którym system będzie funkcjonował, zadania, które system będzie realizował, czy też sposób, w jaki system będzie funkcjonował. Główne produkty wykorzystywane i tworzone w ramach dyscypliny wymagań to opis środowiska (np. środowiska biznesowego) i specyfikacja wymagań. Inżynieria wymagań oprogramowania obejmuje działania polegające na zbieraniu, formułowaniu, modyfikacji i aktualizacji specyfikacji wymagań, która jest podstawą efektywnego kosztowo wytworzenia systemu oprogramowania, z wykorzystaniem wiedzy naukowej oraz technicznej. W procesie inżynierii wymagań można wyróżnić 6 kroków: 1) ustalenie wymagań, 2) analizowanie i negocjowanie wymagań, 3) specyfikowanie wymagań, 4) modelowanie obserwowalnego działania systemu, 5) zatwierdzenie wymagań, 6) zarządzanie wymaganiami.

Wymagania, ich odbiorcy i reprezentacje

Wymagania odpowiadają na najistotniejsze w całym procesie budowy oprogramowania pytanie, „jaki system mamy zbudować?” W dobrze zorganizowanym procesie wytwórczym, wymagania sterują konstrukcją systemu. Wszystkie działania związane z projektowaniem, implementacją oraz wdrożeniem sytemu są podporządkowane spełnieniu wymagań. Z wymagań korzystają osoby po stronie zamawiającego (np. firma zamawiająca), jak i po stronie wykonawcy (np. firma wykonująca system). Konieczne jest zatem zastosowanie notacji, które byłyby zrozumiałe dla określonych uczestników procesu wytwarzania oprogramowania. Notacje wykorzystywane w dyscyplinie wymagań można podzielić na tekstowe i graficzne. Najbardziej podstawową notacją jest wykorzystanie swobodnego języka naturalnego. Powstały też różnego rodzaju notacje wykorzystujące ograniczony język naturalny, np. historie użytkownika oraz tekstowe scenariusze przypadków użycia. Notacje graficzne często wykorzystują język UML, np. diagramy przypadków użycia czy diagramy klas.

Klasyfikacja wymagań

Dobrze zbudowana specyfikacja wymagań powinna mieć strukturę piramidy. Szczyt takiej piramidy stanowi ogólny opis systemu – jego wizja. Elementy wizji systemu stanowią punkt wyjścia do sformułowania wymagań użytkownika określających zakres budowanego systemu. Podstawą piramidy i jednocześnie jej największym fragmentem są wymagania oprogramowania, wyrażające wszystkie szczegółowe potrzeby zamawiającego. Na wszystkich poziomach piramidy formułujemy wymagania czterech rodzajów: wymagania funkcjonalne, jakościowe, słownikowe, oraz ograniczenia środowiskowe i techniczne. Zbiór wszystkich wymagań stanowi specyfikację wymagań, która może być wyrażona w sposób mniej lub bardziej sformalizowany. Często wymagane jest stworzenie formalnego dokumentu, który będzie stanowił załącznik do umowy miedzy zamawiającym z wykonawcą.

Jakość specyfikacji wymagań

Jakość wymagań jest kluczowym elementem powodzenia każdego projektu konstrukcji systemu oprogramowania. Ogólnie, można powiedzieć, że dobre sformułowanie wymagań polega na dobrym odzwierciedleniu rzeczywistych potrzeb zamawiającego. W szczególności, dobrej jakości wymagania powinny charakteryzować się kilkoma podstawowymi cechami. Wymagania powinny być kompletne, tzn. powinny one obejmować cały zakres potrzeb zamawiającego opisany w niezbędnych szczegółach. Powinny być również jednoznaczne i poprawne, tzn. powinny definiować jeden możliwy zakres systemu, i nie pozostawiać pola do różnych interpretacji. Wymagania powinny być również spójne, czyli niesprzeczne. Eliminacja sprzeczności polega na ciągłym wzajemnym porównywaniu wymagań ze sobą, szczególnie wymagań różnych rodzajów. Kolejną cecha dobrej specyfikacji wymagań jest możliwość zarządzania i śledzenia. Wymagania powinny być podzielone na dobrze określone jednostki, które mogą sterować procesem wytwórczym. Bardzo istotną, można powiedzieć – kluczową cechą wymagań jest ich testowalność (mierzalność). Wymaganie, którego nie jesteśmy w stanie przetestować jest nic niewarte. Ważne jest również, aby specyfikacja wymagań była podatna na zmiany. Należy cały czas pamiętać, że zmiany wymagań są nieodłącznym elementem każdego praktycznie projektu konstrukcji oprogramowania.

Czynności i produkty dyscypliny wymagań

Wytwarzanie produktów dyscypliny wymagań wchodzi w zakres obowiązków dwóch podstawowych ról inżynierii wymagań oprogramowania – analityka biznesowego i analityka systemowego. Rolą analityka biznesowego jest dokonanie oceny organizacji, identyfikacja aktorów oraz procesów biznesowych, tworzenie modelu procesów biznesowych oraz zdefiniowanie słownictwa biznesu. Rolą analityka systemowego jest stworzenie specyfikacji wymagań składającej się z wizji, modelu wymagań funkcjonalnych (np. przypadków użycia), szczegółowych scenariuszy i scenopisów, a także wymagań systemowych (jakościowych i ograniczeń) i szczegółowego słownika dziedziny.  W metodykach zwinnych (agile), definicja zadań w dyscyplinie wymagań jest ograniczona. W metodyce XP za wymagania odpowiada rola klienta, a w metodyce Scrum – rola właściciela produktu.

Wymagania w cyklu życia oprogramowania

Większość współczesnych projektów stosuje jeden z dwóch cykli wytwórczych: cykl wodospadowy (również nazywany kaskadowym) lub cykl iteracyjny. Wybór jednego z tych cykli zależy od różnych czynników i przede wszystkim zależy od rozmiarów oraz stabilności wymagań. Wymagania zamawiającego umożliwiają stworzenie ram dla projektu, czyli jego zakresu i wynikających z niego – czasu trwania i budżetu. Wynikiem etapu wymagań zamawiającego może być np. formalna umowa (kontrakt) na wykonanie systemu lub wstępnie określony rejestr produktu. W cyklu wodospadowym, po ustaleniu ram projektu, następuje etap wymagań oprogramowania. W cyklu iteracyjnym, etap wymagań oprogramowania powtarzany jest w każdej iteracji. Oznacza to, że szczegółowe wymagania na system są formułowane bezpośrednio przed ich zaprojektowaniem i implementacją. W cyklu wodospadowym etap testowania przebiega pod koniec projektu, kiedy sprawdzana jest zgodność zbudowanego systemu z pełną specyfikacją wymagań. W cyklu iteracyjnym, testy systemu (aktualnego przyrostu lub wydania) odbywają się w ramach każdej iteracji.

Wymagania jako podstawa zarządzania projektem

Zarządzanie wymaganiami polega na ciągłym upewnianiu się, że rozwiązujemy właściwy problem klienta, a tym samym, że budujemy właściwy system. Polega ono na systematycznym podejściu do zbierania, organizowania, dokumentowania i wykorzystywania zmieniających się wymagań dla systemu oprogramowania. Dla sprawnego zarządzania wymaganiami konieczne jest wyposażenie ich w dodatkowy opis – atrybuty wymagań. Typowy zbiór atrybutów wymagań obejmuje m.in.: unikalny identyfikator, wagę dla klienta, wagę dla wykonawców, trudność wykonania, status, wersję, planowane wydanie, osobę odpowiedzialną. Zarządzanie zakresem i zmianami można porównać do przepuszczania wymagań przez „bramkę kontroli jakości”. Każde wymaganie podlega ocenie pod kątem priorytetów, czyli przede wszystkim – wagi dla zamawiającego i wagi dla wykonawcy (trudności wykonania). Proces zarządzania zmianami, zdefiniowany procedurami wprowadzania zmian, powinien być uruchomiony, gdy oprogramowanie lub związana z nim dokumentacja wymaga wprowadzenia modyfikacji. Należy tak zaprojektować procedury zarządzania zmianami, żeby koszty i korzyści związane ze zmianami były właściwie analizowane oraz żeby zmiany systemu były wprowadzane w kontrolowany sposób. Bardzo istotne dla identyfikacji skutków zmiany wymagań jest utrzymywanie śladów łączących wymagania miedzy sobą, a także wymagania z innymi produktami pracy. Ślady są dobrym sposobem na zachowanie spójności całej specyfikacji wymagań. Podstawową techniką jest tutaj zachowanie spójności słownictwa poprzez łączenie wymagań różnego rodzaju (funkcjonalne, jakościowe) z pojęciami w słowniku. Bardzo istotne jest tworzenie i utrzymywanie relacji między poszczególnymi wymaganiami a odpowiednimi elementami innych produktów pracy, takich jak – przypadki testowe, modele projektowe czy instrukcje dla użytkowników.

Specyfikowanie środowiska systemu

Specyfikowanie środowiska zaczynamy od określenia otoczenia biznesu, czyli zbioru wszystkich jednostek współpracujących z biznesem. Tymi jednostkami mogą być klienci, podwykonawcy, dostawcy podzespołów, spedytorzy, zleceniodawcy, instytucje państwa, agenci, itp. Biznes może również współpracować bezpośrednio z zewnętrznymi systemami informatycznymi. Działania biznesu opisujemy za pomocą modeli procesów biznesowych, wyrażonych np. w języku BPMN lub UML (diagramy czynności). Proces biznesowy posiada jasno określone granice, wejście i wyjście, składa się z sekwencji uporządkowanych na przestrzeni czasu czynności, oraz tworzy wartość dodaną dla określonego odbiorcy (beneficjenta procesu).

Specyfikowanie wizji systemu

Wizja systemu powinna dawać przede wszystkim odpowiedzi na pytania: Po co budujemy nowy system? Jakie problemy biznesu zamawiającego ten system rozwiąże? Dla kogo jest ten system, jakie są ograniczenia w środowisku odbiorcy systemu? Jakie cechy ma mieć ten system, aby pokonać zidentyfikowane problemy? Pierwszym krokiem podczas analizy zasadności budowy systemu oprogramowani powinno być zdefiniowanie problemów, które ewentualny system mógłby rozwiązać, czyli sformułowanie stwierdzenia problemu. Kolejnym elementem wizji systemu powinna być specyfikacja interesariuszy, czyli wszystkich tych osób, na których wdrożenie nowego systemu będzie miało bezpośredni lub pośredni wpływ. Najważniejszym składnikiem wizji systemu jest zestaw cech systemu. Cechy systemu stanowią odpowiedź na potrzeby poszczególnych grup zainteresowanych systemem. Wizję systemu uzupełnia słownik najważniejszych pojęć oraz motto dla systemu.

Techniki pozyskiwania wymagań

Można wyróżnić dwa podstawowe źródła pozyskiwania wymagań: dokumenty oraz ludzie. Zawsze jednak najważniejszym źródłem wymagań są ludzie, gdyż dopiero bezpośrednie rozmowy pozwalają odkryć rzeczywiste potrzeby klienta. Wśród technik współpracy z dokumentami można wyróżnić podkreślanie pojęć, wyróżnianie wymagań oraz poszukiwanie opisów interakcji z użytkownikiem w dokumentacji zastanych systemów oprogramowania. Techniki pracy z dokumentami stanowią punkt wyjścia dla zastosowania technik współpracy z ludźmi. Techniki te mają na przede wszystkim na celu ustanowienie efektywnych kanałów komunikacji między klientem a wykonawcą. Najważniejszymi technikami tego typu są wywiady z użytkownikiem, terminowanie, burze mózgów i sesje typu JAD. Pierwsze dwie techniki dotyczą pracy indywidualnej, a dwie kolejne – pracy grupowej.


Ostatnia modyfikacja: środa, 3 lipca 2024, 10:29