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