Po wykonaniu identyfikacji wymagań (patrz: Techniki pozyskiwania wymagań) należy przeprowadzić ich analizę celem uszczegółowienia, ewentualnego odrzucenia wymagań sprzecznych lub nieprawidłowych oraz określenia priorytetu i ryzyka.

Analiza wymagań funkcjonalnych umożliwia zidentyfikowanie i opisanie pożądanego zachowania systemu. Zgodnie z jedną z definicji, wymaganie funkcjonalne to „stwierdzenie, jakie usługi ma oferować system, jak ma reagować na określone dane wejściowe oraz jak ma się zachowywać w określonych sytuacjach. W niektórych wypadkach wymagania funkcjonalne określają, czego system nie powinien robić”.

Szczegółowe wymagania funkcjonalne muszą opisywać możliwości systemu w zakresie zachowania oraz dostępnych operacji (czynności wykonywane przez system, odpowiedzi na akcje użytkownika). Wymagania funkcjonalne mogą obejmować również pewne elementy dotyczące wyglądu projektowanej aplikacji. Nie jest to jednak regułą, zwykle wymagania GUI znajdują się w osobnej kategorii lub są dostarczane przez Klienta w postaci standardu GUI danej organizacji (tzn. GUI guideline lub dokument Look & Feel Specification).

Wymagania funkcjonalne powinny opisywać:

• w jaki sposób system realizuje założone cele i wyniki biznesowe w ramach danej dziedziny,
• jakie warunki muszą być spełnione, aby system mógł wykonać określone zadania,
• w jaki sposób użytkownik będzie mógł korzystać z systemu w celu realizacji określonych zadań (jaki moduł aplikacji oferuje określoną funkcjonalność, jakie czynności użytkownik musi wykonać w celu uzyskania danego rezultatu).

Wymagania funkcjonalne powinny uwzględniać standard (np. obowiązujący w danej organizacji), który ma spełniać projektowany system – jeśli dotychczasowe rozwiązania wdrożone u Klienta mają określone sposoby realizacji pewnych funkcji, nowe rozwiązanie również powinno je spełniać (przykład: jeśli funkcjonalność wyszukiwania użytkownika już istnieje w którymś z systemów działających u Klienta, w nowym, projektowanym systemie funkcjonalność ta powinna działać analogicznie – zwiększa to re-używalność i spójność aplikacji, ponadto ułatwia pracę programistom i testerom oraz samym użytkownikom końcowym, przyzwyczajonym już do używania danej funkcjonalności w określony sposób).

Dobra dokumentacja wymagań nie powinna nadmiernie ograniczać projektu aplikacji, to znaczy narzucać konkretnego rozwiązania architektonicznego. Analityk powinien w taki sposób opisywać system, by prezentować dostępne funkcje i możliwości aplikacji bez zbędnego wnikania w szczegóły techniczne (dlatego tak często mówi się, że analityk nie musi, wręcz nie powinien mieć doświadczenia w programowaniu czy architekturze, gdyż w przeciwnym wypadku mimowolnie będzie się starał napisać dokumentację wymagań w sposób odpowiadający swojej wiedzy technicznej, a to z kolei może znacznie ograniczyć funkcjonalność rozwiązania).

Wymagania dokumentuje się zwykle w postaci tekstu. Szczegółowy opis wymagań – specyfikację funkcjonalną – tworzony jest zwykle w postaci tekstu w określonej formie (np. specyfikacja przypadków użycia) oraz modeli UML (np. map procesów lub aktywności). 

Podczas opisywania wymagań funkcjonalnych (zarówno listy wymagań, jak i szczegółowej specyfikacji), należy posługiwać się prostymi, jednoznacznymi i zrozumiałymi stwierdzeniami – zbyt złożone lub zawierające za dużo terminów fachowych powodują, że dokumentacja staje się trudna w odbiorze, a przecież ma służyć nie tylko jej autorowi, lecz również udziałowcom ze strony Klienta, kierownikowi projektu, zespołom developerskim i QA. Dobrze opracowana lista wymagań zawiera wymagania napisane:

• Prosto – bez złożonych warunków;

• Spójnie – terminologia używana w dokumentacji wymagań jest spójna i ma to samo znaczenie w różnych częściach dokumentacji (przykład – słowo „klient” użyte w dokumentacji zawsze znaczy to samo i określa docelowego Klienta z punktu widzenia organizacji zamawiającej produkt IT);

• Zrozumiale – analityk nie może zakładać, iż odbiorca dokumentacji posiada szeroką wiedzę dziedzinową. Wymaganie powinno być zrozumiałe zarówno dla eksperta dziedzinowego, testera, programisty, jak i dowolnej innej osoby z grupy udziałowców. Najczęściej popełnianym błędem jest tu zakładanie, że coś jest na tyle oczywiste, iż nie wymaga dokładnego opisu, lub w ogóle nie wymaga wzmianki w dokumentacji. O ile pewne rzeczy są oczywiste dla analityka i przedstawicieli Klienta, o tyle wcale nie muszą być znane programistom, a to spowoduje, że nie będą zaimplementowane;

• Precyzyjnie – jedna pozycja na liście wymagań dotyczy tylko jednego wymagania. Ułatwia to dalsze śledzenie (ang. traceablity) i monitorowanie implementacji oraz weryfikacji wymagania;

• Zwięźle – tekst wymagań powinien być w miarę możliwości krótki i powinien opisywać wyłącznie zakres danego wymagania;

• W niektórych przypadkach lista wymagań definiuje również osoby odpowiedzialne za dokumentację określonych wymagań i sposób ich weryfikacji w projektowanym systemie. Ponadto ważne jest określenie priorytetu i krytyczności dla każdego wymagania.

Wymagania opisane w formie tekstowej powinny obejmować opis możliwości systemu, warunków, jakie muszą zaistnieć, by wymaganie mogło zostać spełnione i zrealizowane oraz wszelkich ograniczeń, jakie uniemożliwiają spełnienie wymagania w projektowanym systemie. W określonych przypadkach (np. jeśli wymagań jest niewiele i są łatwe do zarządzania) nie ma potrzeby prowadzenia pełnej dokumentacji wymagań – lista (katalog) wymagań wraz z odniesieniami do dokumentacji szczegółowej jest informacją wystarczającą. Przykładowa struktura katalogu wymagań jest przedstawiona w Tabeli 1:

Tabela 1. Przykładowa lista wymagań

Autor: Karolina Zmitrowicz