Jak opisać wymagania do aplikacji webowej, żeby projekt ruszył szybciej

Żeby projekt aplikacji webowej ruszył szybciej, wymagania nie muszą być pełną specyfikacją techniczną – wystarczy dokument, który jasno odpowiada na osiem pytań: po co powstaje aplikacja, kto będzie z niej korzystał, jakie procesy obsługuje, na jakich danych pracuje, z czym się integruje, co jest konieczne w pierwszej wersji, po czym poznamy, że funkcja działa, i jakie są ograniczenia. Poniżej znajdziesz gotowy szablon takiego briefu z przykładami, który możesz wypełnić przed pierwszą rozmową z software house’em.

Dlaczego szablon, a nie wolny opis

Wolny opis w mailu zwykle mówi dużo o pomyśle, a mało o tym, co zespół ma zbudować. Brakuje w nim zwykle ról, danych i kryteriów akceptacji, więc pierwsze spotkania schodzą na dopytywanie. Szablon wymusza odpowiedzi na pytania, które i tak padną. Dzięki niemu:

• różni dostawcy dostają ten sam materiał, więc ich propozycje da się porównać,
• łatwiej wskazać, co wchodzi do pierwszej wersji, a co może poczekać,
• po stronie firmy widać luki – np. że nikt nie wie, kto ma zatwierdzać zamówienia powyżej limitu.

Brief nie musi być długi. Kilka stron konkretów jest lepsze niż kilkadziesiąt stron ogólników.

Szablon wymagań – sekcja po sekcji

1. Cel biznesowy

Jedno lub dwa zdania: jaki problem rozwiązuje aplikacja i dla kogo. Dobrze, jeśli cel da się sprawdzić. Przykład: „Handlowcy przestają przepisywać zamówienia z maili do ERP – zamówienia klientów stałych trafiają do systemu bez ręcznej pracy”. Źle: „Chcemy nowoczesny system do zarządzania sprzedażą”.

2. Użytkownicy i role

Wypisz grupy użytkowników, a przy każdej – co robi w systemie i czego nie może robić:

• klient – zamawiający – składa zamówienia, widzi swoje ceny i dokumenty,
• klient – administrator konta – dodaje pracowników swojej firmy i nadaje im limity,
• handlowiec – widzi swoich klientów, zatwierdza nietypowe zamówienia,
• administrator – zarządza słownikami, użytkownikami i konfiguracją.

Podaj też przybliżoną skalę: kilka osób w biurze czy kilkuset klientów logujących się z telefonu na budowie. To wpływa na architekturę bardziej niż lista ekranów.

3. Procesy – jak jest dziś i jak ma być

Opisz dwa–trzy najważniejsze procesy w formie kroków. Najpierw stan obecny („klient wysyła mail z Excelem, handlowiec przepisuje go do ERP, potem dzwoni z potwierdzeniem terminu”), potem stan docelowy. Zaznacz wyjątki: co się dzieje, gdy towaru brakuje, gdy klient przekroczy limit, gdy zamówienie trzeba poprawić. Wyjątki są tym, co najczęściej wydłuża projekt, jeśli wyjdą dopiero w trakcie.

4. Dane

Jakie obiekty przechowuje aplikacja (klient, produkt, zamówienie, dokument, zgłoszenie) i skąd pochodzą. Dołącz przykładowe pliki: eksport z ERP, arkusz z cennikiem, wzór dokumentu. Zanonimizowana próbka realnych danych mówi zespołowi więcej niż opis słowny. Zapisz też, ile jest mniej więcej rekordów i jak szybko przybywa nowych.

5. Integracje

Lista systemów, z którymi aplikacja ma wymieniać dane: ERP, CRM, sklep, system kurierski, płatności, mailing. Dla każdego: jaki to system i wersja, czy ma API, kto po stronie firmy lub dostawcy zna jego konfigurację. Jeśli chcesz uporządkować to szerzej, pomocna będzie mapa przepływów danych w firmie B2B.

6. Priorytety MoSCoW

Każdą funkcję przypisz do jednej z czterech grup:

• Must have – bez tego pierwsza wersja nie ma sensu (np. logowanie klientów, katalog z indywidualnymi cenami, składanie zamówień),
• Should have – ważne, ale da się wystartować bez tego (np. historia faktur),
• Could have – miłe dodatki (np. lista ulubionych produktów),
• Won’t have (this time) – świadomie odłożone na później (np. aplikacja mobilna).

Grupa „Won’t have” jest równie ważna jak „Must have”. Zapisanie, czego nie robimy, chroni przed rozrastaniem się zakresu.

7. Kryteria akceptacji i user stories

Najważniejsze funkcje opisz jako historie użytkownika z kryteriami, które da się sprawdzić:

• „Jako zamawiający po stronie klienta chcę wgrać plik CSV z indeksami i ilościami, aby nie wpisywać ręcznie długiego zamówienia.” Kryteria: system akceptuje plik z kolumnami indeks i ilość; nieznane indeksy są wyświetlane jako lista błędów; poprawne pozycje trafiają do koszyka.
• „Jako handlowiec chcę dostać powiadomienie o zamówieniu powyżej limitu kupieckiego klienta, aby zdecydować o jego realizacji.” Kryteria: zamówienie ma status „do zatwierdzenia”; handlowiec widzi je na liście; decyzja jest zapisana w historii.
• „Jako administrator konta klienta chcę dodać nowego pracownika z prawem tylko do podglądu, aby mógł sprawdzać statusy bez składania zamówień.”

Kryteria akceptacji są później podstawą testów i odbioru – dzięki nim „gotowe” znaczy to samo dla obu stron.

8. Ograniczenia i wymagania niefunkcjonalne

Tu wpisz rzeczy, które nie są funkcjami, ale wpływają na projekt: wymagane języki interfejsu, dostępność na urządzeniach mobilnych, wymagania bezpieczeństwa i RODO, miejsce hostingu, oczekiwany termin startu (np. przed sezonem), budżet lub przedział, w którym się mieścicie, oraz kto po stronie firmy podejmuje decyzje.

Czego nie wpisywać do briefu

• Wyboru technologii „na zapas” – jeśli nie masz twardych powodów (zespół wewnętrzny, istniejące systemy), zostaw decyzję o stacku zespołowi i poproś o uzasadnienie. Kryteria takiego wyboru opisujemy we wpisie Jak wybrać stack technologiczny dla aplikacji B2B.
• Gotowych projektów ekranów jako wymagań – szkice pomagają, ale lepiej opisać, co użytkownik ma osiągnąć, niż gdzie ma być przycisk.
• Funkcji „bo konkurencja ma” – każda funkcja powinna mieć właściciela i powód.

Typowe błędy w wymaganiach

1. Brak właściciela procesu – nikt nie potrafi rozstrzygnąć, jak ma działać wyjątek.
2. Wszystko jest „Must have” – wtedy priorytety nie istnieją.
3. Opis ekranów zamiast procesów – zespół buduje formularze, które nie pasują do rzeczywistej pracy.
4. Pominięte integracje – „a, jeszcze synchronizacja z ERP” na etapie odbioru to najdroższa niespodzianka.
5. Brak danych testowych – funkcje działają na trzech przykładowych produktach, a nie na realnym katalogu.

Co dzieje się z briefem dalej

Dobry brief nie zastępuje etapu analizy, ale go skraca. Zespół czyta dokument, zadaje pytania uzupełniające, a potem proponuje zakres pierwszej wersji, architekturę i plan etapów. Na tej podstawie powstaje wycena – o tym, od czego zależy i jak porównywać oferty, piszemy w artykule Ile kosztuje dedykowana aplikacja webowa. Brief warto traktować jako żywy dokument: po warsztatach aktualizujesz priorytety i kryteria, a nie tworzysz nowy dokument od zera.

Następny krok

Weź powyższe osiem sekcji, wypełnij je w jednym pliku – nawet w punktach – i dołącz próbkę danych oraz opis najważniejszego procesu. Z takim materiałem pierwsza rozmowa od razu dotyczy zakresu, a nie zbierania podstawowych informacji. Jeśli planujesz dedykowane oprogramowanie dla firmy, prześlij nam brief – odpowiemy pytaniami uzupełniającymi i propozycją zakresu pierwszej wersji.