Wymaganie funkcjonalne określa, co system ma robić: jakie zachowania, funkcje i operacje na danych ma realizować w odpowiedzi na działania użytkowników i zdarzenia. To odpowiedź na pytanie „co system robi", w odróżnieniu od wymagań niefunkcjonalnych, które mówią, jak dobrze ma to robić.
Wymagania funkcjonalne to chleb powszedni analityka - zapisuje je jako user stories z kryteriami akceptacji, przypadki użycia albo klasyczne listy „system umożliwia / system wykonuje". Niezależnie od formy obowiązują te same kryteria jakości: wymaganie ma być jednoznaczne, testowalne i atomowe (jedno wymaganie = jedno zachowanie).
Przykład z MediFlow: „System umożliwia pacjentowi odwołanie wizyty najpóźniej 24 godziny przed jej terminem; zwolniony slot wraca do puli dostępnych terminów w ciągu 60 sekund; pacjent otrzymuje potwierdzenie odwołania SMS-em". Trzy zdania, trzy testowalne zachowania, zero miejsca na interpretację. Dla porównania wersja, która trafiła do analityka na początku: „system obsługuje odwołania". Z tego zdania developer nie wie nic - kto odwołuje, do kiedy, co się dzieje ze slotem, czy ktoś dostaje powiadomienie.
Częsta pomyłka: mieszanie wymagań funkcjonalnych z niefunkcjonalnymi. „System szybko wyszukuje wolne terminy" skleja funkcję (wyszukiwanie) z jakością (szybko), a ta druga część jest w dodatku niemierzalna. Rozdziel: funkcja do wymagań funkcjonalnych, „poniżej 2 sekund dla 95% zapytań" do niefunkcjonalnych. Druga pomyłka: wymagania-wydmuszki w rodzaju „system obsługuje rezerwacje". Test prostoty: jeśli tester nie umie na podstawie wymagania napisać przypadku testowego, wymaganie nie jest skończone.