Wymagania funkcjonalne i niefunkcjonalne tworzą ciekawy związek. Żyją osobno, ale mają sporo wspólnego. W to wszystko miesza się jeszcze ktoś trzeci. A nawet czwarty.
Z tego wpisu dowiesz się:
- czym różnią się wymagania funkcjonalne i niefunkcjonalne,
- co łączy różne typy wymagań,
- co jeszcze trzeba uwzględnić w analizie wymagań, czyli na czym polega złoty trójkąt w pracy z wymaganiami
Pomocne definicje wymagań funkcjonalnych i niefunkcjonalnych
Zaczynamy od podstaw. Będę posiłkował się definicjami z sylabusa „Certyfikowany specjalista inżynierii wymagań IREB – Poziom podstawowy”
Wymagania funkcjonalne – czym są?
Oficjalna definicja: odnoszą się do wyniku, który musi być dostarczony lub zachowania, które musi być zapewnione przez funkcję systemu. Obejmują one wymagania dotyczące danych lub interakcji systemu z jego środowiskiem.
Jest też mniej oficjalna, krótsza definicja, którą preferuję – wymagania funkcjonalne mówią CO system robi.
Wymaganiem funkcjonalnym będzie więc np.:
- utworzenie nowego klienta z podaniem imienia, nazwiska i numeru telefonu,
- wyliczanie składowych wynagrodzenia zgodnie z wymaganiami konkretnej ustawy,
- pobranie kursów walut z serwisu NBP.
Wymagania niefunkcjonalne (jakościowe) – czym są?
Oficjalna definicja wymagań niefunkcjonalnych (jakościowych): odnoszą się do zagadnień jakości, które nie są objęte wymaganiami funkcjonalnymi. Są to na przykład: wydajność, dostępność, bezpieczeństwo lub niezawodność.
Także dla wymagań niefunkcjonalnych mam uproszczoną definicję: wymagania jakościowe oznaczają JAK (szybko, dobrze itp.) system działa.
Testem, który pozwala oddzielić wymagania funkcjonalne i niefunkcjonalne jest sposób przedstawienia rezultatu z wdrożenia takiego wymagania. Jeżeli wymaganie albo jest wdrożone albo nie (0 lub 1) to jest to wymaganie funkcjonalne. Jeżeli jednak poziom wymagania można pokazać na skali, to jest to wymaganie niefunkcjonalne (np. czas odpowiedzi zmieni się na 200ms z 5s).
Na pytanie, czym są takie wymagania i co mają wspólnego wymagania funkcjonalne i niefunkcjonalne odpowiadam dokładniej w tym nagraniu:
Rozwiązania i ograniczenia – czym są
Jest jeszcze trzeci czynnik, czyli ograniczenia. Według oficjalnej definicji: Ograniczenia to wymagania, które ograniczają przestrzeń rozwiązania ponad to, co jest konieczne, żeby spełnić dane wymagania funkcjonalne i wymagania jakościowe.
W skrócie, ograniczenia definiują JAK system zostanie zbudowany.
Czyli na przykład:
- system będzie dostępny wyłącznie jako aplikacja mobilna na urządzenia z systemem Android,
- ekran rejestracji zostanie wykonany zgodnie z załączonym projektem,
- serwisy będą korzystać z RabbitMQ do wymiany informacji.
Z ograniczeń jest więc bardzo blisko do Rozwiązań. Technicznie jest to w zasadzie to samo. Różnica jest tylko taka, że Ograniczenia ktoś narzuca w trakcie analizy wymagań, a Rozwiązania powstają w odpowiedzi na wymagania.
Złoty trójkąt, czyli zależności pomiędzy wymaganiami
Jaka jest zależność pomiędzy wymaganiami funkcjonalnymi i niefunkcjonalnymi? I gdzie jest miejsce na rozwiązania?
Czym jest złoty (żelazny) trójkąt?
Być może znasz koncepcję złotego trójkąta w zarządzaniu projektami. Chodzi o zależności pomiędzy trzema wymiarami: czas, zakres, budżet. I jeżeli te trzy parametry są z góry narzucone i niezmienne, to kierownik projektu przestaje pełnić tę rolę, bo nie ma czym zarządzać. Z drugiej strony, zmiana dowolnego parametru pociąga za sobą zmiany pozostałych. Nie można np. zwiększyć zakresu bez wpływu na czas i budżet.
Złoty trójkąt w analizie wymagań funkcjonalnych i niefunkcjonalnych
Podobna sytuacja jest w pracy z wymaganiami. Mamy też trzy wymiary w obrębie analizowanego modułu czy pojedynczej funkcjonalności:
- wymaganie funkcjonalne,
- wymaganie niefunkcjonalne (jakościowe),
- ograniczenia i możliwe rozwiązania.
Wypadkową z tych trzech jest Jakość, czyli poziom spełnienia oczekiwań klienta.
Co ważne ‼️ analogicznie jak w zarządzaniu projektami, tak i w analizie:
- jeżeli wszystkie parametry trójkąta są narzucone z góry i niezmienne, to:
- analityk przestaje być analitykiem, a jego rola sprowadza się do opisania zadań dla programistów,
- analityk nie może zagwarantować, że zostanie zapewniona odpowiednia jakość – nie ma na to wpływu.
- nie można zmienić jednego rodzaju wymagań bez wpływu na pozostałe.
Złoty trójkąt – wymagania funkcjonalne i niefunkcjonalne w praktyce
Spójrz na dwa przykłady.
Wszystkie wymiary trójkąta określone na sztywno 🫤
Powiedzmy, że wymagania zostały zdefiniowane tak:
Funkcjonalność ta umożliwi rejestrację uczniów na zajęcia sportowe. W trakcie rejestracji konieczne jest podanie danych takich jak:…. Ze względu na różny wiek osób korzystających z systemu konieczne jest zapewnienie odpowiedniej użyteczności i dostępności rozwiązania, co opisano w …. a czas reakcji systemu nie może być dłuższy niż …. Funkcjonalność ta zostanie zbudowana w oparciu o istniejącą platformę, która jest dostępna pod adresem … Będzie to więc dodatkowy moduł, zgodny wizualnie z pozostałą stroną.
Co Ty na to?
Autor wymagań opisał na sztywno wszystkie wymiary trójkąta.
Analityk nie może więc zagwarantować, że ten trójkąt się domknie. Tzn. że po zbudowaniu modułu w oparciu o istniejący system zostaną osiągnięte oczekiwane cechy jakościowe.
Wizualnie może to wyglądać tak:
Na przykład istniejąca platforma nie będzie w stanie zapewnić oczekiwanych czasów reakcji.
Co z tym zrobić?
Konieczna jest albo solidna analiza i przemodelowanie opisu tego wymagania. Jeżeli to nie pomaga, to pozostaje uzyskać podpis od autora, że bierze odpowiedzialność za wdrożenie tego modułu w taki właśnie sposób.
Trójkąt z elastycznymi powiązaniami 🫡
Powiedzmy, że po długich rozmowach autor wymagania dał się namówić na przemodelowanie opisu. Teraz wygląda on tak:
Funkcjonalność ta umożliwi rejestrację uczniów na zajęcia sportowe. W trakcie rejestracji konieczne jest podanie danych takich jak:….
Ze względu na różny wiek osób korzystających z systemu konieczne jest:
- zapewnienie odpowiedniej użyteczności i dostępności, co opisano w ….
- czas reakcji systemu nie może być dłuższy niż ….
Funkcjonalność ta musi być zgodna wizualnie z serwisem dostępnym na stronie … tzn. wykorzystywać kolory i czcionki z identyfikacji wizualnej zdefiniowanej w ….
W tym przypadku ograniczenie jest już mniej restrykcyjne. Dotyczy wyłącznie zastosowania kolorów i czcionek zgodnych z identyfikacją wizualną. Rozwiązanie może być zarówno osobnym systemem, jak i aplikacją mobilną itd.
Analityk może więc zaproponować takie rozwiązanie, które domknie cały trójkąt i sprawi, że Jakość zostanie osiągnięta.
Zauważ, że w podobny sposób można wyeliminować wymagania jakościowe i pozostawić dokładny opis rozwiązania. Wtedy to parametry niefunkcjonalne będą wynikiem konkretnej implementacji. Czyli domkną taki trójkąt, a analityk będzie mógł je co najwyżej zmierzyć (ale nie zagwarantować).
Wymagania funkcjonalne i niefunkcjonalne – podsumowanie
Podsumowując, wymagania funkcjonalne i niefunkcjonalne:
- istnieją zawsze w relacji do siebie, czyli cechy jakościowe dotyczą konkretnych funkcjonalności,
- razem z ograniczeniami i rozwiązaniami tworzą złoty trójkąt w analizie wymagań,
- taki trójkąt musi być analizowany zawsze w całości.
Zobacz też jak mierzyć wymagania niefunkcjonalne:
