Odpowiedź.

Wymagania funkcjonalne opisują, co system powinien robić: operacje biznesowe, procesy, scenariusze użytkownika — czyli funkcjonalność.

Wymagania niefunkcjonalne definiują, jak system powinien działać: ograniczenia, parametry jakości, wydajność, bezpieczeństwo, użyteczność itp. Te wymagania często wpływają na wybór technologii, skalowalność i stabilność rozwiązania.

Dlaczego ważne jest rozróżnienie:

• Wyraźne rozdzielenie sprzyja poprawnemu określeniu zadań dla programistów i testerów.
• Pozwala unikać pomijania krytycznych cech (na przykład bezpieczeństwa, skalowalności).
• Niezauważone niefunkcjonalne wymagania często stają się źródłem niepowodzeń projektów.

Kluczowe cechy:

• Wymagania funkcjonalne — zachowanie systemu.
• Wymagania niefunkcjonalne — jakość i ograniczenia.
• Oba typy muszą być wyraźnie udokumentowane i uzgodnione.

Pytania z pułapką.

Czy „użyteczność interfejsu” wchodzi w skład wymagań funkcjonalnych?

Nie, to parametr niefunkcjonalny (usability). Wymaganie funkcjonalne to obecność na przykład przycisku „Zapisz”, niefunkcjonalne to szybkość jego reakcji i łatwość użycia.

Czy można zignorować wymagania niefunkcjonalne, jeśli nie są one wyraźnie wskazane przez klienta?

Nie. Analityk jest zobowiązany do omówienia i sformalizowania nawet niejawnych wymagań niefunkcjonalnych, w przeciwnym razie zwiększa się ryzyko opóźnień w uruchomieniu, skarg użytkowników i dodatkowych kosztów.

„System powinien być w stanie obsługiwać 1000 zapytań na minutę”. Czy to wymaganie funkcjonalne?

Nie, to wymaganie niefunkcjonalne — charakterystyka wydajności.

Typowe błędy i antywzorce

• Skupienie się wyłącznie na funkcjonalności („najważniejsze, żeby działało, prędkość potem”).
• Niejawne sformułowanie wymagań niefunkcjonalnych — „musi być szybko”, „nawet”, „bezpiecznie”.
• Ignorowanie testowania niefunkcjonalności.

Przykład z życia

Negatywny przypadek: System w pełni zebezpieczył zadeklarowaną funkcjonalność biznesową, ale przy dużym obciążeniu zaczynał „zamulać”, ponieważ wydajność nie została w ogóle uwzględniona. Zalety:

• Szybki rozwój, dokładne wykonanie deklarowanych scenariuszy. Wady:
• System nie nadawał się do użytkowania w warunkach rzeczywistego obciążenia, firma musiała pilnie poprawiać architekturę.

Pozytywny przypadek: Analityk wspólnie z architektem i klientem ustalili w wymaganiach maksymalne obciążenie, kryteria reakcji, przeprowadzili testy obciążeniowe. Zalety:

• Produkt stabilnie działał i znosił wzrost liczby użytkowników.
• Plany rozwoju przewidywały skalowalność. Wady:
• Na początku projektowania trzeba było poświęcić więcej czasu na dyskusje i dodatkowe testy.