1.1. Czym są i skąd się biorą wymagania użytkownika?

W procesie wytwarzania oprogramowania jednym z kluczowych zagadnień jest określenie zakresu budowanego systemu. Wymagania użytkownika powinny opisać potrzeby klienta w sposób wystarczający do określenia rozmiaru systemu i nakładu pracy potrzebnej do jego zbudowania. Specyfikacja wymagań użytkownika powinna zatem dostarczyć odpowiedzi na kluczowe w procesie zarządzania projektem pytania:

• Jak obszerna będzie funkcjonalność systemu?
• Jakie dane będzie przetwarzał system?
• Kto będzie się posługiwał systemem?
• Jakie zasoby (ludzie, czas, pieniądze) są potrzebne do zbudowania systemu?

Punktem wyjścia dla analityków oraz odbiorców przyszłego systemu przy formułowaniu wymagań użytkownika jest wizja sytemu. Zidentyfikowane wymagania użytkownika dokumentujemy, aby mogły się stać podstawą do zawarcia umowy między zamawiającym a wykonawcą systemu, w tym – do określenia zasobów niezbędnych do realizacji systemu. Wymagania użytkownika powinny być zatem na tyle precyzyjne, aby nie było niedomówień co do zakresu systemu. Jednocześnie, powinny być na tyle ogólne, aby nie sugerować rozwiązań technicznych (dotyczących np. implementacji interfejsu użytkownika, baz danych, itp.), co jest dopiero zadaniem projektantów systemu.

Rysunek 1.1 pokazuje podstawowe zasady przekształcania wizji systemu w zestaw wymagań użytkownika i utrzymywania spójności między nimi. Każda cecha funkcjonalna (tu: F098) powinna zostać poddana analizie pod kątem jej realizacji przez odpowiedni zestaw wymagań funkcjonalnych. Należy zwrócić uwagę na to, że cecha funkcjonalna może być przekształcona w kilka przypadków użycia (lub innych wymagań tego typu). Z drugiej strony, każde wymaganie funkcjonalne na poziomie wymagań użytkownika powinno wynikać z co najmniej jednej cechy sytemu. Podobnie jak wymagania funkcjonalne, przekształceniu podlegają wymagania jakościowe i ograniczenia. Przekształcenie polega najczęściej na doprecyzowaniu i określeniu metryk.

Rysunek 1.1: Zgodność wymagań użytkownika z wizją systemu

Jeśli planowany system jest zamawiany na rzecz organizacji biznesowej, to dobrym źródłem wymagań funkcjonalnych na poziomie wymagań użytkownika mogą być opisy procesów biznesowych. Zwróćmy uwagę na to, że takie postępowanie uzupełnia proces łowienia wymagań na podstawie cech systemu. Dzięki odniesieniu do szczegółowych czynności procesów biznesowych możemy łatwiej określić konkretne wymagania mieszczące się z zakresie budowy systemu.

1.2. Rodzaje wymagań użytkownika

Jednym z najczęściej spotykanych sposobów zapisu wymagań funkcjonalnych są przypadki użycia systemu. Notacja przypadków użycia jest oparta na bardzo prostych modelach graficznych. Zasadniczo składa się ona z dwóch elementów – aktorów (ikona człowieka) i przypadków użycia (elipsa), co ilustruje rysunek 1.2.

Rysunek 1.2: Przykładowy model przypadków użycia

Alternatywnym do przypadków użycia sposobem formułowania wymagań funkcjonalnych są historie użytkownika. Historie użytkownika opisują oczekiwania klienta w stosunku do tworzonego systemu za pomocą krótkich zdań mieszczących się np. na kartkach z notesu. Zdanie stanowiące historię użytkownika powinno określać podmiot historii (użytkownik, który czegoś chce od systemu), cel biznesowy realizowany przez system i oczekiwany przez użytkownika, oraz motywację klienta stojącą za konkretnym oczekiwaniem. Do formułowania historii użytkownika można wykorzystać następujący prosty wzorzec:

·        Jako <rodzaj użytkownika> chcę <jakiś cel>, aby <jakiś powód>

Przykładowe historie, analogiczne do przypadków użycia z rysunku 1.2 przedstawia rysunek 1.3.

Rysunek 1.3: Przykładowy zestaw historii użytkownika

Drugim kluczowym składnikiem wymagań użytkownika są wymagania jakościowe. Wymagania te mogą w bardzo znaczącym stopniu wpłynąć na architekturę systemu, a tym samym – na koszt jego wykonania. Bardzo istotne jest zatem, aby zapewnić kompletność i jednoznaczność tego rodzaju wymagań na poziomie wymagań użytkownika. Kontrolę kompletności może nam zapewnić zachowanie zgodności z określoną taksonomią wymagań jakościowych. Istnieje wiele takich taksonomii, przy czym tutaj podamy ogólny podział w oparciu o normę ISO/IEC 25010:2011. Jest to standard przemysłowy, oparty na doświadczeniach z wielu rzeczywistych projektów. Identyfikuje on następujące rodzaje wymagań: Przydatność funkcjonalna, Efektywność wydajnościowa, Kompatybilność, Użyteczność, Niezawodność, Bezpieczeństwo, Łatwość utrzymania i Przenośność.

Aby móc sprawdzić stopień realizacji wymagań jakościowych należy określić dla nich metryki i związany z tym sposób testowania (patrz rys. 1.1, wymaganie J022-2). Na poziomie wymagań użytkownika konieczne jest określenie metryk na tyle precyzyjnych, żeby można było oszacować koszt realizacji systemu spełniającego te wymagania.

Trzecim rodzajem wymagań formułowanych na poziomie wymagań użytkownika są ograniczenia środowiskowe i techniczne. Ograniczenia zawężają możliwości odnośnie do projektowania i implementacji danego systemu oprogramowania. Przykład notacji dla ograniczeń przedstawia rysunek 4.

Rysunek 1.4: Przykładowy zestaw ograniczeń środowiskowych

Ostatnim rodzajem wymagań, zapewniającym spójność całej specyfikacji jest słownik dziedziny. W słowniku tym umieszczane są wszystkie pojęcia, stanowiące elementy dziedziny problemu, którą będzie wspierał tworzony system oprogramowania. Pojęcia te docelowo przekładają się na dane, które będzie musiał przechowywać oraz przetwarzać system. Ważnym elementem opisu słownika dziedziny jest zatem wyszczególnienie istotnych składników poszczególnych pojęć dziedzinowych. W szczególności, należy określić atrybuty pojęć, czyli elementarne jednostki danych, które będą podlegać przetwarzaniu.

Rysunek 1.5: Przykładowy słownik dziedziny problemu

Słownik dziedziny może być opisany w tradycyjny sposób, czyli jako lista definicji pojęć w porządku alfabetycznym. W wielu przypadkach korzystniejsze jest przedstawienie słownika dziedziny w formie diagramu. Najczęściej używaną w tym celu notacją jest notacja modelu klas (język UML), zilustrowana na rysunku 1.5.

1.3. Organizowanie i dokumentowanie wymagań użytkownika

Podczas procesu zbierania wymagań użytkownika otrzymujemy pokaźny zbiór wymagań różnego rodzaju. W przypadku typowego, średniej wielkości systemu, samych wymagań funkcjonalnych może być kilkadziesiąt lub nawet kilkaset. Aby możliwe było zapanowanie nad taką liczbą wymagań, konieczne jest stworzenie logicznej struktury organizującej wszystkie jednostki wymagań.

Jak już zostało wspomniane, wymagań każdego rodzaju może być wiele. W celu lepszego panowania nad złożonością specyfikacji korzystne będzie podzielenie poszczególnych pakietów wymagań na pakiety składowe. Podstawową zasadą, którą należy się kierować grupując wymagania w pakiety, jest panowanie nad złożonością i zrozumiałość dla czytelników specyfikacji. Pomaga tutaj zasada 7 +/- 2, która określa ograniczenia percepcji. Przeciętny człowiek jest w stanie w danym momencie, w zależności od indywidualnych predyspozycji, przetwarzać w umyśle od 5 do 9 elementów. W przypadku większej liczby elementów konieczne jest zastosowanie dodatkowych technik (np. abstrakcji) w celu objęcia danego zagadnienia umysłem.

Niezależnie jednak od narzędzia, które jest wykorzystywane do zapisywania i zarządzania wymaganiami, klient najczęściej wymaga utworzenia specyfikacji w formie dokumentu podlegającego akceptacji. Wzór takiego dokumentu może być ustalony przez organizację zamawiającą system lub może być elementem warsztatu pracy analityków.