Najdłuższy dokument wymagań biznesowych, jaki miałem w rękach, liczył 87 stron. Powstawał trzy miesiące. Przeczytały go w całości dwie osoby: autor i ja, bo przejmowałem po nim projekt. Sponsor podpisał stronę tytułową, zespół dostawcy czytał wyrywkowo, a pół roku później i tak wybuchł spór o to, co „na pewno miało być w zakresie”.
To nie jest argument przeciwko pisaniu BRD. To argument przeciwko pisaniu go źle. Dobry BRD ma kilkanaście stron, tabele zamiast prozy i jedną sekcję, która ratuje projekty częściej niż wszystkie pozostałe razem. Pokażę dokładnie, jak go złożyć.
BRD w jednym akapicie - i kiedy w ogóle pisać ten dokument
BRD (business requirements document, po polsku dokument wymagań biznesowych) opisuje, po co organizacja uruchamia projekt i co ma się zmienić w biznesie - zanim ktokolwiek zdecyduje, jak to zrobić technicznie. Zbiera w jednym miejscu cel z liczbami, zakres, interesariuszy, procesy i wymagania biznesowe, a na końcu podpisuje go sponsor. Ten podpis to sedno: BRD jest umową o treść projektu, nie notatką ze spotkań.
Teraz szczerze, bo mało który poradnik to mówi: w zespole produktowym pracującym zwinnie pełny BRD to zwykle przerost formy. Jeśli budujecie własny produkt i co dwa tygodnie weryfikujecie kierunek, lepszą robotę zrobi krótki dokument celu plus backlog z dobrze napisanymi user stories.
BRD ma sens tam, gdzie treść projektu jest podstawą rozliczenia z kimś spoza zespołu:
- Wdrożenie systemu od zewnętrznego dostawcy - BRD jest bazą wyceny i załącznikiem do umowy; bez niego spór o zakres kończy się na wersjach z pamięci.
- Przetargi i zamówienia publiczne - formalny opis potrzeb bywa wymogiem, a nie wyborem.
- Integracje między organizacjami - dwie firmy, dwa zarządy, jedna wspólna definicja tego, co powstaje.
- Zgodność i regulacje - audytor nie zapyta o backlog, zapyta o zatwierdzony dokument.
Mój test jest prosty: jeśli za pół roku ktoś może wyciągnąć ten dokument w sporze o pieniądze lub zakres - pisz BRD. Jeśli jedynym czytelnikiem jest Twój własny zespół - wystarczy forma lżejsza.
Częsty punkt zamieszania: czym BRD różni się od SRS i od backlogu. Trzy artefakty, trzy różne pytania:
| BRD | SRS | Backlog produktu | |
|---|---|---|---|
| Odpowiada na pytanie | po co i co ma się zmienić w biznesie | co dokładnie ma robić system | co budujemy w najbliższych iteracjach |
| Język i poziom | biznesowy, bez technikaliów | techniczny, precyzyjny | mieszany, na poziomie pojedynczych zmian |
| Główny czytelnik | sponsor, zarząd, dostawca | zespół deweloperski, testerzy | zespół i Product Owner |
| Kiedy powstaje | przed decyzją o realizacji | po zatwierdzeniu BRD | ciągle, żyje z produktem |
Kolejność ma znaczenie: SRS wywodzi się z BRD, nie odwrotnie. Jak wygląda dobra specyfikacja systemowa i co dokładnie zawiera, rozpisałem w osobnym tekście o specyfikacji wymagań SRS; samą definicję znajdziesz też w słowniku BA.
Struktura BRD sekcja po sekcji (z komentarzem, co pisać)
Poniższy układ stosuję od lat i jeszcze nie trafiłem na projekt, w którym trzeba by go wywrócić. Siedem sekcji, logika od „po co” do „po czym poznamy sukces”. Przy każdej: co ma zawierać i błąd, który widzę najczęściej.
1. Kontekst i cel biznesowy
Skąd wziął się projekt, jaki problem lub jaką okazję adresuje i czyja to decyzja. Cel musi być mierzalny: wskaźnik, wartość dzisiejsza, wartość docelowa, termin i źródło pomiaru. Jedno-dwa zdania kontekstu wystarczą; reszta to tabela miar.
Najczęstszy błąd: cel-życzenie w stylu „poprawa doświadczenia klienta” - bez liczby, terminu i miejsca, w którym ktokolwiek to zmierzy.
2. Zakres (i out of scope - sekcja, która ratuje projekty)
Lista tego, co wchodzi do projektu, i - ważniejsza połowa - lista tego, co świadomie zostaje poza nim. Każda pozycja out of scope z powodem, decydentem i datą decyzji. To najtańsze ubezpieczenie od scope creep, jakie znam: dyskusja „a ja myślałem, że to będzie” kończy się jednym spojrzeniem w tabelę.
Najczęstszy błąd: brak sekcji out of scope w ogóle. Wszystko, czego nie wykluczysz na piśmie, ktoś kiedyś uzna za obiecane.
3. Interesariusze i role
Kto decyduje, kto dostarcza wymagania, kto akceptuje wynik i kogo zmiana dotknie, nawet jeśli nie ma nic do powiedzenia. Zamiast opisów najlepiej działa macierz RACI: jedna tabela, zero wątpliwości, kto podejmuje którą decyzję. Jak ją zbudować w 30 minut i jakich błędów uniknąć, opisałem we wpisie o macierzy RACI.
Najczęstszy błąd: lista działów zamiast konkretnych osób - „dział sprzedaży” niczego nie zatwierdzi, zatwierdza człowiek z imieniem i nazwiskiem.
4. Proces as-is i to-be
Jak praca wygląda dziś (as-is) i jak ma wyglądać po zmianie (to-be) - najlepiej dwa diagramy plus krótki opis różnic. Nie musisz modelować każdego wyjątku; poziom „główny przebieg plus najczęstsze odstępstwa” wystarcza, żeby wszyscy zobaczyli skalę zmiany. Metodę przejścia od stanu obecnego do docelowego rozpisałem w tekście o analizie procesów as-is i to-be.
Najczęstszy błąd: opisanie tylko to-be. Bez as-is nie widać, co się zmienia, ile to kosztuje i kogo trzeba przeszkolić.
5. Wymagania biznesowe i funkcjonalne
Serce dokumentu. Wymagania biznesowe mówią, co organizacja ma osiągać („klient widzi stan punktów w każdym kanale”), funkcjonalne - co system ma robić, żeby to umożliwić. Każde wymaganie w tabeli: ID, treść, priorytet, źródło (kto zgłosił). Rozróżnienie poziomów wymagań z 20 przykładami znajdziesz we wpisie o wymaganiach funkcjonalnych i niefunkcjonalnych, a jeśli dopiero je zbierasz - zacznij od warsztatu wymagań, nie od ankiety mailem.
Najczęstszy błąd: zapisywanie rozwiązań zamiast potrzeb - „system ma mieć przycisk eksportu do Excela” zamiast „kontroler finansowy potrzebuje danych sprzedaży do własnych analiz”.
6. Założenia, ograniczenia, ryzyka
Założenia to rzeczy, które uznajecie za prawdziwe bez dowodu - każde z właścicielem i terminem weryfikacji. Ograniczenia to twarde ramy: budżet, termin, technologia, prawo. Ryzyka - co może pójść źle, z oceną wpływu i planem reakcji. Trzy krótkie tabele, nie eseje.
Najczęstszy błąd: założenia zapisane i zapomniane. Po pół roku „zakładamy, że dostawca udostępni API” okazuje się nieprawdą i nikt nie wie, kto miał to sprawdzić.
7. Kryteria akceptacji i miary sukcesu
Dwie różne rzeczy, często mylone. Kryteria akceptacji mówią, po czym poznacie, że projekt można odebrać - sprawdzalne w dniu odbioru. Miary sukcesu mówią, po czym poznacie, że osiągnął cel biznesowy - mierzone tygodnie lub miesiące po wdrożeniu, według tabeli z sekcji 1. Jak formułować kryteria, żeby dało się je jednoznacznie sprawdzić, pokazuję we wpisie o kryteriach akceptacji.
Najczęstszy błąd: kryterium „system działa poprawnie”. Nie da się tego ani potwierdzić, ani obalić, więc odbiór kończy się negocjacją zamiast pomiarem.
Przykład: fragment wypełnionego BRD dla programu lojalnościowego
Większość wzorów BRD w sieci to puste spisy treści z nagłówkami do samodzielnego wypełnienia. Niewiele z nich pokazuje, jak wygląda treść na poziomie, który obroni się przed sponsorem. Dlatego poniżej dwie sekcje wypełnione w całości. Firma i liczby są przykładowe, poziom konkretu - dokładnie ten, którego oczekuję w realnym dokumencie.
Sekcja 1: Kontekst i cel biznesowy (wypełniona)
Kontekst. Domea sp. z o.o. sprzedaje wyposażenie wnętrz online i w 12 salonach stacjonarnych. Analiza bazy klientów za ostatnie 24 miesiące pokazała, że 68% kupujących składa jedno zamówienie i nie wraca, a koszt pozyskania nowego klienta rośnie trzeci rok z rzędu. Zarząd zdecydował o budowie programu lojalnościowego jako głównej inicjatywy retencyjnej (uchwała z 14.05.2026, sponsor projektu: dyrektorka e-commerce).
Cel biznesowy. Program ma zwiększyć odsetek klientów powracających oraz wartość ich zakupów w horyzoncie 12 miesięcy od startu:
| ID | Wskaźnik | Dziś | Cel | Termin | Źródło pomiaru |
|---|---|---|---|---|---|
| C-01 | Odsetek klientów z co najmniej 2 zakupami w roku | 32% | 40% | 12 mies. od startu | hurtownia danych, raport retencji |
| C-02 | Średnia roczna wartość zakupów uczestnika programu | 640 zł | 800 zł | 12 mies. od startu | system sprzedaży |
| C-03 | Liczba aktywnych zgód marketingowych | 45 tys. | 80 tys. | 12 mies. od startu | CRM |
Czym ten projekt NIE jest. Program nie służy pozyskiwaniu nowych klientów - działa na retencję istniejących. Inicjatywy akwizycyjne pozostają w osobnym budżecie marketingu.
Zwróć uwagę na dwie rzeczy. Cele mają ID (C-01, C-02...), więc dalej w dokumencie każde wymaganie może wskazać, któremu celowi służy. I jest zdanie o tym, czym projekt nie jest - to najkrótsza forma zarządzania oczekiwaniami, jaką znam.
Sekcja 2: Zakres i out of scope (wypełniona)
W zakresie projektu:
- naliczanie punktów za zakupy w sklepie internetowym i w salonach stacjonarnych,
- jedno wspólne saldo punktów klienta niezależnie od kanału zakupu,
- wymiana punktów na kupony rabatowe realizowane w koszyku online i przy kasie,
- zakładka programu w istniejącym koncie klienta (stan punktów, historia, dostępne nagrody),
- e-maile transakcyjne: naliczenie punktów, zbliżający się termin wygaśnięcia, potwierdzenie wymiany,
- miesięczny raport efektów programu dla zarządu (wskaźniki C-01 do C-03).
Poza zakresem projektu:
| Pozycja | Dlaczego poza zakresem | Decyzja |
|---|---|---|
| Aplikacja mobilna programu | koszt przekracza budżet etapu 1; wraca do oceny po 6 miesiącach działania programu | komitet sterujący, 28.05.2026 |
| Partnerstwa punktowe z markami zewnętrznymi | wymaga umów międzyfirmowych, brak zasobów prawnych w tym roku | sponsor, 02.06.2026 |
| Personalizowane rekomendacje produktowe | zależne od wdrożenia hurtowni danych (osobny projekt, inna oś czasu) | komitet sterujący, 28.05.2026 |
| Naliczanie punktów wstecz za zakupy sprzed startu | nieproporcjonalny koszt migracji danych względem korzyści | sponsor, 02.06.2026 |
Każda pozycja poza zakresem ma powód i decydenta z datą. Kiedy za cztery miesiące ktoś zapyta „a czemu nie ma apki?”, odpowiedź zajmuje dziesięć sekund i nie wywołuje kryzysu. Właśnie dlatego nazywam out of scope sekcją, która ratuje projekty.
5 zasad pisania, żeby ktokolwiek to przeczytał
- Wersjonuj i podpisuj. Pierwsza strona to tabela wersji: numer, data, co się zmieniło, kto zatwierdził. Wersja robocza i zatwierdzona to dwa różne dokumenty - w sporze liczy się tylko ta druga.
- Pisz językiem biznesu, nie IT. Sponsor ma zrozumieć każdy akapit bez tłumacza. Zamiast „integracja przez REST API” napisz „systemy wymieniają dane automatycznie, bez ręcznego przepisywania”; szczegóły techniczne należą do SRS.
- Tabele zamiast prozy. Cele, wymagania, ryzyka i zakres czyta się w tabelach, nie w akapitach. Prozę zostaw dla kontekstu - dwa, trzy akapity na cały dokument.
- Nadawaj wymaganiom ID. BR-01, FR-12 - dzięki temu test, decyzja o zmianie i pozycja w umowie wskazują to samo wymaganie. Bez ID śledzenie zmian kończy się na „to wymaganie o mailach, no wiesz które”.
- Dokument żyje. Po każdej zatwierdzonej zmianie zakresu robisz przegląd BRD i nową wersję. Dokument nieaktualizowany od trzech miesięcy w żywym projekcie opisuje projekt, którego już nie ma.
I zasada zerowa, moim zdaniem najważniejsza: krótszy dokument, który wszyscy przeczytali, bije dłuższy, którego nie przeczytał nikt. Te 87 stron z początku tego tekstu nie ochroniło projektu właśnie dlatego, że nikt ich nie znał.
Szablon BRD do pobrania
Nie buduj tego układu od zera. Na platformie Analify utrzymuję bibliotekę szablonów dokumentów analityka - jest w niej między innymi szablon BRD z dokładnie tą strukturą: siedem sekcji, gotowe tabele celów, zakresu, wymagań z ID i rejestrem wersji. Pobierasz, podmieniasz treść, zostawiasz format.
A jeśli Twój projekt jest mały - dwuosobowy zespół, sześć tygodni pracy - nie pisz pełnego BRD. Zrób wersję 2-stronicową:
- Strona 1: kontekst w jednym akapicie, tabela celów z miarami (2-3 wiersze wystarczą), zakres jako dwie listy: w zakresie / poza zakresem z powodami.
- Strona 2: tabela wymagań z ID i priorytetem, pięć najważniejszych założeń i ryzyk, kryteria akceptacji.
- Wytnij: diagramy as-is/to-be (zastąp trzema zdaniami o tym, co się zmienia) i pełną macierz RACI (zastąp jedną linijką: kto decyduje, kto akceptuje).
Taki dokument piszesz w dwie godziny, a daje 80% wartości pełnego BRD: zatwierdzony cel z liczbami i zakres, na który można się powołać.
Chcesz sprawdzić, jak mocne są Twoje podstawy pracy z wymaganiami, zanim usiądziesz do własnego BRD? Zrób darmowy test wiedzy BA - bez konta, wynik od razu. A szablon BRD razem z pozostałymi szablonami dokumentów znajdziesz w bibliotece na platformie Analify.