Analiza wymagań

Analiza wymagań – uzgodnienie wymagań klienta i ich analiza. Celem jest określenie zakresu prac, oszacowanie czasochłonności, kosztów i czasu wykonania.

Wstępna analiza wymagań

• oszacować techniczne wymagania (środowisko działania, system operacyjny, wymagania sieciowe)
• określić aplikacje, systemy z którymi musimy zintegrować system
• wymagania funkcjonalne (spis oczekiwań klienta)
• (przykładowe) scenariusze użycia

Wymagania funkcjonalne

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ć.

Jakie działania będzie mógł wykonać użytkownik ? Przykład:
Użytkownik może się zalogować, wydrukować wynik, wyświetlić listę plików.
Po wciśnięciu przycisku OK okno się zamyka i następuje powrót do okna głównego.

Jakie działanie wykonuje system ? Przykład:
Cyklicznie (codziennie) wysyłana jest poczta do wskazanych użytkowników.

• dane wejściowe → działanie → dane wyjściowe
• ogólne – lista w języku naturalnym
• szczegółowa specyfikacja – dokładna lista, UML, grafy działania (zrobimy w późniejszej fazie projektowania)

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.

Podczas opisywania wymagań funkcjonalnych (zarówno listy wymagań, jak i szczegółowej specyfikacji), należy posługiwać się prostymi, jednoznacznymi i zrozumiałymi stwierdzeniami

Wymagania niefunkcjonalne

Ograniczenia w jakich system ma pracować, standardy jakie spełnia, itp.

Jaki ten system powinien być ?
Co jest interfejsem ? (strona www, GUI, konsola, inne aplikacje)
Czy jest przeznaczona dla pojedynczego użytkownika?
Na jakim systemie operacyjnym działa?
Jakie mam wymagania (dodatkowe oprogramowanie, dodatkowy sprzęt)?

• wydajność
• sklalowalność
• otwartość, możliwość rozbudowy
• odporność na awarie
• bezpieczeństwo

Metoda FURPS

• Functionality funkcjonalność w rozumieniu zestawu funkcji uwzględniająca również bezpieczeństwo, możliwości systemu
• Usability użyteczność jako zestaw wizualnych aspektów oprogramowania, estetyka, dokumentacja
• Reliability niezawodność, będąca mierzona np. częstością występowania błędów
• Performance wydajność aplikacji określana również jako czas odpowiedzi lub użycie zasobów
• Supportability przenosność, rozszerzalność, nie dająca się łatwo przetłumaczyć “wspieralność” uwzględniająca zdolność aplikacji do instalacji na różnych platformach, łatwość testowania itd.

Diagramy użycia

Przykładowy scenariusz uzycia:

Przypadek użycia powinien przedstawiać podstawowy przebieg operacji, tzw. szczęśliwą ścieżkę wydarzeń („basic flow”, „happy flow”)

Przykład:

1. System prosi Użytkownika o zalogowanie
2. Użytkownik podaje swój numer identyfikacyjny oraz hasło
3. System stwierdza poprawność danych
4. Użytkownik zostaje zalogowany do systemu

Ścieżki alternatywne - sytuacje, gdy nie zachodzi ścieżka optymalna.
Dla punktu 3 może zajść, np.:

• System odrzuca podane dane
• Powrót do kroku 1.

Przykład dokumentu

1. Wprowadzenie – krótki opis celu systemu.
2. Słownik – definicja wszystkich technicznych i specyficznych terminów użytych w dokumencie.
3. Modele systemu – (np. graficzny) relacje między elementami systemu i środowiskiem systemu.
   O ile uda się już na tym etapie taki model sporządzić. Na początek ogólny model (lub brak modelu).
4. Wymagania funkcjonalne – powinien się tu znaleźć możliwie pełny spis usług systemu, przy czym nie muszą one jeszcze być opisywane bardzo szczegółowo.
   W tej sekcji można również zawrzeć informacje o danych, jakie system będzie przetwarzał:
   • Opis – krótki opis funkcjonalności.
   • Wejście – definicja danych wejściowych i ich ewentualnych ograniczeń.
   • Wyjście – definicja zwracanych rezultatów.
   • Efekty uboczne – określenie dodatkowych czynności, np. interakcji z innymi funkcjami.
5. Wymagania niefunkcjonalne – w tej sekcji przede wszystkim należy wypisać ograniczenia wynikające z oczekiwań klienta co do technologii, w której ma to być realizowane.
6. Dodatkowo można zawrzeć diagramy (przypadki) użycia