inzynieria_wymagan

# Inżynieria wymagań

Inżynieria wymagań to proces, który obejmuje wszystkie czynności niezbędne do opracowania i aktualizacji dokumentacji wymagań systemowych. Istnieją cztery ogólne czynności wysokiego poziomu w procesie inżynierii wymagań. Są nimi:

## Studium wykonalności.

Daną wejściową tego studium jest ogólny opis systemu i tego jak będzie wykorzystywany w ramach przedsiębiorstwa. Wynikiem tego studium powinien być raport który zaleca albo nie zaleca kontynuacji procesu inżynierii wymagań. Studium wykonalności to krótkie opracowanie odpowiadające na kilka pytań:

1. czy system przyczyni się do realizacji ogólnych celów przedsiębiorstwa
2. czy system może być zaimplementowany z użyciem dostępnych technologii w ramach ustalonego budżetu i ograniczeń czasowych.
3. czy system może być zintegrowany z istniejącymi systemami które już zainstalowano.

## Określanie i analizowanie wymagań.

W trakcie tej czynności techniczni budowniczowie pracują z klientami i użytkownikami systemu nad badaniem dziedziny zastosowania i usług , które system ma oferować , pożądanej efektywności, ograniczeń sprzętowych itd. Czynnościami tego procesu są : Rozpoznanie dziedziny . Jeśli system ma działać np. w supermarkecie to analityk musi się dowiedzieć jak działa supermarket.

- Zbieranie wymagań. Proces interakcji z użytkownikami systemu , którego celem jest wyjawienie ich wymagań.
- Klasyfikacja. Podzielenie bezładnego zbioru wymagań na grupy.
- Usuwanie sprzeczności znalezionych w podanych przez użytkowników wymaganiach
- Nadawanie priorytetów. W każdym zbiorze wymagań będą bardziej i mniej ważne
- Sprawdzanie wymagań. Czy są spójne, pełne i zgodne z tym czego użytkownicy tak naprawdę chcieli od systemu.

Ludzie często wolą przykłady z życia wzięte niż abstrakcyjne opisy. W tym celu tworzy się scenariusze zdarzeń które są przykładami sesji interakcyjnych. Każdy scenariusz może obejmować jedną lub kilka możliwych interakcji. Scenariusz obejmują opis przepływu danych , akcji systemu i wyjątków które mogą się pojawić. Przykład takiego scenariusza to może być np. interakcja człowieka z bankomatem przedstawiona blokowo.

Drugi sposób na przedstawienie zachowania systemu to tzw. przypadki użycia kiedy to użytkownika przedstawia się jako kreskową postać , a każdą klasę akcji jako elipsę.

## Specyfikowanie i dokumentowanie wymagań.

Wymagania stawiane systemowi informatycznemu można podzielić na następujące grupy:

- Wymagania użytkownika. Wymagania te powinny określać wymagania funkcjonalne 1) i niefunkcjonalne 2) w taki sposób, aby były zrozumiałe dla użytkowników systemu. Powinny określać jedynie zewnętrzny sposób zachowania się systemu unikając charakteryzowania projektu systemu.

- Wymagania systemowe. Są to bardziej szczegółowe opisy wymagań użytkownika. Mogą być podstawą kontraktu zatem powinny zawierać pełną i niesprzeczną specyfikację całego systemu. Są traktowane przez inżynierów jako punkt wyjścia do projektowania systemu. Powinny określać co system ma robić, a nie jak ma być zaimplementowany. Wymagania systemowe są często zapisywane za pomocą języka naturalnego, co może generować kłopoty wynikające ze zbytniej elastyczności takiego zapisu. Dlatego można stosować tzw. strukturalny język naturalny, będący ograniczeniem języka naturalnego. Język ten dostarcza szablony np. formularze do definiowania wymagań. Inny sposób specyfikowania wymagań systemowych wykorzystuje do tego zbliżony do Javy lub Ady język PDL (Program Description Language). Ten sposób jest chwilowo wręcz zbyt bliski implementacji. Jednak jego stosowanie umożliwia szybkie wyłapywanie sprzeczności i przeoczeń.

## Zatwierdzanie wymagań.

Polega na wykazaniu, że wymagania naprawdę definiują system, którego chce użytkownik. Ma wiele cech wspólnych z analizą ponieważ oznacza poszukiwanie kłopotów z wymaganiami. Różni się natomiast tym, że pracuje się już na niemalże kompletnej dokumentacji. Jest to bardzo ważny etap mogący bardzo rzutować na czas trwania i koszt projektu dlatego należy podejść do niego bardzo poważnie. Sprawdzenia wymagań obejmują:

- Sprawdzenia ważności. Użytkownik musi być przekonany że system będzie spełniał swoje funkcje.
- Sprawdzenie niesprzeczności.
- Sprawdzenie kompletności. Dokumentacja powinna zawierać wymagania, w których zdefiniowano wszystkie funkcje i ograniczenia zamierzone przez użytkownika.
- Sprawdzenie realności.
- Możliwość weryfikowalności. Na wypadek sporów z klientem, należy wymagania pisać tak, aby dało się je potem zweryfikować. Należy zatem opracować system sprawdzianów, który wykaże że system spełnia określone w dokumentacji wymagania.

1) wymagania funckjonalne - określają, jak system ma działać, jak ma reagować na określone dane wejściowe , jak ma się zachowywać w określonych sytuacjach
2) wymagania niefunkcjonalne - specyfikują ograniczenia usług i funkcji systemu. Obejmują ograniczenia czasowe , ograniczenia procesu tworzenia, standardy itd.