1.1. Czym są wymagania oprogramowania?

Wymagania oprogramowania stanowią uszczegółowienie wymagań użytkownika. Na tym poziomie piramidy wymagań, przypadki użycia zdefiniowane podczas formułowania wymagań użytkownika są opisywane w szczegółach, poprzez m.in. zdefiniowanie interakcji pomiędzy aktorami a systemem w postaci scenariuszy przypadków użycia. Powstają również tzw. scenopisy, które łączą opis działania przypadków użycia z wyglądem poszczególnych „scen”, czyli elementów wyświetlanych użytkownikowi. Podsumowując rolę wymagań oprogramowania, można powiedzieć, że dają one odpowiedź na trzy pytania:

• Jakie są szczegóły funkcjonowania systemu?
• Jakie dane będą przetwarzane przez system?
• Jakie inne szczegółowe cechy powinien mieć system?

Tego typu szczegóły są bardzo podatne na zmiany w miarę postępów prac nad systemem. Dlatego też, zazwyczaj formułuje się je bezpośrednio przed implementacją wybranego fragmentu funkcjonalności systemu. W cyklu iteracyjnym, dopiero po wybraniu zestawu przypadków użycia (lub historii użytkownika) do realizacji w danej iteracji, dokonuje się ich szczegółowego wyspecyfikowania.

1.2. Podstawowe składniki wymagań oprogramowania

Jednym z istotnych aspektów definiowania wymagań oprogramowania jest uzupełnienie przypadków użycia zdefiniowanych w wymaganiach oprogramowania kompletnymi scenariuszami. Scenariusze określają w sposób precyzyjny interakcję użytkownika z systemem prowadzącą do osiągniecia celu biznesowego określonego przez dany przypadek użycia. Scenariusze na poziomie wymagań oprogramowania powinny określać wszystkie zidentyfikowane alternatywne ścieżki wykonania przypadku użycia oraz obsługę sytuacji wyjątkowych (np. spowodowanych wystąpieniem błędu podczas wykonania przypadku). Przypadek użycia jest zbiorem scenariuszy, co ilustruje rysunek 1.1. Istotnym warunkiem jest tutaj, aby scenariusze te prowadziły do tego samego celu, niezależnie od tego, czy kończą się powodzeniem (osiągnięciem celu) czy porażką. Scenariusze przypadku użycia powinny definiować wszystkie alternatywne przebiegi obsługujące reakcje systemu na różne zdarzenia, w tym sytuacje wyjątkowe.

Rysunek 1.1: Przypadek użycia ze zbiorem jego scenariuszy

Kolejnym elementem, który składa się na precyzyjną specyfikację wymagań oprogramowania jest szczegółowy model danych. Pojęcia dziedziny problemu zamieniamy w precyzyjnie wyspecyfikowane klasy w modelu danych, co ilustruje rysunek 1.2.

Rysunek 1.2: Klasa w modelu danych a pojęcie w słowniku dziedziny

W trakcie specyfikacji wymagań oprogramowania powstają także nowe pojęcia – klasy uzupełniające model danych. Podczas uszczegóławiania wymagań (np. pisania szczegółowych scenariuszy) odkrywane są pojęcia reprezentujące np. elementy interfejsu użytkownika które służą do komunikacji użytkownika z systemem lub pojęcia dotyczące konfiguracji systemu. Rysunek 1.3 przedstawia model danych w postaci diagramu klas wraz z klasami reprezentującymi elementy interfejsu użytkownika oraz parametry konfiguracyjne systemu. Są one oznaczone odpowiednio stereotypami <<UI window>> i <<configuration>>.

Rysunek 1.3: Klasy uzupełniające model danych

Scenariusze wraz ze zidentyfikowanymi elementami interfejsu użytkownika są podstawą do stworzenia projektu interfejsu użytkownika oraz scenopisów. Dla kolejnych kroków scenariuszy należy uzgodnić z klientem i zaprojektować wygląd (w tym – treść) poszczególnych elementów ekranowych. Tak zaprojektowane elementy ekranowe układają się w odpowiednią sieć definiującą możliwość nawigacji poprzez interfejs użytkownika oraz realizację celów zadanych przypadkami użycia.

1.3. Wymagania oprogramowania w cyklu życia

W cyklu iteracyjnym produkty wymagań oprogramowania powstają w każdej iteracji. Jednocześnie, na podstawie tych produktów powstają inne, istotne produkty procesu wytwórczego. Zależność głównych produktów pracy dla wymagań oprogramowania od innych produktów pracy na ścieżce do kodu przedstawia rysunek 1.4. Wymagania oprogramowania uszczegóławiają wymagania zamawiającego, a ich celem jest “przetłumaczenie” zakresu systemu w modele architektoniczne (projektowe) systemu. Wymagania funkcjonalne zapisane w postaci przypadków użycia lub historii użytkownika są opisywane w szczegółach za pomocą scenariuszy i scenopisów. To stanowi podstawę dla stworzenia odpowiednich modeli dynamiki systemu. Z kolei słownik dziedziny jest zamieniany w szczegółowy model danych. To jest podstawą do zdefiniowania statycznych modeli architektury. Uzupełnienie tego opisu o rozbudowane wymagania jakościowe i ograniczenia techniczne pozwala na podjęcie decyzji architektonicznych i technologicznych prowadzących do zrealizowania systemu w pełni zgodnego z realnymi potrzebami zamawiającego.

Rysunek 1.4: Źródła i cel dla wymagań oprogramowania