Czym jest specyfikacja funkcjonalna?
Specyfikacja funkcjonalna to dokument, który opisuje szczegóły produktu cyfrowego (np. aplikacji mobilnej, webowej, systemu IoT), m.in. ideę projektu, cel biznesowy projektu, zakres prac, funkcje systemu, interakcje pomiędzy systemem a użytkownikiem, czy wymagania pozafunkcjonalne, np. wymagania odnośnie bezpieczeństwa. Dodatkowo może on zawierać opis sposobu pracy nad projektem (o ile nie ma dokument tzw. statement of work).
Specyfikacja funkcjonalna pozwala software housowi dokładnie poznać oczekiwania klienta i spełnia dwie główne funkcje:
- umożliwia wycenę projektu – jest podstawą do dokładnej wyceny przedstawionego pomysłu,
- określa, jakie prace developerskie są do wykonania – jest podstawą dla zespołu developerskiego do stworzenia produktu końcowego.
Przesłanie przez klienta specyfikacji funkcjonalnej na etapie wyceny projektu pozwala software housowi dokładnie oszacować nakłady potrzebne na zbudowanie produktu. Jest to przypadek, w którym najłatwiej zastosować wycenę w modelu fixed price, która polega na określeniu ceny “z góry” za podane funkcje systemu. (Brak takiego dokumentu niesie za sobą duże ryzyko błędnego oszacowania zasobów produkcyjnych: przeszacowania lub niedoszacowania ich i pojawienia się problemów w toku produkcji oprogramowania).
Więcej na temat tego, w jaki sposób specyfikacja funkcjonalna pomaga w wycenie oprogramowania, znajdziecie w artykule: Jakie informacje potrzebuje software house, aby wycenić projekt.
Specyfikacja funkcjonalna pozwala również zespołowi developerskiemu zrozumieć, w jaki sposób system ma funkcjonować, jest instrukcją do tego, co zbudować, i stanowi punkt odniesienia w trakcie developmentu.
Kliknij i pobierz wzór specyfikacji funkcjonalnej
Jak stworzyć specyfikację funkcjonalną?
W Appchance często otrzymujemy zapytania, które przedstawiają pomysł na stworzenie oprogramowania, a następnie współpracujemy z klientami nad wypracowaniem ostatecznej wizji produktu i jego zakresu. Stworzenie takiej specyfikacji wymaga dogłębnej wiedzy z zakresu tworzenia oprogramowania i znajomości zależności pomiędzy poszczególnymi modułami systemu, jak również pracy kilku osób z teamu: analityka biznesowego, UX designera oraz programistów. Tak przygotowany dokument, na wspólnym warsztacie produktowym, pozwala na dokładne odzwierciedlenie cech oprogramowania nie tylko pod kątem pomysłu, ale również architektury systemu. Dlatego jest to najpewniejsze rozwiązanie w zakresie budowania wzajemnego porozumienia, pozwalające zaoszczędzić czas w dalszym toku prac.
Oczywiście, klient może sam zmierzyć się z przygotowaniem takiego dokumentu (w czym dzisiaj postaramy się pomóc) i na tej podstawie zlecić software housowi przygotowanie produktu. Z naszego doświadczenia wynika jednak, że tak przygotowana specyfikacja jest mniej szczegółowa aniżeli wypracowywana wspólnie z software house’em, przez co w trakcie projektu pojawiają się pytania o doprecyzowanie poszczególnych elementów systemu. Dlatego, przygotowując samodzielnie dokument, należy zwrócić uwagę nie tylko na to, CO ma być zrobione, ale na to JAK: np. w jaki sposób ma być posortowana lista, jaki powinien być limit znaków w danym polu, jakie są przypadki brzegowe (np. jak ma zachować się aplikacja po zbanowaniu użytkownika, a następnie po cofnięciu blokady), jakie są role użytkowników panelu administracyjnego i uprawnienia dla poszczególnych ról. Im dokładniej opisany zostanie projekt, tym mniejsze ryzyko opóźnień w harmonogramie, i większa szansa na to, że dostarczony produkt spełni oczekiwania właściciela projektu.
Dlatego przed przygotowaniem specyfikacji funkcjonalnej warto również zaprojektować i spisać model biznesowy, np. wykorzystując model Business Canvas, zadecydować czy projekt będzie wdrażany i weryfikowany w swojej podstawowej formie tzw. MVP, oraz przemyśleć i zaprojektować flow aplikacji, posługując się np. user stories.
Niewątpliwie warto zainwestować swój czas lub czas software house’u w stworzenie takiej specyfikacji. Większa praca przy starcie projektu, to mniej zawirowań w toku trwania prac nad implementacją.
Co powinna zawierać specyfikacja?
Zdefiniuj cel, jaki aplikacja ma spełniać
Jaka jest główna idea aplikacji? Do czego jest przeznaczona i jaki problem rozwiązuje?
Być może jest to aplikacja do usprawnienia procesów wewnątrz firmy (np. logistyka, zarządzanie pracownikami) lub do procesów zewnętrznych (np. komunikacja, sprzedaż). Opisz cel biznesowy i preferowane zmiany po wprowadzeniu aplikacji. Wskaż, czy rozwijasz istniejąca aplikację, czy budujesz nowy produkt od podstaw.
Określ, kto będzie twoim użytkownikiem
Kto będzie korzystał z Twojej aplikacji i dlaczego? Jakim typem użytkownika będą Twoi klienci, na czym im zależy? Jakie doświadczenia ma zapewniać Twoja aplikacja?
Jeżeli posiadasz opis person, dane rynkowe na temat swoich użytkowników, analizy behawioralne lub kluczowe wnioski z analiz, to jest moment, w którym możesz je przedstawić zespołowi tak, aby ten lepiej zaprojektował system. Opisz typy użytkowników, jakie będą występowały w ramach systemu oraz ich kluczowe role.
Wylistuj wszystkie funkcje
Jakie czynności, akcje użytkownik będzie mógł podejmować poprzez aplikacje? W jaki sposób aplikacja będzie prowadziła użytkownika przez kolejne swoje funkcje od momentu zalogowania się? Czy występuje jakaś sekwencja akcji podejmowanych przez użytkownika?
Przykładowymi funkcjami w aplikacji mogą być: logowanie się, przeglądanie produktów, porównywanie produktów, kupowanie produktów, śledzenie przesyłki, wysyłanie wiadomości, otrzymywanie notyfikacji push, geolokalizacja. Określ priorytety poszczególnych funkcji i wskaż, które stanowią kluczową część aplikacji, a które opcjonalną. Rozpisz, jakie elementy mają być uwzględnione na poszczególnych ekranach i jak mają się zachowywać, jaką pełnić rolę, jakie stany mogą przyjmować.
Zdefiniuj integracje ze wszystkimi systemami
Czy aplikacja będzie musiała się integrować z np. systemem kasowym, twoim CRM-em, social mediami, innymi platformami? Z jakimi systemami będzie musiała współpracować aby spełniać swoje funkcje?
Jeżeli posiadasz dokumentację API, czy hardware’u, z którym aplikacja powinna się łączyć, lub informacje na temat systemów, z którymi aplikacja powinna być zintegrowana (np. płatności), opisz to w specyfikacji.
Określ zakres współpracy i dostarczane materiały
Za jakie obszary rozwoju aplikacji będzie odpowiadał wybrany software house, a za jakie Twoja firma lub inni podwykonawcy? Czy po twojej stronie jest dostarczenie API, designu, makiety, copywriting?
Jeżeli dostarczasz potrzebne materiały – określ w dokumencie czy poszczególne elementy są gotowe, czy w trakcie przygotowywania i zadeklaruj termin przekazania ich.
Informacje dodatkowe
Na różnych etapach negocjacji z podwykonawcą mogą pojawić się pytania dodatkowe oraz inne dokumenty, jak: brief czy statement of work, które pomogą określić współpracę, np. ograniczenia i zasoby (budżet, deadline), ryzyka projektowe, wcześniej wspomniany sposób pracy nad projektem, zaangażowane osoby oraz sposób komunikacji czy benchmarki innych aplikacji.
14 pytań, które pozwolą Ci przygotować specyfikację aplikacji
Przed rozpoczęciem tworzenia specyfikacji aplikacji mobilnej czy webowej warto zadać sobie następujące pytania:
- Jaka jest główna idea Twojej aplikacji, jaki cel biznesowy spełnia?
- Czy jest to aplikacja budowana od początku czy rozwój istniejącej aplikacji?
- Kto jest użytkownikiem Twojej aplikacji?
- Na jakie platformy (Android, iOS, web) i wersje systemu ma zostać zaimplementowana aplikacja?
- Na jakie urządzenia powinna zostać zaprojektowana aplikacja (smartfon, tablet, desktop)?
- Jakie funkcje powinna mieć aplikacja (co użytkownik dzięki niej będzie mógł robić)?
- Czy aplikacja będzie posiadała moduły takie jak: logowanie, zakup w aplikacji, moduł płatności, notyfikacje push, geolokalizacja?
- Czy aplikacja będzie integrowała się z zewnętrznymi systemami: CMS, urządzenia (hardware), synchronizacja w chmurze, beacony, Bluetooth, social media?
- Czy aplikacja powinna mieć podpięte moduły analityczne (np. Google Analytics)? Czy będą wymagane pogłębione analizy zachowania użytkowników w aplikacji (wtedy zwykle konieczna jest dodatkowa konfiguracja po stronie Google Analytics oraz wdrożenie w aplikacjach)
- Jakie materiały zostaną dostarczone software house’owi: designy, copywriting, API wraz z dokumentacją?
- Czy zamawiający posiada konta na Google Play i AppStore i sam będzie publikował aplikację?
- Jakie prace powinny zostać wykonane po stronie software house’u: warsztaty produktowe, UX/UI design, development, testy, strategia rozwoju produktu, utrzymanie projektu?
- Jakie są wykluczenia w projekcie, tzn. co wychodzi poza obszar prac software house’u (np. prace związane z konfiguracją serwera, instalacją domen i certyfikatów)?
- Jaki jest harmonogram i planowany budżet?
Odpowiedzi na powyższe pytania pozwolą na jasne sprecyzowanie wymagań produktowych, a co za tym idzie – na prawidłowe zbudowanie specyfikacji funkcjonalnej. Screen jednego z tak przygotowanego dokumentów, będącego wynikiem współpracy pomiędzy nami a jednym z naszych zagranicznych klientów załączamy poniżej.
Specyfikacja funkcjonalna spis treści
Jak można zauważyć, każda funkcja stanowi osobny podrozdział, przez co sam dokument jest dość rozbudowany.
Przykładowa specyfikacja funkcjonalna aplikacji
KLIKNIJ I POBIERZ WZÓR SPECYFIKACJI FUNKCJONALNEJ
Specyfikacja funkcjonalna w trakcie procesu developmentu
Budując specyfikację funkcjonalną, powinniśmy zastanowić się, które elementy są istotne w drodze do osiągnięcia założonego celu. Dlatego w zależności od projektu specyfikacja będzie mniej lub bardziej obszerna.
Często okazuje się, że w trakcie rozwoju produktu i testowania jego poszczególnych modułów ostateczna wizja projektu zmienia się. Weryfikując oprogramowanie, klient widzi czego brakuje, co dobrze byłoby zrobić inaczej, co należy dodać. W takim przypadku wraz z nowymi postanowieniami należy zaktualizować specyfikację funkcjonalną.
To jak dobrze zdefiniowany zostanie produkt będzie miało przełożenie na to, czy produkt będzie spełniał wymagania klienta i odzwierciedlał jego ostateczne wyobrażenia. Każde niedopowiedzenie to późniejsza strata w zaplanowanych godzinach w harmonogramie, dlatego bardzo ważne jest wzajemne zrozumienie swoich intencji i zakresów działania.
