Wymagania funkcjonalne strony internetowej opisują, co użytkownik może zrobić na stronie, w sklepie lub systemie oraz jak rozwiązanie powinno reagować na konkretne działania.
To coś więcej niż lista funkcji typu „formularz”, „logowanie” czy „integracja z ERP”. Żeby wykonawca mógł właściwie zrozumieć zakres projektu i przygotować realistyczną wycenę, powinien wiedzieć również, kto korzysta z danej funkcji, co może zrobić, jakie dane są potrzebne i jaki powinien być rezultat.
Samo stwierdzenie „Potrzebujemy strefy klienta” niewiele mówi o rzeczywistym zakresie prac.
Znacznie bardziej użyteczny będzie opis: „Klient po zalogowaniu powinien zobaczyć dokumenty przypisane do jego konta, historię zamówień oraz aktualny status realizacji. Administrator powinien mieć możliwość przypisywania dokumentów do poszczególnych klientów”.
Oba opisy dotyczą „strefy klienta”, ale mogą oznaczać zupełnie inny zakres projektu, czas realizacji i koszt.
W tym poradniku wyjaśniamy:
Wymagania funkcjonalne opisują, jakie działania powinna umożliwiać strona lub system. Mogą dotyczyć zarówno użytkownika odwiedzającego stronę, jak i klienta po zalogowaniu, administratora, pracownika firmy czy systemu zewnętrznego.
Przykładowe wymagania funkcjonalne:
Wymaganie funkcjonalne nie musi od razu opisywać technicznego sposobu realizacji. Kluczowe jest określenie oczekiwanego działania i rezultatu.
Brief i wymagania funkcjonalne są ze sobą związane, ale nie są tym samym.
Brief opisuje projekt z szerszej perspektywy:
Wymagania funkcjonalne schodzą poziom niżej i odpowiadają na pytanie: Jak mają działać poszczególne elementy strony?
Przykład briefu: Potrzebujemy formularza dla potencjalnych klientów.
Przykład wymagania funkcjonalnego: Użytkownik wybiera temat zapytania, podaje dane kontaktowe i opisuje potrzebę. W zależności od wybranego tematu wiadomość powinna trafić do odpowiedniego działu. Po wysłaniu użytkownik otrzymuje potwierdzenie.
Brief może więc wskazać potrzebę, a wymagania funkcjonalne pomagają ją doprecyzować.
Jeżeli jesteś jeszcze na wcześniejszym etapie projektu, zobacz poradnik Brief strony internetowej – co powinien zawierać? Wzór i checklista do wyceny.
Firma może samodzielnie opisać wiele potrzeb własnym językiem. Nie oznacza to jednak, że przed pierwszym kontaktem z wykonawcą musi przygotować kompletną dokumentację projektu.
Opisują oczekiwane działanie rozwiązania. Jeżeli partner po zalogowaniu powinien mieć możliwość pobrania aktualnego cennika, jest to właśnie przykład wymagania funkcjonalnego.
Podczas analizy wykonawca sprawdza między innymi:
To etap, podczas którego potrzeby biznesowe są weryfikowane i porządkowane.
Szerzej opisujemy go w artykule Analiza przedwdrożeniowa – na czym polega i dlaczego warto ją wykonać?
Specyfikacja jest rezultatem dalszego doprecyzowania projektu.
Może zawierać:
Najprościej można więc przyjąć:
To dwa różne rodzaje wymagań.
Na przykład:
Opisują konkretne działania i zachowania.
Opisują warunki i cechy, które rozwiązanie powinno spełniać, niezależnie od konkretnych funkcji.
Mogą dotyczyć między innymi:
Jeżeli użytkownik powinien mieć możliwość wyszukania produktu, mamy do czynienia z wymaganiem funkcjonalnym. Jeżeli natomiast określamy, że wyszukiwarka powinna działać sprawnie również przy katalogu obejmującym kilkadziesiąt tysięcy produktów, opisujemy wymaganie dotyczące jakości i wydajności rozwiązania.
W bardziej rozbudowanych projektach oba obszary powinny zostać przeanalizowane, ponieważ zarówno liczba funkcji, jak i wymagania dotyczące wydajności, bezpieczeństwa czy dostępności mogą wpływać na sposób budowy rozwiązania, czas realizacji i koszt projektu.
Nie musisz przygotowywać dokumentacji technicznej. Opisz kto ma korzystać z funkcji, co powinien móc zrobić i jaki rezultat chcesz osiągnąć. Na tej podstawie możemy pomóc doprecyzować zakres, zależności i elementy wymagające dalszej analizy.
Koszt projektu nie wynika wyłącznie z liczby podstron.
Bardzo duży wpływ mają:
Prosta strona informacyjna posiadająca 20 podstron opartych na kilku powtarzalnych układach może wymagać mniej pracy niż serwis składający się z pięciu głównych widoków, ale wyposażony w konfigurator, konta użytkowników i kilka integracji.
Weźmy „formularz kontaktowy”.
Wariant podstawowy:
Wariant bardziej rozbudowany:
W obu przypadkach klient może powiedzieć: Potrzebujemy formularza.
Z perspektywy wyceny są to jednak dwa zupełnie różne zakresy.
Sam proces przygotowania wyceny opisujemy szerzej w poradniku Wycena strony internetowej – jak wygląda proces?
Nie trzeba znać specjalistycznej notacji. Na etapie przygotowania projektu wystarczy prosty schemat:
kto? → co robi? → co robi system? → jaki jest rezultat?
Przykład
Kto? Partner handlowy.
Co robi? Loguje się do strefy partnera.
Co robi system? Rozpoznaje konto i przypisaną do niego grupę.
Jaki jest rezultat? Partner widzi właściwy cennik, dokumenty i materiały dostępne dla swojej grupy.
Można to również zapisać jednym zdaniem: Po zalogowaniu partner powinien zobaczyć cennik i dokumenty przypisane do jego grupy. Administrator powinien mieć możliwość decydowania, jakie materiały są dostępne dla poszczególnych grup użytkowników.
W przypadku bardziej złożonych funkcji warto odpowiedzieć na dodatkowe pytania:
Nie trzeba znać wszystkich odpowiedzi przed rozpoczęciem współpracy – ich zebranie pomaga jednak wykonawcy szybciej zrozumieć zakres i wskazać kwestie wymagające doprecyzowania.
Lista zależy od rodzaju projektu. Poniższe obszary warto przeanalizować w większości bardziej rozbudowanych stron, portali i platform.
Określ, kto będzie korzystał z systemu. Mogą to być:
Następnie wskaż, czy poszczególne grupy mają różne możliwości. Partner może na przykład pobierać dokumentację bez możliwości jej edycji, podczas gdy administrator może dodawać dokumenty i przypisywać je do wybranych grup partnerów.
Jeżeli użytkownicy mogą zakładać konta lub logować się do strony, warto opisać:
Samo hasło „logowanie” nie odpowiada na żadne z tych pytań.
Dla każdego ważnego formularza określ:
Jeżeli formularz dotyczy konkretnego produktu, może automatycznie przekazywać jego nazwę wraz ze zgłoszeniem. Wiadomość trafia wtedy do działu handlowego, a użytkownik po jej wysłaniu otrzymuje potwierdzenie.
Warto opisać również potrzeby osób administrujących stroną.
Na przykład:
Panel administracyjny także jest częścią projektu i jego zakres może istotnie wpływać na wycenę.
Samo stwierdzenie „potrzebujemy wyszukiwarki” niewiele mówi o rzeczywistym zakresie funkcji. Warto dodatkowo określić:
Bardziej precyzyjny opis może więc brzmieć: „Użytkownik powinien móc filtrować produkty według kategorii, producenta i zakresu parametrów technicznych. Po zmianie filtrów lista wyników powinna się aktualizować”.
Warto ustalić:
W przypadku rezerwacji opisz między innymi:
Jeżeli strona umożliwia płatność, opisz:
W przypadku pełnego sklepu internetowego zakres wymagań jest znacznie szerszy. Szczegółowo opisujemy go w poradniku Specyfikacja sklepu internetowego – jak zaplanować funkcje sklepu internetowego?
Jeżeli strona korzysta z danych znajdujących się poza nią, opisz przede wszystkim biznesowy cel wymiany danych. Nie trzeba od razu wskazywać technologii.
Zamiast technicznego opisu typu „integracja przez REST API z ERP” lepiej opisać potrzebę: Strona powinna raz na godzinę pobierać z ERP aktualne stany magazynowe produktów. Po złożeniu zamówienia jego dane powinny zostać przekazane z powrotem do ERP.
Taki opis daje zespołowi technicznemu znacznie więcej informacji.
Warto wskazać, które czynności mają wykonywać się automatycznie.
Na przykład:
Przy serwisie wielojęzycznym warto określić:
Często skupiamy się tylko na tym, co widzi klient. Tymczasem istotne jest również to, jak firma będzie obsługiwać system po wdrożeniu.
W przypadku katalogu produktów administrator może potrzebować możliwości samodzielnego tworzenia kategorii i ustalania kolejności ich wyświetlania. Z kolei w serwisie rekrutacyjnym pracownik HR może otrzymać możliwość publikowania i zamykania ofert pracy bez dostępu do pozostałych ustawień strony.
Za ogólnie: Potrzebujemy formularza.
Lepiej: Użytkownik wybiera temat zapytania, podaje dane kontaktowe i wiadomość. W zależności od wybranego tematu zgłoszenie trafia do działu sprzedaży albo wsparcia. Użytkownik otrzymuje potwierdzenie wysłania.
Za ogólnie: Potrzebujemy strefy B2B.
Lepiej: Partner loguje się na konto zatwierdzone wcześniej przez administratora. Po zalogowaniu widzi indywidualny cennik, dokumenty i historię zamówień. Administrator może przypisywać partnerów do grup z różnymi uprawnieniami.
Za ogólnie: Potrzebujemy zaawansowanej wyszukiwarki.
Lepiej: Użytkownik wyszukuje produkty po nazwie, symbolu i wybranych parametrach. Wyniki można zawęzić według kategorii i producenta.
Za ogólnie: Potrzebny system rezerwacji.
Lepiej: Użytkownik wybiera usługę i jeden z dostępnych terminów. Po dokonaniu rezerwacji liczba dostępnych miejsc dla wybranego terminu zmniejsza się o jedno. Użytkownik oraz administrator otrzymują potwierdzenie.
Za ogólnie: Potrzebujemy integracji z ERP.
Lepiej: Strona pobiera z ERP ceny oraz dostępność produktów. Po utworzeniu zamówienia dane klienta i pozycje zamówienia są przekazywane do ERP.
Samo podanie nazwy systemu nie wystarcza. „Integracja z ERP” może oznaczać:
Przy opisie integracji warto wskazać:
Wskaż systemy, pomiędzy którymi mają być wymieniane dane, np. stronę internetową i system ERP.
Określ, czy wymiana obejmuje np. produkty, ceny, stany magazynowe, zamówienia, klientów lub dokumenty.
ERP → strona, strona → ERP albo dwukierunkowo.
na żądanie, cyklicznie – np. co godzinę lub raz dziennie – albo bezpośrednio po określonym działaniu, np. złożeniu zamówienia.
Czy administrator ma otrzymać informację? Czy proces ma zostać powtórzony?
Tak przygotowany opis pozwala rozpocząć analizę zakresu. Jeżeli projekt obejmuje połączenie z systemem ERP, więcej informacji znajdziesz również w naszej ofercie integracji z systemami ERP.
W bardziej rozbudowanych projektach z systemu korzystają różne grupy użytkowników, na przykład:
Każda z tych osób może widzieć inne dane i mieć inne możliwości.
Zakres dostępu może wyglądać na przykład tak:
Jedno wymaganie „panel klientów” nie pokazuje tej złożoności.
Dlatego role i uprawnienia powinny zostać określone możliwie wcześnie, szczególnie w portalach B2B, panelach klientów i systemach dedykowanych.
Kryteria akceptacji pomagają odpowiedzieć na pytanie: Po czym poznamy, że funkcja została wykonana zgodnie z oczekiwaniami?
Nie każda prosta strona wymaga formalnego dokumentowania wszystkich kryteriów. W rozbudowanych funkcjach jest to jednak bardzo pomocne.
Załóżmy, że wymaganie brzmi: „Użytkownik może zapisać się na szkolenie”. Aby dokładniej określić, co oznacza poprawne działanie tej funkcji, można przyjąć następujące kryteria:
Dzięki temu obie strony rozumieją, co dokładnie oznacza „system zapisów”.
Każde dodatkowe zachowanie oznacza określony zakres:
Dlatego dwa pozornie identyczne wymagania mogą różnić się kosztowo. Kryteria akceptacji pozwalają wcześniej zidentyfikować te różnice.
Nie. Jedną z najważniejszych części pracy z wymaganiami jest ustalenie priorytetów. Jeżeli każda funkcja zostanie oznaczona jako „konieczna”, trudno kontrolować budżet i harmonogram.
W praktyce można zastosować metodę MoSCoW:
Funkcja jest konieczna, aby pierwsza wersja rozwiązania realizowała swój główny cel.
Funkcja jest ważna, ale jej przesunięcie nie blokuje uruchomienia rozwiązania.
Funkcja zwiększa wartość rozwiązania, ale może zostać wdrożona później.
Funkcja jest świadomie odkładana do kolejnego etapu.
Taki podział pozwala zbudować racjonalny zakres pierwszej wersji i zaplanować kolejne etapy. Szczegółowo opisujemy tę metodę w poradniku Metoda MoSCoW – na czym polega i jakie są zalety jej stosowania w projektach IT?
MVP (Minimum Viable Product) to pierwsza wersja rozwiązania zawierająca minimalny zestaw funkcji potrzebnych do osiągnięcia założonego celu biznesowego. Nie oznacza produktu niedopracowanego lub wykonanego „na skróty”.
Dla strefy partnera zakres pierwszej wersji może obejmować:
W kolejnych etapach można natomiast wdrożyć:
Takie etapowanie może mieć dużo większy sens niż próba wdrożenia wszystkich pomysłów w jednym projekcie.
Podobnie jak w przypadku briefu, wymagania funkcjonalne nie powinny zmuszać klienta do projektowania rozwiązania za wykonawcę.
Nie musisz samodzielnie określać:
Jeżeli istnieją konkretne wymagania technologiczne po stronie organizacji, oczywiście należy je przekazać.
Jeżeli nie ma takich ograniczeń, znacznie bardziej użyteczna będzie informacja: „Dane produktów są utrzymywane w systemie X i mają być automatycznie prezentowane na stronie” niż samodzielne narzucanie technologii, w jakiej ma odbywać się ich wymiana.
Rolą software house’u jest przełożenie potrzeb biznesowych na odpowiednie rozwiązanie techniczne.
Jeżeli masz już listę funkcji, możemy pomóc ją zweryfikować i uporządkować. Jeżeli projekt jest dopiero na etapie pomysłu, wystarczy opisać cele, użytkowników i najważniejsze procesy. W przypadku rozbudowanych projektów możemy również przeprowadzić analizę przedwdrożeniową i na jej podstawie przygotować zakres dalszych prac.
Logowanie, ERP, formularz, wyszukiwarka.
To nadal za mało, żeby dobrze zrozumieć zakres.
Formularz ma być nowoczesny.
nie jest wymaganiem funkcjonalnym.
Nie wiadomo, kto może skorzystać z danej funkcji.
Funkcja działa dla klienta, ale nikt nie określił, jak firma ma nią zarządzać.
Opisuje się tylko prawidłowy scenariusz, bez informacji o tym, co powinno wydarzyć się przy błędzie, braku danych lub przekroczeniu określonego limitu.
„Integracja z ERP” może być jednym z największych elementów całego projektu.
Wszystkie pomysły trafiają do pierwszej wersji, nawet jeżeli nie są potrzebne do realizacji głównego celu.
Wykonawca wie, jak klient chce coś zrobić, ale nie wie, dlaczego.
Niektóre decyzje podjęte dla pierwszej wersji mogą utrudniać późniejszą rozbudowę.
Przygotowując listę funkcjonalności, sprawdź, czy potrafisz odpowiedzieć na poniższe pytania.
Nie musisz mieć kompletu tych informacji przed pierwszą rozmową. Lista ma przede wszystkim pomóc uporządkować projekt i wskazać obszary, które wymagają dalszego omówienia.
Przy prostej stronie wystarczająca może być krótka lista funkcji oraz rozmowa z wykonawcą.
Na przykład:
Wraz ze wzrostem liczby:
rośnie potrzeba formalnego uporządkowania wymagań.
Analiza przedwdrożeniowa jest szczególnie uzasadniona, gdy:
W takim przypadku sam opis wymagań jest punktem wyjścia i nie zastępuje pełnej analizy projektu.
W Webtom.pl nie oczekujemy, że klient przed pierwszym kontaktem dostarczy gotową dokumentację techniczną.
Najważniejsze jest dla nas zrozumienie:
Na tej podstawie możemy ocenić, które elementy są już wystarczająco określone, a które wymagają dalszej analizy.
W bardziej rozbudowanych projektach proces może obejmować:
Dzięki temu wycena nie opiera się wyłącznie na liczbie podstron lub ogólnych nazwach funkcji, ale na rzeczywistym zakresie, który trzeba zaprojektować, zaprogramować i przetestować.
Takie podejście jest szczególnie istotne w bardziej rozbudowanych projektach realizowanych przez software house – portalach B2B, strefach klientów i partnerów, platformach internetowych oraz rozwiązaniach zintegrowanych z systemami firmy.
Wymagania funkcjonalne strony internetowej nie są dokumentacją programistyczną. Ich zadaniem jest możliwie jasno odpowiedzieć na pytanie:
Co użytkownik lub system powinien móc zrobić i jaki ma być rezultat?
Zamiast tworzyć samą listę:
formularz → logowanie → CRM → ERP → wyszukiwarka,
warto opisać:
użytkownika → działanie → reakcję systemu → rezultat → ograniczenia → priorytet.
Im lepiej zostaną określone te elementy, tym łatwiej:
Nie oznacza to jednak, że klient musi samodzielnie wykonać całą analizę.
Rolą firmy jest możliwie dobrze opisać potrzeby biznesowe. Rolą doświadczonego wykonawcy jest pomóc przełożyć je na kompletne wymagania i właściwe rozwiązanie techniczne.
Wymagania funkcjonalne opisują działania, które strona lub system powinny umożliwiać użytkownikom, administratorom albo innym systemom. Przykładem może być logowanie, wysłanie formularza, wyszukanie produktu, pobranie dokumentu czy przekazanie zamówienia do ERP.
Najprościej wskazać, kto korzysta z funkcji, co wykonuje, jak reaguje system i jaki powinien być rezultat. Przykładowo: po zalogowaniu partner widzi dokumenty przypisane do swojej grupy, a administrator może zarządzać ich dostępnością.
Nie. Brief opisuje cały projekt z szerszej perspektywy: jego cel, odbiorców, zakres, treści, termin czy budżet. Wymagania funkcjonalne bardziej szczegółowo określają sposób działania poszczególnych funkcji.
Nie. Wymagania funkcjonalne przede wszystkim opisują oczekiwane działanie. Specyfikacja techniczna może natomiast określać sposób realizacji rozwiązania, jego architekturę oraz konkretne wymagania technologiczne.
Wymagania funkcjonalne odpowiadają na pytanie co system ma robić, a niefunkcjonalne określają warunki i cechy działania, takie jak wydajność, bezpieczeństwo, dostępność czy skalowalność.
W przypadku prostego projektu często możliwe jest przygotowanie wstępnej wyceny na podstawie krótkiego zakresu i rozmowy. Przy bardziej złożonych systemach brak opisu funkcji zwiększa liczbę niewiadomych, dlatego pierwsza estymacja może być mniej precyzyjna albo wymagać przyjęcia dodatkowych założeń.
Najlepsze rezultaty daje współpraca obu stron. Klient zna swój biznes, użytkowników i procesy. Wykonawca pomaga przełożyć te potrzeby na kompletne scenariusze, znaleźć brakujące przypadki i zaproponować sposób realizacji.
Samo hasło „integracja z ERP” jest zbyt ogólne. Wymaganiem funkcjonalnym może być natomiast konkretny proces, np. pobieranie z ERP aktualnych cen produktów oraz przekazywanie do niego nowych zamówień.
Tak. Warto określić, czym pracownicy firmy powinni móc zarządzać po wdrożeniu strony, ponieważ zakres panelu administracyjnego również wpływa na projekt, development i testy.
Kryteria akceptacji określają warunki, po których można stwierdzić, że dana funkcja działa zgodnie z ustaleniami. Przykładowo przy zapisie na szkolenie mogą obejmować wybór terminu, kontrolę dostępności miejsc, potwierdzenie zapisu oraz zapis informacji w panelu administratora.
Nie. Warto określić priorytety i rozdzielić funkcje niezbędne na start od tych, które mogą zostać wdrożone później. Pomagają w tym metody priorytetyzacji takie jak MoSCoW.
Najczęściej wtedy, gdy projekt ma wiele typów użytkowników, integracje, rozbudowane procesy biznesowe, zależności pomiędzy funkcjami lub wymagania, których nie da się jednoznacznie określić podczas krótkiej rozmowy. W takich przypadkach analiza pozwala uporządkować wymagania przed rozpoczęciem właściwego projektowania i developmentu.
Ten wpis stworzył
Ekspert od wycen dedykowanych rozwiązań i zarządzania projektami. Posiada ogromne doświadczenie w tworzeniu ofert idealnie dopasowanych do potrzeb i oczekiwań klientów, specjalista łączący pasję do nowych wyzwań z analitycznym podejściem do każdego szczegółu projektu.
Poznaj INP – jeden ze wskaźników Google w Core Web Vitals. Dowiedz się jak poprawić INP w WordPress/WooCommerce.
Dlaczego szybkość ładowania stron internetowych jest istotna dla SEO, konwersji i doświadczeń użytkowników? Dowiedz się, jak ją poprawić!
Sprawdź, ile kosztuje usunięcie wirusa z WordPress, od czego zależy cena, co obejmuje czyszczenie malware i kiedy naprawa jest droższa niż przebudowa strony.
Jak maintenance wpływa na bezpieczeństwo WordPress? Sprawdź, dlaczego aktualizacje, hardening i monitoring są kluczowe dla ochrony strony internetowej.
Share:
