Opisz zmianę w pracy, którą chcesz uzyskać.
Specyfikacja pomaga uzgodnić działanie produktu i porównać oferty. Nie musi zaczynać się od dokumentu pełnego nazw technologii. Ważniejsze jest wskazanie obecnej trudności, odbiorcy i rezultatu, który aplikacja ma umożliwić.
Przykład celu: zgłoszenie serwisowe ma trafiać do jednej kolejki z opisem i osobą odpowiedzialną. To bardziej konkretne niż „nowoczesny system do wszystkiego”. Na tej podstawie można rozpisywać funkcje, dane i wyjątki.
Zapisz także granice pierwszego etapu. Jeśli na starcie nie obejmujesz rozliczeń, powiedz to wprost. Wyłączenie nie jest brakiem jakości, jeżeli główny uzgodniony proces pozostaje użyteczny i kończy się poprawnym wynikiem.
Użytkownicy mają różne zadania.
Wskaż role oraz ich odpowiedzialność: klient zgłasza, koordynator przydziela, pracownik wykonuje, a wybrana osoba zatwierdza. Opisz, jakie informacje i działania są potrzebne każdej z tych osób. Wspólny system nie oznacza identycznego dostępu.
Dla każdej ważnej czynności zapisz, kto może ją rozpocząć, jakie warunki muszą być spełnione i co staje się widoczne po zakończeniu. Jeżeli zakończenie pracy wymaga odbioru kierownika, dodaj ten etap do scenariusza.
Uwzględnij zmianę lub odebranie dostępu. Konto osoby, która przestała wykonywać dane zadanie, nie powinno pozostać jedynym właścicielem ważnej sprawy. Role i dane warto ustalać razem.
Scenariusz ma początek, koniec i wyjątki.
Opisz, skąd użytkownik trafia do aplikacji, jakie informacje podaje i jaki wynik otrzymuje. Zapisz komunikat potwierdzenia oraz to, co musi zrobić druga strona procesu. Sam formularz nie opisuje kompletnego zlecenia lub rezerwacji.
Dodaj brak danych, błędną wartość, utratę połączenia oraz próbę powtórzenia operacji. Wyjątki nie muszą zajmować dziesiątek stron, ale powinny być widoczne w zakresie. Inaczej każda oferta może zakładać inne zachowanie.
Dla funkcji na telefonie określ potrzebne urządzenia i sposób powrotu do przerwanej czynności. Jeśli coś ma działać bez internetu, opisz dokładnie, czy jest to odczyt, szkic, czy zapis czekający na potwierdzenie.
Przykładowe wymaganie do skopiowania.
To przykład dla procesu zgłoszeń, wymagający dopasowania do firmy:
- Rola: klient z aktywnym kontem.
- Działanie: dodanie zgłoszenia z opisem i opcjonalnym załącznikiem.
- Warunek: opis zawiera informacje niezbędne do przyjęcia sprawy.
- Wynik: po potwierdzeniu zapisu klient otrzymuje identyfikator, a obsługa widzi zgłoszenie w kolejce.
- Wyjątek: przy przerwanym połączeniu interfejs nie pokazuje fałszywego potwierdzenia; wyjaśnia możliwość ponowienia.
- Odbiór: sprawdzamy zapis, widoczność obu ról, odmowę dostępu i ponowne wysłanie bez duplikatu.
Wymaganie powinno opisywać zachowanie możliwe do sprawdzenia. „Ładny i szybki formularz” nie mówi jeszcze, kiedy aplikacja poprawnie zakończyła zadanie.
Dane i integracje potrzebują właściciela.
Wymień informacje, ich źródło oraz miejsce zmiany. Cena może pochodzić z systemu sprzedaży, a status wykonania z panelu pracowników. Ustal, który zapis jest wiążący, jeżeli informacja różni się między narzędziami.
Dla integracji dołącz dokumentację, dostępne operacje i informacje o środowisku testowym. Jeżeli czegoś jeszcze nie masz, oznacz pytanie otwarte. Nie warto wpisywać „integracja z ERP” jako jednego słowa bez zakresu danych i odpowiedzialności.
Specyfikacja powinna rozróżniać potrzebne funkcje i założenia wymagające sprawdzenia. Dzięki temu wycena integracji nie opiera się na przypadkowej interpretacji tego samego hasła.
Uzgodnij materiał i kryteria odbioru.
Wskaż, co ma zostać przekazane: interfejs, działająca wersja, opis uruchomienia i dostęp do potrzebnych kont. Ustal też scenariusze, na których firma sprawdzi rezultat. Odbiór nie powinien sprowadzać się do stwierdzenia, że strona się otwiera.
Rozdziel błędy w uzgodnionym zakresie, decyzje otwarte i nowe pomysły. Przy zmianie wymagań zaktualizuj opis oraz wpływ na etap. W ten sposób specyfikacja pozostaje narzędziem współpracy, a nie dokumentem, do którego nikt nie wraca.
Na pierwszą rozmowę możesz przygotować skróconą wersję i pobrać szablon briefu. Cel, jeden pełny przebieg i najważniejsze ograniczenia często wystarczą, aby określić następny krok. Opisz swój pomysł, wskazując także to, czego jeszcze nie wiesz.
Jaką decyzję podjąć dalej?
Dla rozdzielenia szkicu, przekazania i akceptacji przeczytaj Wersja robocza i zatwierdzenie: kiedy sprawa staje się wiążąca?.
Jeżeli zadanie firmy nie jest jeszcze opisane, zacznij od Jak przygotować pomysł na aplikację?.
Od decyzji do zakresu wykonania.
Zakres związany z tą decyzją opisujemy na stronie Pierwsza wersja MVP.