- Biznes
- Oprogramowanie
Wymagania niefunkcjonalne aplikacji – czym są i jak je poprawnie opisać w specyfikacji projektu?
Właściwe określenie wymagań funkcjonalnych i niefunkcjonalnych aplikacji to niezwykle istotny krok, jeśli planujesz stworzenie nowego produktu IT we współpracy z software house’m. Sprecyzowanie oczekiwań wpływa na efektywność procesu tworzenia oprogramowania, a także pozwala developerom lepiej zrozumieć Twoje cele i wizję produktu, a tym samym dobrze przygotować się do działania.
Badania wskazują, że 30% projektów IT ponosi porażkę ze względu na błędnie sformułowane wymagania, dlatego warto już teraz zwiększyć swoje szanse na sukces. Aby cały ten proces przebiegł pomyślnie, konieczne jest dokładne zrozumienie czym są wymagania niefunkcjonalne aplikacji, jakich obszarów dotyczą, a także jak je opisać w specyfikacji technicznej.
Spis treści
Wymagania niefunkcjonalne aplikacji – definicja i rola w procesie tworzenia produktu
Wymagania niefunkcjonalne określają przede wszystkim oczekiwania co do samej jakości działania aplikacji oraz pożądanego zachowania tworzonego systemu. Innymi słowy, za ich pomocą należy opisać kryteria jakościowe w jakich ma działać Twój produkt. Najczęściej są one determinowane przez typ aplikacji, jaką zamierzasz stworzyć, Twoje cele biznesowe, wielkość budżetu i rodzaj grupy docelowej. Z kolei wymagania funkcjonalne, jak sama nazwa wskazuje, odnoszą się do opisu konkretnych funkcjonalności danej aplikacji.
Na jakich obszarach najlepiej się skupić opisując wymagania niefunkcjonalne? Weź pod uwagę kwestie związane z szybkością aplikacji, bezpieczeństwem, wydajnością, rodzajem przeglądarki, do jakiej ma być dostosowana, użytecznością, dostępnością, a także sposobem jej wdrożenia. Wybrane obszary omówimy osobno w kolejnej części artykułu.
Tak jak wspomnieliśmy na początku, jasno zaprezentowana klasyfikacja wymagań funkcjonalnych i niefunkcjonalnych odgrywa niezwykle ważną rolę w całym procesie tworzenia aplikacji. Ich określenie jest istotne nie tylko z punktu widzenia biznesowego, ale również z perspektywy software house’u, z którym rozpoczniesz współpracę. Wpływają one na szereg działań, w tym m.in. wybór właściwej architektury systemu.
Ponadto określenie już na samym początku kwestii związanych z bezpieczeństwem aplikacji, bez wątpienia pozwoli na oszczędność kosztów i czasu. Podjęcie takiej decyzji w trakcie prac może przynieść więcej szkody niż pożytku – w niektórych sytuacjach zapewnienie bezpieczeństwa aplikacji w późniejszym etapie może być bardzo kosztowne. Wiedząc od samego początku na jakie rozwiązania będziesz się decydować, zminimalizujesz ryzyko niespodzianek finansowych w przyszłości.
Jak najlepiej zgromadzić wymagania aplikacji?
Zastanawiasz się, skąd czerpać wiedzę o wymaganiach niefunkcjonalnych i jak je najlepiej określić? Dobrym rozwiązaniem może być udział w warsztatach produktowych, którą ważną częścią jest Event Storming. Choć w dużej mierze ich celem jest przeanalizowanie wymagań funkcjonalnych; często są źródłem dyskusji również o obszarach niefunkcjonalnych. Szerokie spojrzenie na produkt i przeanalizowanie procesów w nim zachodzących zdecydowanie ułatwia zgromadzenie kluczowych informacji w związku z wymaganiami funkcjonalnymi i niefunkcjonalnymi.
Realne przykłady wymagań niefunkcjonalnych
Poniżej wymieniamy obszary wraz z konkretnymi przykładami wymagań niefunkcjonalnych, które warto opisać w specyfikacji projektu IT.
Dostępność/Niezawodność
Kiedy użytkownicy będą mogli korzystać z aplikacji? Opisując wymagania niefunkcjonalne z zakresu dostępności należy wskazać, czy:
- aplikacja ma być dostępna w systemie 24/7/365,
- aplikacja będzie dostępna przez określoną ilość lat.
Wydajność
Opis wydajności jest kluczowy w celu zbudowania sprawnie działającej aplikacji, która odpowiednio obsłuży przewidywany ruch użytkowników. W związku z tym konieczne będzie określenie:
- maksymalnej ilości użytkowników korzystających jednocześnie z aplikacji,
- lokalizacji, z jakich mogą pochodzić potencjalni użytkownicy,
- maksymalnego czasu odpowiedzi aplikacji na zapytanie użytkownika,
- sposobu, w jaki aplikacja korzysta z zasobów sprzętowych.
Wsparcie
Określ rodzaj wsparcia (przykładowo, czy będzie zapewniane wewnętrznie, czy zewnętrznie), które będzie niezbędne w razie awarii aplikacji. Wskaż:
- sposób, w jaki użytkownicy mogą zgłaszać błędy,
- sposób, w jaki aplikacja będzie monitorowana,
- maksymalny czas potrzebny do naprawienia błędów (z podziałem na odpowiednie rodzaje błędów),
- sposób testowania aplikacji.
Bezpieczeństwo
Zapewnienie bezpieczeństwa aplikacji to jeden z istotnych elementów związanych z tworzeniem takiego produktu. Określ stopień zabezpieczenia danych aplikacji przez ewentualnych atakami z zewnątrz, wskazując przykładowo:
- najważniejsze zagrożenia, na które może być narażona aplikacja,
- pożądane sposoby zabezpieczenia aplikacji,
- czy są wymagane inne, dodatkowe kwestie bezpieczeństwa (przykładowo związane z przechowywaniem danych – np. RODO).
Wdrożenie
Dotyczy wszelkich kwestii dotyczących sposobu wdrożenia aplikacji i wytycznych w tym zakresie. Należy wskazać przykładowo:
- w jakim czasie nastąpi wdrożenie aplikacji,
- do jakich grup osób skierowany jest produkt i ilu użytkowników będzie z niego korzystać w poszczególnych etapach rozwoju,
- rodzaje integracji niezbędnych we wdrożeniu,
- wskazówki odn. pożądanej architektury aplikacji lub konkretnych wymaganych języków programowania / frameworków.
Użyteczność aplikacji
Te wymagania dotyczą wyglądu interfejsu aplikacji i koncentrują się na sposobie interakcji z produktem. W sytuacji, gdy nie masz gotowego projektu graficznego aplikacji lub przykładowo aplikacja dotyczy wyłącznie backoffice’wego systemu, warto zaprezentować:
- informacje dotyczące kolorystyki i designu,
- rozmiar ekranu (czy wymagana jest responsywność),
- sposób oznaczeń poszczególnych elementów aplikacji,
- rozmiar i wygląd przycisków CTA, itp.
- rozmiar i rodzaj czcionki.
Jak właściwie opisać wymagania niefunkcjonalne w specyfikacji technicznej?
Wiedząc, czym dokładnie są wymagania niefunkcjonalne aplikacji i mając już odpowiedni zasób wiedzy na temat właściwości produktu, bardzo istotne jest spisanie wszystkiego w dokumentacji technicznej. Tak jak wspomnieliśmy na początku artykułu, właściwe opisane wymaganie funkcjonalne w dużej mierze wpływa na późniejsze powodzenie projektu. Jeśli zastanawiasz się, jak powinna wyglądać cała specyfikacja techniczna, zajrzyj do artykułu, gdzie kompleksowo opisujemy zawartość tego dokumentu.
Omówmy teraz kilka kluczowych rzeczy, o których należy pamiętać podczas ustawiania i dokumentowania wymagań dotyczących jakości oprogramowania.
Kilka kluczowych aspektów dotyczących wymagań niefunkcjonalnych:
Powinny być możliwe do zmierzenia i testowania
Nie wystarczy stwierdzenie, że oprogramowanie powinno być po prostu „przyjazne dla użytkownika” lub „wygodne”, zamiast tego trzeba wskazać różne miary lub liczby, które określiłyby skuteczność Twojego produktu. Im dokładniej będą ustalone standardy (np. dokładny czas odpowiedzi strony), tym większe szanse masz na pokonanie przeszkód podczas developmentu oraz wdrożenie projektu.
Standardy trzeba ustalić dla komponentów systemu, a nie dla całych produktów.
Aby wymagania były jasne i konkretne od początku, zastanów się, które krytyczne interfejsy i systemy wymagają takich wymagań. Ważne jest by jak najszybciej ustalić określone funkcje interfejsu, z którymi użytkownicy najczęściej wchodzą w interakcję i skonfigurować wymagania dotyczące wydajności.
Wymagania niefunkcjonalne muszą współdziałać z celami biznesowymi.
Analiza celów biznesowych jest konieczna do przedyskutowania między interesariuszami a architektem projektu. Dotyczy to wielu aspektów, takich jak analiza bieżącej sytuacji rynkowej, czy konkurencji. W celu pomiaru działań użytkowników na stronie takich jak np. analiza systemów operacyjnych użytkowników, przeglądarek, sieci, wymagań sprzętowych, warto skorzystać z narzędzi analitycznych, takich jak np. Google Analytics. Jest to istotne, ponieważ na przykład kilkuminutowa różnica w dostępności systemu może nie mieć drastycznego wpływu na wyniki sprzedaży, ale czasami może oznaczać dodatkowe tygodnie prac deweloperskich.
Weź pod uwagę ograniczenia ze strony architektury systemu
Jeśli masz do czynienia ze starszym systemem, konieczna może być zmiana całej architektury w celu poprawy wydajności. Może to dotyczyć np. interfejsu API, który wolniej przywraca dane. Podobnie jest ze starszym kodem, który może wymagać nie tylko refaktoryzacji, ale całkowitej zmiany, jeśli ma spełniać określone wymagania.
Sprawdź już istniejące standardy
Okazuje się, że wiele zaleceń dotyczących jakości systemu zostało już wcześniej sformułowanych. Dlatego warto sprawdzać wcześniej już ustalone wytyczne dotyczące np. aplikacji na iOS lub Androida, aby zasugerować niektóre wymagania dla swojej aplikacji.
Na co jeszcze warto zwrócić uwagę przy opisie wymagań niefunkcjonalnych?
Sama forma nie musi mieć konkretnego schematu – dokładny opis w punktach będzie wystarczający i czytelny. Poniżej zamieszczamy przykłady wybranych opisów:
- aplikacja musi obsłużyć jednocześnie 2000 użytkowników,
- produkt działa na przeglądarkach internetowych takich jak Internet Explorer,
- aplikacja odpowie na żądanie użytkownika w ciągu 3 s.
Przygotowanie wymagań niefunkcjonalnych wcale nie musi być trudne. Posiadając skonkretyzowane oczekiwania dotyczące właściwości produktu, zdecydowanie łatwiej będzie przelać ideę na papier. Jeśli jednak nie masz pewności co do funkcjonalności aplikacji i chcesz przeanalizować jej działanie, weź udział w warsztatach produktowych, które pomogą Ci zrozumieć najważniejsze procesy w niej zachodzące.
Skontaktuj się z nami i otrzymaj darmową konsultację – doradzimy Ci i zaproponujemy najlepsze rozwiązania dla Twojego biznesu.
