Wydajność, bezpieczeństwo, intuicyjność i tak dalej… Lista możliwych wymagań w systemie IT jest długa. Czy da się w jakiś sposób zmierzyć wymagania niefunkcjonalne? Jak zmierzyć intuicyjność czy łatwość obsługi?
Odpowiedź jest jedna — TAK, da się zmierzyć wymagania niefunkcjonalne. Wbrew pozorom nie jest to takie trudne!
O tym właśnie jest ten wpis.
Wstęp — czym są wymagania niefunkcjonalne?
Wymagania niefunkcjonalne odpowiadają na pytanie „jak” system realizuje założone funkcjonalności.
Przykładowo, proces logowania do aplikacji może być:
- szybki,
- intuicyjny,
- bezpieczny.
Te wymagania w żaden sposób nie definiują „co” system będzie robił.
Poziomy wymagań niefunkcjonalnych
Wymagania niefunkcjonalne należą do różnych kategorii. Dlatego wrzucanie ich do jednego worka i opisywanie przez zanegowanie wymagań funkcjonalnych nie pomaga w zrozumieniu o co naprawdę chodzi.
Wyobraź sobie taki scenariusz:
- właściciel produktu oczekuje przyrostu +10 000 nowych użytkowników co miesiąc, co nie może wpłynąć negatywnie na opóźnienie działania systemu — jest to klasyczny przykład wymagania niefunkcjonalnego na poziomie biznesu,
- zespół specjalistów przekłada to na pewne cechy produktu, takie jak: konkretna wydajność i skalowalność.
- po dokładniejszej analizie jeden z inżynierów sugeruje, że przy tak dynamicznym skalowaniu konieczne będzie natychmiastowe raportowanie problemów z bazą danych. Czyli informacja ma być dostępna w określonym czasie od momentu wystąpienia problemu. Niezależnie więc od wyboru rozwiązania („co”) do monitorowania, musi ono posiadać pewne cechy niefunkcjonalne („jak”). Możemy to określić cechami pod-produktu, którym będzie narzędzie monitorujące.

Jaki jest związek wymagań funkcjonalnych z niefunkcjonalnymi?
Wymagania niefunkcjonalne istnieją w ścisłej relacji z wymaganiami funkcjonalnymi.
Wróćmy do przykładu skalowania produktu +10 000 nowych użytkowników. Czy wymagania dotyczące wydajności będą na takim samym poziomie w całym systemie?
Raczej nie. Strony kluczowe dla końcowych użytkowników, takie jak np. rejestracja, strona startowa, czy strona do dokonywania zakupów będą miały wyśrubowane czasy reakcji. Ale dla administratora, który będzie zarządzał setkami tysięcy kont, czas odpowiedzi systemu może być nieco dłuższy. Kilka sekund opóźnienia nie wpłynie na jego efektywność, czy chęć korzystania z systemu.
Dlatego, żeby zmierzyć wymagania niefunkcjonalne trzeba je najpierw umieścić w kontekście, jakim są wymagania funkcjonalne.

Jak zmierzyć wymagania niefunkcjonalne w projekcie IT?
Do tej pory używałem ogólnych stwierdzeń typu: system ma być wydajny. Teraz pora określić co to dokładnie znaczy i jak zmierzyć wymagania niefunkcjonalne.
Wbuduj wymagania niefunkcjonalne w produkt
Dlaczego wymagania niefunkcjonalne muszą być możliwe do zmierzenia?
Spotykam się z wymaganiami typu: „system będzie intuicyjny i łatwy w obsłudze dzięki wdrożeniu nowoczesnego interfejsu użytkownika, jak na załączonych makietach„.
Czy to jest prawidłowe, czy błędne wymaganie niefunkcjonalne?
Odpowiedź jest w tym, co było wcześniej. Jeżeli autor wymagania określił oczekiwany poziom intuicyjności, a następnie potwierdził, że przygotowane makiety pozwalają ten poziom osiągnąć, to jest OK.
Podobnie jest OK, jeżeli intuicyjność została zdefiniowana na początku, a autor dopuszcza modyfikację UI w trakcie projektu, tak aby osiągnąć założony poziom intuicyjności.
Gorzej jeżeli makiety zostały przygotowane z nadzieją, że system będzie intuicyjny, bez określenia, czym w ogóle jest ta intuicyjność. Wtedy wymaganie sprowadza się do wdrożenia makiet. Intuicyjność będzie trudnym do przewidzenia wynikiem tego wdrożenia.

Dobrą praktyką jest więc definiowanie mierzalnych wymagań niefunkcjonalnych jak najwcześniej, a następnie wbudowywanie ich w produkt.
Znajdź autora wymagania
Od czego zacząć?
Przeanalizuj takie wymaganie: „Strona główna będzie ładowała się szybko i bez wyraźnych opóźnień„.
Co to znaczy?
Nic.
Potrzebny jest ktoś, kto wyjaśni co miał/a na myśli.

Do każdego wymagania powinien być przypisany jeden autor. Przy dwóch i więcej osobach jest prawie pewne, że pojawią się różne interpretacje tego co znaczy: szybko, wydajnie, intuicyjnie itd.
Wyjaśnij nieścisłości w opisie wymagania niefunkcjonalnego
Jak już masz autora, to popracuj nad doprecyzowaniem wymagania. Jest to pierwszy krok do określenia mierników.
Przykładowe wymaganie: „Strona rejestracji musi być wyjątkowo intuicyjna i przyjazna użytkownikom”.
Wspólnie z autorem wyjaśniamy poszczególne terminy:
- „strona rejestracji„ — oznacza stronę, na której użytkownik wpisuje dane i potwierdza chęć dołączenia do programu (patrz makieta XYZ).
- „wyjątkowo intuicyjna i przyjazna” — tą definicją zajmiemy się w dalszej części.
- „użytkownik” – użytkownik, który nie posiada jeszcze konta w systemie ABC i jest to zwykle jego pierwszy kontakt z systemem ABC.
Określ skalę i sposób pomiaru
Teraz pora na najtrudniejsze. Co miał autor na myśli pisząc „wyjątkowo intuicyjna i przyjazna”?
W tym momencie powinny paść pytania typu:
- co to dokładnie znaczy?
- jak możemy to zmierzyć? po czym poznać, że strona spełnia te wymagania?
- co jeszcze kryje się pod tym pojęciem?
Powiedzmy, że „intuicyjny i przyjazny” interfejs według autora oznacza, że:
- większość użytkowników zarejestruje się za pierwszym razem bez żadnej pomocy,
- strona będzie dostosowana do potrzeb osób niepełnosprawnych,
- użytkownicy uznają stronę za atrakcyjną wizualnie.
Te definicje są mało nieprecyzyjne. Więc drążymy dalej, tak aby dla każdej z tych składowych określić:
- skalę, czyli w jakich jednostkach będziemy mierzyć to wymaganie,
- miernik, czyli sposób pomiaru tego wymagania,
- poziomy, czyli do jakich wartości będziemy dążyć.
W wyniku rozmów i analiz możemy na przykład określić takie definicje:
Wymaganie | Skala | Miernik | Poziomy |
Większość użytkowników zarejestruje się za pierwszym razem bez żadnej pomocy. | % użytkowników, którzy przejdą proces rejestracji przy pierwszej próbie, dla min. 20 osób. | Wykorzystanie narzędzia do nagrywania zachowania użytkownika. | OK>85% Idealnie>95% |
Strona będzie dostosowana do potrzeb osób niepełnosprawnych. | Liczba pozytywnie zakończonych testów według uproszczonej procedury weryfikacji dostępności | Manualne przeprowadzenie testów przez inżyniera testów. | OK>=18/22 Idealnie>=20/22 |
Użytkownicy uznają stronę za atrakcyjną wizualnie. | % użytkowników, którzy uznają stronę za atrakcyjną na min. 4 w skali 1-5, przy próbie min. 40 osób. | Ankieta wśród grupy docelowej przeprowadzona w social media. | Ok>50% Idealnie>80% |
W tak podanych skali i miernikach należy doprecyzować wszelkie wieloznaczne terminy, tak aby była możliwa jednoznaczna weryfikacja. Przykładowo: „proces rejestracji” wymaga osobnej definicji. Termin „użytkownik” już zdefiniowaliśmy, więc można się do niego odwołać.
Te same mechanizmy zastosuj do opisania dowolnych innych wymagań, takich jak np.: wydajność, odtwarzalność, bezpieczeństwo itd.
Czy jest sens mierzyć wymagania niefunkcjonalne, które są określone subiektywnie?
Ktoś mógłby zakwestionować tego typu podejście. Bo jaką mamy gwarancję, że użytkownicy w ankietach powiedzą prawdę. Albo, że w trakcie testów nie będą świadomie wprowadzać nas w błąd.
Słusznie, nie ma takiej gwarancji.
O ile niektóre wymagania są precyzyjnie mierzalne, jak np. wydajność, o tyle inne bazują na subiektywnych opiniach i statystyce.
Mimo to mnie przekonują dwa argumenty:
- Jakiekolwiek liczby są lepsze niż żadne. Jeżeli nawet się pomylimy w miernikach, to i tak będziemy szli w dobrym kierunku.
- Definiując mierniki ograniczamy niekończące się rozmowy o tym, czy coś jest ładne, przyjazne itd. Każdy pewnie zna sytuację, gdy właściciel produktu zmienia co chwilę zdanie na temat wyglądu aplikacji. Precyzyjne wymagania zmieniają perspektywę z „mi się to podoba” na konkretny wskaźnik, który opisuje preferencje użytkowników. A o to przecież chodzi.
Zaplanuj implementację i testy
Co więc zrobić z definicjami wymagań niefunkcjonalnych?
Tak przygotowane wymagania można wbudowywać w system od pierwszej linijki kodu. Analitycy, projektanci czy architekci wiedzą dokładnie jaki jest cel. Dzięki temu są w stanie przygotować rozwiązania, które odpowiadają na tak zdefiniowane wymagania.
Jednocześnie, tak szybko jak to możliwe, powinny rozpocząć się testy. Na przykład makiety ekranów mogą zostać ocenione przez grupę przyszłych użytkowników, którzy ocenią na ile te projekty są atrakcyjne. Analogicznie można sprawdzić intuicyjność procesu rejestracji.
Im częstsze i coraz bardziej precyzyjne testy, tym mniej przeróbek pod koniec projektu.
Przykłady mierników wymagań niefunkcjonalnych
W materiałach do pobrania załączyłem plik z przykładowymi definicjami wymagań niefunkcjonalnych. Znajdziesz go pod numerem 12.

Przeczytaj też o określaniu wartości w projektach IT.
