Metoda FURPS, czyli 29 rzeczy do przemyślenia w każdym projekcie IT

„To aplikacja nie będzie działała na smartfonach?”, „Przecież to oczywiste, że powinna być możliwość rozbudowania systemu o pluginy!” – jak często zdarza Wam się usłyszeć tego typu słowa na prezentacji projektu przed klientem?
Ukryte wymagania, które wychodzą dopiero podczas realizacji projektu. Jak im zapobiec? Oczywiście, nie da się wcześniej zebrać i przeanalizować wszystkich wymagań. Takie przypadki zawsze będę się zdarzały. Można jednak sobie pomóc. Jednym z pomocnych narzędzi jest model FURPS – checklista obszarów, o których warto pomyśleć przed każdym projektem IT.

FURPS

FURPS to akronim reprezentujący model klasyfikowania funkcjonalnych i niefunkcjonalnych wymagań. Został on wymyślony przez Roberta Gready’ego z firmy Hewlett Packard. Robert stanął przed standardowym problemem – często uciekały mu pewne wymagania. Zauważył jednak, że wszystkie można sklasyfikować w pewną skończoną listę kategorii. Stworzył taką listę i każdy następny projekt starał się przeanalizować pod względem każdego z tych obszarów. Dzięki checkliście o żadnym nie zapomniał – zadziałało!
FURPS  to skrót od:

• Functionality (Funkcjonalność)
• Usability (Używalność)
• Reliability (Niezawodność)
• Performance (Wydajność)
• Supportability (Wsparcie)

Każdy z elementów oznacza pewien obszar wymagań, które mogą pojawić się w projekcie. Każdy z nich składa się też z bardziej szczegółowych obszarów. Takie drzewko kategorii wymagań można potraktować jako świetną checklistę, która pozwala zastanowić się nad wszystkimi najważniejszymi elementami projektu.
Poniżej cała klasyfikacja FURPS z autorskim tłumaczeniem oraz moimi małymi zmianami. Z góry przepraszam za niektóre neologizmy, ale ciężko mi było znaleźć polskie odpowiedniki 😉

Funkcjonalność (Functionality)

1. Czego system potrzebuje? – wszystkie wymagania funkcjonalne klienta
2. Administracja – panel do zarządzania
3. Audyt – zapis i odczytywanie zapisów czynności wykonanych w systemie (logi)
4. Połączenia – połączenia i synchronizacja, protokoły
5. Reużywalność – zależność od języka programowania, frameworka, środowiska itp.
6. Rozszerzalność – o dodatkowe pluginy
7. Licencjonowanie – sposób licencjonowania systemu

Używalność (Usability)

1. Ergonomia  – łatwość używania
2. Look and Feel – estetyczne właściwości systemu
3. Spójność – jakie elementy systemu powinny działać tak samo?
4. Dostępność – dostępność dla użytkowników mających specjalne wymagania np. niepełnosprawnych, niewidomych
5. Lokalizacja – wersje językowe systemu
6. Pomoc – pomoc dla użytkowników

Niezawodność (Reliability)

1. Dokładność – poprawność wyników (jaki stopień)
2. Dostępność – czas pomiędzy awariami
3. Odzyskiwalność – jak długo ma zająć czas do ponownego postawienia systemu po błędzie
4. Sprawdzalność – raportowanie o poprawności działania systemu
5. Mechanizmy naprawcze – Z jakimi błędami system powinien sobie sam poradzić

Wydajność (Performance)

1. Przepustowość – jak duże obciążenia system jest w stanie przetrwać
2. Responsywność – czas systemu na odpowiedź
3. Skalowalność – jak można skalować system
4. Prędkość – prędkość działania

Wsparcie (Supportability)

1. Adaptowalność – w jaki sposób system może być zaadoptowany do innych warunków
2. Audytowalność – dostęp do zapisu operacji
3. Kompatybilność – zgodność z poprzednimi wersjami systemu
4. Konfigurowalność – łatwość i sposób konfiguracji
5. Instalowalność – łatwość i sposób instalacji
6. Szybkość napraw – szybkość naprawy systemu
7. Testowalność – poziomy testowania systemu (funkcjonalne, unit, integracyjne itp.)

Czy czegoś Wam na tej liście brakuje? Zostawcie w komentarzu, uzupełnimy.