Specyfikacja aplikacji mobilnej: jak ją napisać w 2027 roku

Czym jest specyfikacja aplikacji i czym różni się od briefu

Specyfikacja (w zleceniach IT często nazywana też zakresem prac lub specyfikacją wymagań) to dokument, w którym zapisano, co dokładnie ma umieć aplikacja i po czym poznasz, że jest gotowa. Czytają go trzy osoby naraz: Ty, projektant i programista. Jeśli wszyscy rozumieją tekst tak samo, znika główne źródło sporów w projektach: „myślałem, że to wchodzi w cenę”.

Nie myl trzech dokumentów. Brief odpowiada na pytania „po co” i „dla kogo”: cel, odbiorcy, rynek, budżet. Specyfikacja odpowiada na pytanie „co dokładnie ma działać”: ekrany, działania, reguły, dane. Wycena odpowiada na pytanie „ile i kiedy” i powstaje już na podstawie specyfikacji. Brief na stronę omawialiśmy w artykule brief i zakres prac na stronę internetową, a przy aplikacji wymagań jest więcej: telefon, sklepy z aplikacjami, powiadomienia, praca bez internetu.

Dobra wiadomość: nie musisz pisać specyfikacji jak inżynier na 80 stron. Wystarczą 3–6 stron prostego tekstu według wzoru poniżej. Wykonawca dopisze szczegóły techniczne sam, ale nie wymyśli za Ciebie, czego potrzebuje Twoja firma.

Jest jeszcze jedna korzyść: specyfikacja pozwala dostać porównywalne oferty. Gdy pięć firm wycenia ten sam dokument, ceny można uczciwie położyć obok siebie. Gdy każda wycenia własną wersję pomysłu, nie ma czego porównywać.

Wzór specyfikacji aplikacji mobilnej: 10 sekcji

Skopiuj tę listę do dokumentu i uzupełnij każdy punkt, choćby jednym–dwoma zdaniami. Pusta sekcja to pytanie, które i tak trzeba będzie rozstrzygnąć, tyle że później i drożej.

1. Cel i mierzalny wynik. Jedno zdanie: „klienci sami się zapisują, a 30% zapisów przychodzi przez aplikację”. Liczba nie jest obowiązkowa, ale wtedy napisz, po czym poznasz sukces.
2. Użytkownicy i role. Kto korzysta: klient, specjalista, administrator, kurier. Każda rola ma własne ekrany i uprawnienia.
3. Platformy. iOS, Android lub obie; czy potrzebny jest tablet; czy wystarczy strona instalowana na telefonie jak aplikacja (PWA), czy trzeba wejść do sklepów z aplikacjami. Jeśli się wahasz, najpierw porównaj aplikację, stronę i PWA pod względem kosztów i zadań.
4. Mapa ekranów. Lista wszystkich ekranów i strzałki między nimi: logowanie, ekran główny, katalog, karta, koszyk, profil. Można narysować ręcznie i zrobić zdjęcie.
5. Scenariusze. Krok po kroku, co robi człowiek: „otworzył, wybrał usługę, wybrał godzinę, zapłacił, dostał przypomnienie”.
6. Funkcje z priorytetami. Trzy kolumny: „bez tego nie uruchamiamy”, „dobrze byłoby mieć”, „później”. To najważniejsza sekcja dla budżetu.
7. Dane i integracje. Gdzie przechowywani są użytkownicy i zamówienia, z czym się łączymy: płatności, CRM, księgowość, mapy, poczta, komunikatory.
8. Wymagania niefunkcjonalne. Szybkość, praca bez internetu, języki, bezpieczeństwo, dostępność (szczegóły niżej).
9. Publikacja i konta. Na czyje dane zakłada się konta deweloperskie, kto pisze opisy do sklepów, jakie kraje.
10. Odbiór i etapy. Jak sprawdzamy wynik, ile rund poprawek, jak dzielimy płatność na etapy.

Do każdego punktu warto dodać przykłady aplikacji, które Ci się podobają, i jedno zdanie o tym, co dokładnie. „Chcę jak Uber” nic nie mówi, a „chcę, żeby mapa z punktami wyglądała jak w Uberze, a rejestracja była po numerze telefonu” mówi wszystko.

Wymagania aplikacji mobilnej: funkcjonalne i niefunkcjonalne

W dokumencie z wymaganiami (po angielsku app requirements document) zwykle są dwa rodzaje zapisów. Funkcjonalne opisują, co aplikacja robi: „użytkownik może przenieść wizytę najpóźniej na 2 godziny przed terminem”. Niefunkcjonalne opisują, jak dobrze to robi: szybko, bezpiecznie, zrozumiale, w odpowiednich językach. To właśnie o tych drugich najczęściej się zapomina, a potem się o nie spiera.

Przykład dla aplikacji do rezerwacji wizyt w salonie

Rola „klient”. Rejestracja po numerze telefonu z kodem z SMS. Katalog usług z ceną i czasem trwania. Wybór specjalisty i wolnego terminu. Przedpłata kartą. Przypomnienie na dobę i na 2 godziny przed wizytą. Odwołanie bezpłatne najpóźniej 24 godziny przed terminem. Rola „administrator”: grafik specjalistów, lista rezerwacji, zwroty, mailing z promocjami.

To część funkcjonalna. Dodajemy do niej niefunkcjonalną:

• Szybkość. Ekran główny otwiera się bez zauważalnego opóźnienia na przeciętnym telefonie sprzed pięciu lat.
• Łączność. Co widzi klient bez internetu: ostatnią rezerwację czy komunikat o błędzie? Pełny tryb offline kosztuje osobno.
• Języki i waluty. Ile języków interfejsu, w jakiej walucie ceny, jak wyglądają daty.
• Bezpieczeństwo i dane. Jakie dane osobowe są przechowywane, kto je widzi, jak człowiek usuwa swoje konto. Jeśli działasz w Twoim kraju, wymagania dotyczące danych osobowych omów z prawnikiem: w Polsce i całej UE obowiązuje RODO.
• Dostępność. Duża czcionka, kontrast, opisy dla czytników ekranu. To i wygoda, i wymóg na niektórych rynkach.
• Urządzenia. Od jakiej wersji iOS i Androida obsługujemy i na jakich ekranach testujemy.

Nie zapomnij o części „niewidocznej”: większość aplikacji ma panel administratora, w którym zespół zarządza treściami i zamówieniami. W specyfikacji zapisuje się go osobną sekcją, inaczej okaże się, że aplikacja jest gotowa, a nie ma jak nią zarządzać.

Co zapisać w specyfikacji o App Store i Google Play

Publikacja to osobny etap z własnymi regułami i wpływamy na nią nie tylko my. Dlatego w specyfikacji warto z góry zapisać kilka punktów.

• Konta deweloperskie. Apple pobiera 99 $ rocznie, Google Play 25 $ jednorazowo. Aplikację rejestrujemy na Twoje konto, więc zapisz, kto je założy i kto przechowuje dostępy.
• Gotowa wersja do sprawdzenia. Według wytycznych Apple (sekcja 2.1, „kompletność aplikacji”) do weryfikacji wysyła się skończoną wersję: bez zaślepek i tymczasowych stron, z działającymi linkami, a jeśli jest logowanie, z kontem demo dla recenzenta, przy czym serwer musi w tym czasie działać. W specyfikacji zamienia się to w punkt odbioru: „konto testowe i opis dla recenzenta gotowe”.
• Testy dla Google Play. Dla nowych kont osobistych Google wymaga testów zamkniętych: co najmniej 12 testerów zapisanych przez 14 dni z rzędu, i dopiero potem otwiera publikację dla wszystkich. Wlicz te dwa tygodnie w termin albo załóż konto organizacji; aktualne warunki sprawdź w pomocy Google Play.
• Teksty i grafiki do sklepów. Opis, zrzuty ekranu, polityka prywatności, ocena wiekowa. Kto je pisze i w jakich językach.
• Płatności. Jeśli w aplikacji sprzedaje się produkty cyfrowe lub subskrypcje, sklepy mają własne zasady i prowizje. Dla towarów fizycznych i usług reguły są inne. Zapisz, co sprzedajesz, a wykonawca podpowie właściwy model.

Terminy weryfikacji w sklepach od nas nie zależą, dlatego nigdy nie obiecujemy dokładnej daty pojawienia się w sklepie. Więcej o samych krokach publikacji w artykule jak stworzyć aplikację mobilną: od pomysłu do App Store.

Pięć błędów w specyfikacji, przez które rosną terminy i cena

1. Brak priorytetów. Gdy wszystko jest „bardzo potrzebne”, wycena obejmuje wszystko, a pierwszą wersję uruchamiasz po pół roku zamiast po dwóch miesiącach. Podziel funkcje na „obowiązkowe”, „dobrze byłoby” i „później”.
2. Brak kryteriów odbioru. „Ładnie i wygodnie” nie da się sprawdzić. „Rezerwacja powstaje w nie więcej niż czterech dotknięciach” da się.
3. Zapomniany panel i role. Aplikacja dla klienta to połowa produktu. Drugą połową jest narzędzie Twojego zespołu.
4. Rozmyte integracje. „Połączyć z CRM” oznacza inny zakres prac dla różnych systemów. Podaj nazwę systemu i opisz, jakie dane dokąd trafiają.
5. Brak odpowiedzialnej osoby. Jeśli decyzje po Twojej stronie podejmują trzy osoby, projekt hamuje na uzgodnieniach. Wyznacz jedną, która mówi „tak” lub „nie”.

Częsta pułapka to też pisanie specyfikacji na gotowy „idealny produkt”. Lepiej opisać pierwszą wersję, która sprawdza pomysł na prawdziwych ludziach, a osobną listą wszystko, co dodasz, jeśli się sprawdzi. Jak wygląda taka pierwsza wersja i ile kosztuje, wyjaśnia artykuł MVP: co to jest i ile kosztuje stworzenie.

Sprawdź, czy specyfikacja jest gotowa do wyceny

Przejdź krótką listę kontrolną poniżej. Pokazuje, czy dokument można już wysyłać wykonawcom, czy najpierw warto uzupełnić braki. Jeśli na większość punktów odpowiadasz „nie”, to nic strasznego: część pytań można rozstrzygnąć razem z wykonawcą i jesteśmy na to gotowi.

Kto powinien pisać specyfikację: Ty, wykonawca czy razem

Są trzy działające scenariusze, a wybór zależy od tego, jak jasny jest Twój pomysł.

• Piszesz sam według wzoru. Pasuje, gdy pomysł jest prosty, a Ty znasz swoich odbiorców. Dostaniesz kilka wycen i porównasz je.
• Wykonawca pisze na podstawie Twojego briefu. Wygodne, ale pamiętaj: im dokładniejszy dokument, tym dokładniejsza wycena. Darmowa specyfikacja bywa „specyfikacją pod naszą cenę”, więc zapytaj, do kogo należy, jeśli wybierzesz inny zespół.
• Płatna praca przed projektem. Przy złożonych produktach (role, płatności, kilka systemów) robimy to osobnym etapem: sesja architektoniczna za 3 500 €. Na wyjściu dostajesz mapę produktu, wycenę i plan pierwszej wersji. Ta kwota jest zaliczana na poczet projektu, a sama mapa zostaje u Ciebie w każdym wypadku, nawet jeśli potem wybierzesz inny zespół.

Jeśli potrzebujesz ekranów, a nie tylko tekstu, dodaj projekt i prototyp od 1 990 €: klikalny prototyp na telefonie tłumaczy pomysł lepiej niż dziesięć stron opisu. W gotowych pakietach aplikacji projekt jest już w cenie.

Jak wybrać, komu powierzyć dokument i sam projekt, opisuje artykuł jak wybrać agencję tworzącą strony internetowe i uniknąć błędów: te same pytania pasują do wykonawców aplikacji. A ile kosztuje sama aplikacja, sprawdzisz w artykule ile kosztuje stworzenie aplikacji mobilnej.

Co wybrać w Twojej sytuacji

• Pomysł jest prosty: jeden scenariusz, jedna rola. Wypełnij wzór sam, wyślij do dwóch–trzech zespołów i porównaj odpowiedzi. Aplikacja na iOS i Androida kosztuje u nas od 10 900 €, dokładną kwotę liczymy w wycenie po specyfikacji.
• Jest kilka ról, płatności, integracje. Nie pisz wszystkiego po omacku: zacznij od sesji architektonicznej i dostań specyfikację w formie mapy produktu i wyceny.
• Nie masz pewności, czy aplikacja w ogóle jest potrzebna. Być może wystarczy strona na telefonie albo aplikacja w Telegramie. Porównaj warianty i koszty, zanim zaczniesz pisać dokument.
• Specyfikację ma już inna firma. Pokaż ją nam i innym wykonawcom: jeden dokument, kilka ofert. Jak uczciwie porównać odpowiedzi, wyjaśnia artykuł jak porównać oferty na stronę internetową i aplikację.
• Musisz ruszyć jak najszybciej. Opisz tylko funkcje obowiązkowe, a resztę przenieś do drugiej wersji.

Nie wiesz, od czego zacząć? Opisz nam pomysł w krótkim briefie, a podpowiemy, które sekcje specyfikacji warto dopracować najpierw i czy zacząć od sesji architektonicznej w Twoim mieście lub zdalnie. Jak przebiega praca krok po kroku, zobaczysz na stronie jak pracujemy.