logo
Kobe Steel plant that supplied

Dokumentowanie wymagań niefunkcjonalnych z pomocą FURPS+

  • : Marcin Ziemek
  • : 2025-01-23
  • : esej

Czy zastanawiałeś się kiedyś, w jaki sposób dokumentować wymagania niefunkcjonalne? Chciałbyś dowiedzieć się czym jest FURPS+? Z tego tekstu dowiesz się czym jest FURPS+ oraz jak go wykorzystać do dokumentowania wymagań niefunkcjonalnych.

Czym są wymagania niefunkcjonalne?

Wymagania niefunkcjonalne (ang. non-functional requirements) definiują cechy systemu takie jak bezpieczeństwo, wydajność czy niezawodność. Stanowią ograniczenia (ang. contrains) związane z projektowanym systemem.

Wymagania funkcjonalne odpowiadają na pytanie CO system ma robić, z kolei wymagania niefunkcjonalne JAK DOBRZE.

Z definicją wymagań niefunkcjonalnych możesz również zapoznać się w słowniku BABOK oraz SAFe (Scaled Agile Framework).

Co to jest FURPS+?

Jedną z metod kategoryzacji wymagań funkcjonalnych oraz niefunkcjonalnych jest FURPS+.

FURPS+ został opracowany przez Roberta Grady w Hewlett-Packard.

W FURPS+ wyróżniamy następujące kategorie wymagań:

  • Funkcjonalność (ang. functionality)
  • Użyteczność (ang. usability)
  • Niezawodność (ang. reliability)
  • Wydajność (ang. performance)
  • Wsparcie (ang. supportability)
  • ‘+’ – pozostałe wymagania oraz ograniczenia

Zadaniem FURPS+ jest pomoc w kategoryzacji wymagań oraz weryfikacji kompletności wymagań.

W dalszej części przedstawię, jak wykorzystuję FURPS+ do kategoryzacji wymagań niefunkcjonalnych.

deimos_art_1_rys_2.png

(F)unctionality - Funkcjonalność

Funkcjonalność (ang. functionality) definiuje wymagania funkcjonalne. Uwzględnia również wymagania, które nie są przedstawiane za pomocą specyficznych przypadków użycia i dotyczą całego systemu na przykład wymagania związane z bezpieczeństwem, logowaniem czy audytem.

Główne podkategorie to:

  • Audyt
  • Licencjonowanie
  • Drukowanie
  • Raportowanie
  • Bezpieczeństwo
  • a. Poufność (np. tylko autoryzowani użytkownicy mają dostęp do danych)
  • b. Integralność (np. dane są spójne i poprawne)
  • c. Dostępność (np. dane są dostępne cały czas)
  • Debugowanie
  • Harmonogramowanie

Przykładowymi wymaganiami niefunkcjonalnymi z kategorii Funkcjonalność są:

  • Autentykacja wykonywana jest po stronie serwera
  • W integracji między systemami wykorzystywany jest bezpieczny protokół HTTPS
  • Dane wrażliwe są szyfrowane
  • Dane systemowe oraz biznesowe są logowane
  • W systemie zdefiniowana jest lista ról wraz z uprawnieniami
  • Sesja użytkownika jest unieważniona po wylogowaniu użytkownika
  • Limit czasu sesji wynosi 10 minut w przypadku braku aktywności zalogowanego użytkownika

(U)sability - Użyteczność

Użyteczność (ang. usability) definiuje wymagania związane z zapewnieniem, aby produkt był zrozumiały, łatwy do nauczenia oraz korzystania.

Główne podkategorie to:

  • Przystępność (np. system wspiera przeglądarki IE, Chrome)
  • Spójność (np. wszystkie komunikaty o błędzie wyglądają tak samo w całym systemie)
  • Zasady nawigacji (np. dotyczy wsparcia wykorzystania klawiatury, myszki czy skrótów klawiszowych)
  • Czas szkolenia (np. szkolenie nowych użytkowników będzie trwało 2 dni lub 8 godzin)
  • Standardy użyteczności (np. rozwiązanie w zakresie użyteczności będzie zgodne z polityką/standardami firmy)

Przykładowymi wymaganiami niefunkcjonalnymi z kategorii Użyteczność są:

  • System musi być dostępny z poziomu przeglądarki Chrome
  • Zostanie wprowadzona polityka haseł zawierająca wytyczne o długości oraz poziomie skomplikowania
  • Będzie możliwy zdalny dostęp do systemu zgodnie ze zdefiniowaną polityką
  • Zostaną przeprowadzone szkolenia użytkowników z obsługi systemu

(R)eliability - Niezawodność

Niezawodność (ang. reliability) określa możliwość produktu do wykonania funkcji (działania) podczas podanych warunków przez określony czas albo określonej liczby operacji.

Główne podkategorie to:

  • Dostępność
  • Dokładność
  • Możliwość odzyskania

Przykładowymi wymaganiami niefunkcjonalnymi z kategorii Niezawodność są:

  • Backup bazy danych musi być wykonywany codziennie
  • Backup bazy danych będzie przechowywany przez 1 rok
  • Czas przywrócenia systemu po awarii nie może być dłuższy niż 4 godziny
  • System powinien być dostępny przez 99,9% czasu

(P)erformance - Wydajność

Wydajność (ang. performance) określa stopień, w jakim system lub komponent spełnia wyznaczone funkcje w ramach określonych ograniczeń dotyczących czasu przetwarzania i przepustowości.

Główne podkategorie to:

  • Pojemność (np. system musi przechowywać 5 TB danych)
  • Przepustowość (np. system musi zapewnić obsługę 100k transakcji na minutę lub system musi obsługiwać równoległą pracę 200 użytkowników)
  • Czas odpowiedzi (np. system musi maksymalnie odpowiadać w 2 sekundy, maksymalny czas logowania nie może być dłuższy niż 1 sekunda)
  • Skalowalność (np. że system musi się automatycznie skalować)

Przykładowymi wymaganiami niefunkcjonalnymi z kategorii Wydajność są:

  • Czas odpowiedzi systemu nie może być dłuższy niż 2 sekundy
  • System musi obsługiwać do 100 tysięcy równoległych transakcji
  • System musi obsługiwać do 1000 równoległych użytkowników

(S)upportability - Wsparcie

Wsparcie (ang. supportability) określa możliwość systemu do obsługi podczas całego cyklu życia systemu.

Główne podkategorie to:

  • Adaptowalność
  • Audytowalność
  • Kompatybilność (np. system jest zgodny z poprzednimi wersjami)
  • Konfigurowalność
  • Możliwość instalacji
  • Testowalność
  • Utrzymanie
  • Zgodność
  • Lokalizacja (np. system obsługuje język polski oraz angielski)

Przykładowymi wymaganiami niefunkcjonalnymi z kategorii Wsparcie są:

  • Zostaną przygotowane odseparowane środowiska testowe w celu przeprowadzenia testów funkcjonalnych, integracyjnych oraz akceptacyjnych
  • System będzie możliwy do monitorowania za pośrednictwem narzędzia do monitorowania
  • Zostaną przygotowane specjalne dashboardy w narzędziu do monitorowania

+

"+" określa inne wymagania oraz ograniczenia definiujące projekt, implementację, interfejsy czy elementy fizyczne rozwiązania.

Główne podkategorie to:

  • Projekt oraz realizacja (np. dotyczące konieczności zastosowania bazy danych relacyjnej PostgreSQL)
  • Interfejsy (np. do integracji między systemami zostanie wykorzystany standard SOAP)
  • Elementy fizyczne (np. mogą dotyczyć wyboru konkretnych serwerów)
  • Informacje prawne (np. dotyczące praw autorskich)

Przykładowymi wymaganiami niefunkcjonalnymi z kategorii "+" są:

  • Zostanie przygotowany dokument przedstawiający architekturę rozwiązania
  • Zostanie przygotowany dokument przedstawiający architekturę infrastruktury
  • W systemie zostaną wykorzystane relacyjne bazy PostgreSQL
  • Zostanie przygotowany plan testów oraz wdrożenia
  • Share On: