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.

Software Requirements Specification (SRS)

• 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

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

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.

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

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

1. Wprowadzenie
   • krótki opis celu systemu.
2. Słownik – definicja wszystkich technicznych i specyficznych terminów użytych w dokumencie.
3. Ogólny opis systemu
   • opis najważniejszych cech systemu
   • modele systemu - wyodrębnienie i opis najważniejszych modułów systemu, relacje między elementami systemu i środowiskiem systemu (np. w formie graficznej - diagram) .
     O ile uda się już na tym etapie taki model sporządzić. Na początek ogólny model (lub brak modelu).
   • grupy użytkowników i ich atrybuty (użytkownik, administrator)
   • środowisko pracy systemu (system operacyjny, sprzęt), ogólny opis interfejsów
4. Wymagania funkcjonalne – możliwie pełny spis usług systemu, przy czym nie muszą one jeszcze być opisywane bardzo szczegółowo (szczegółowy opis dodamy później).
   • Zwykle opis wymagań funkcjonalnych powinien zawierać następujące punkty:
     • Nazwa funkcjonalności
     • 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 wykonywanych dla tej funkcjonalności, np. interakcji z innymi funkcjami.
   • można zawrzeć diagramy (przypadki) użycia.
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. Część z nich już mogła pojawić się we wcześniejszym opisie.
   • środowisko pracy systemu (system operacyjny), komunikacja z innymi elementami środowiska
   • wykorzystywane technologie
   • ograniczenia sprzętowe
   • ograniczenia prawne, licencje
   • inne …
   • założenia dotyczące bezpieczeństwa, wydajności , wymagania pamięciowe, itp.

Przykładowy szablon - by Karl E. Wiegers 1999
ITProject - PPZ 2012
KeePass-1.10
SIMP

Więcej przykładów

• Software_requirements_specification
• Non functional requriments examples by Dr. John Dalbey