Jakie są korzyści wymagań niefunkcjonalnych?
Przede wszystkim, dzięki nim, informacje dotyczące działania interface'u użytkownika są dostępne dla wszystkich uczestników projektu. Wymagania niefunkcjonalne mogą być też używane jako checklista, która pomoże w weryfikacji kolejnych powstających funkcjonalności. Dzięki temu aplikacja działa spójnie, a użytkownicy tracą mniej czasu na nauczenie się nowych funkcjonalności. Testowanie także staje się prostsze.
Zespół może skupić się na rozwiązywaniu trudniejszych problemów, bez konieczności odkrywania za każdym razem, jak ma działać aplikacja. Niwelujemy konieczność domyślania się i uwidaczniamy pożądane zachowania interface'a.
Wiedza nie jest rozproszona pomiędzy członkami zespołu, dostęp do niej ma każdy w jednym miejscu. Będzie to szczególnie ważne podczas wprowadzania do projektu nowych osób.
Spisanie wymagań niefunkcjonalnych upraszcza także tworzenie kolejnych zadań. Programista wie, że zaimplementowanie funkcjonalności wiąże się także z koniecznością spełnienia wymagań niefunkcjonalnych. W ten sposób unikamy powielania ciągle tych samych błędów.
Jeśli rozwijamy jednocześnie kilka aplikacji, które muszą być spójne, wymagania niefunkcjonalne dadzą dodatkową korzyść. Można się do nich odwoływać jako do zbioru najlepszych praktyk przy tworzeniu GUI. Oczywiście część wiedzy dotyczącej wymagań niefunkcjonalnych można brać z doświadczenia członków zespołu przy poprzednich projektach.
Wymagania niefunkcjonalne dotyczące jakiegoś obszaru aplikacji mogą wskazywać na to, że być może warto go zaimplementować w formie współdzielonego komponentu. Dzięki temu nie będziemy musieli go konfigurować wielokrotnie.
Moim zdaniem, spisanie wymagań powinno mieć miejsce od samego początku projektu. Ilość pracy przy tworzeniu i utrzymywaniu dokumentu jest niewielka, a korzyści, które otrzymujemy dzięki niemu, są znaczące.