BRD (Business Requirements Document): co obsahuje a jak ho napsat
BRD, tedy dokument obchodních požadavků, popisuje, co má řešení firmě přinést, nikoli jak se technicky postaví. Je to společný jazyk mezi byznysem a IT: byznys v něm potvrdí, co potřebuje, a dodavatel nebo vývoj z něj vychází při návrhu řešení. Dobrý BRD šetří čas, peníze i nervy, protože nedorozumění odhalí ještě před zahájením vývoje.
Kdy BRD potřebujete
- před výběrem dodavatele nebo vypsáním tendru,
- před začátkem vývoje nového systému nebo větší úpravy,
- když na řešení závisí více oddělení s různými očekáváními,
- když je třeba smluvně dohodnout, co se dodá a podle čeho se to převezme.
BRD versus funkční specifikace
BRD mluví jazykem byznysu: jaký problém řešíme, jaké procesy se mění, co musí uživatel umět udělat a podle čeho poznáme úspěch. Funkční specifikace (FSD) z něj vychází a popisuje, jak bude systém fungovat: obrazovky, pole, integrace, pravidla. Nejdřív BRD, potom FSD.
Struktura BRD
1. Úvod a účel dokumentu – o jaký projekt jde, pro koho je dokument určen a jak se bude schvalovat.
2. Obchodní cíle – čeho má řešení dosáhnout, ideálně měřitelně.
3. Rozsah – co je součástí řešení a co výslovně ne.
4. Zainteresované strany – kdo řešení používá, kdo o něm rozhoduje a kdo ho podporuje.
5. Současný a budoucí stav procesů – jak se dnes pracuje, co nefunguje a jak to má fungovat po změně.
6. Obchodní požadavky – seznam požadavků s jednoznačným ID, popisem, prioritou (MoSCoW: must, should, could, won’t) a zdrojem.
7. Nefunkční požadavky – výkon, bezpečnost, dostupnost, ochrana osobních údajů, jazyky.
8. Předpoklady, omezení a závislosti – rozpočet, termíny, stávající systémy, legislativa.
9. Akceptační kritéria – podle čeho byznys řešení převezme.
10. Slovník pojmů – aby všichni rozuměli stejným slovům stejně.
Jak napsat dobrý požadavek
Dobrý požadavek je jednoznačný, ověřitelný a nezávislý na technickém řešení.
- ❌ „Systém má být rychlý a jednoduchý.“
- ✅ „Obchodník najde historii komunikace se zákazníkem do 10 sekund od zadání jeho názvu.“
Každý požadavek má mít vlastníka a prioritu. Pokud ho nelze otestovat, není to požadavek, ale přání.
Nejčastější chyby
- Řešení místo požadavku („chceme tlačítko v pravém rohu“).
- Chybějící rozsah, takže projekt nekontrolovaně roste.
- Požadavky bez priorit – všechno je „must“, takže nic není.
- Chybějící akceptační kritéria, takže na konci nelze říct, zda je hotovo.
Ukázka: BRD vytvořený v Baaito
Zadání, které jsme Baaito dali:
Firma chce nahradit papírové a e-mailové schvalování dovolených a služebních cest. Zaměstnanci mají žádat přes web i mobil, nadřízený schvaluje jedním kliknutím, HR vidí přehled a export do mzdového systému. 300 zaměstnanců, 3 pobočky.
Ukázka dokumentu
Business Requirements Document — Elektronické schvalování dovolených a služebních cest
První strany skutečného dokumentu, který Baaito vytvořil ze zadání výše.
Business Requirements Document — Elektronické schvalování dovolených a služebních cest
Účel dokumentu
Tento dokument stanovuje první pracovní základ obchodních požadavků pro nahrazení papírového a e-mailového schvalování dovolených a služebních cest. Je určen pro business ownera, business analytika, product ownera, realizační tým, HR a QA; konkrétní role však vyžadují potvrzení v rámci vstupu pro zainteresované strany.
Dokument pokrývá požadované obchodní schopnosti, potřeby uživatelů, pravidla schvalování, datové a procesní potřeby, akceptační podmínky a sledovatelnost. Zahrnuty jsou zejména:
- podávání žádostí zaměstnanci přes web a mobil;
- schvalování nadřízeným jedním kliknutím;
- přehled pro HR;
- export do mzdového systému;
- provozní kontext 300 zaměstnanců a 3 poboček.
Organizační, procesní, informační a integrační hranice nejsou ve vstupních podkladech popsány. TBD – vyžadován schválený rozsah, popis současného stavu, seznam dotčených procesů a specifikace rozhraní na mzdový systém.
Formální schválení tohoto dokumentu, jeho verze, vlastníci požadavků a pravidla změnového řízení jsou TBD – vyžadováno rozhodnutí business ownera nebo jiné pověřené schvalovací autority.
Obchodní kontext a cíle
Z dostupného vstupu vyplývá záměr firmy nahradit papírové a e-mailové schvalování dovolených a služebních cest koordinovaným procesem s podporou webu, mobilního přístupu, schvalování nadřízeným, přehledu pro HR a exportu do mzdového systému.
Podložené informace:
- firma má 300 zaměstnanců;
- firma působí ve 3 pobočkách;
- zaměstnanci mají podávat žádosti přes web i mobil;
- nadřízený má schvalovat jedním kliknutím;
- HR má mít přehled;
- má existovat export do mzdového systému.
Konkrétní problémy současného stavu, měřitelné cíle, dotčené organizační jednotky, očekávané přínosy, termíny a schválené priority nejsou dodány. TBD – vyžadován schválený popis současného stavu, cíle iniciativy, měřítka úspěchu a rozhodnutí stakeholderů.
Požadované výsledky podle zadání jsou:
- digitalizované podávání žádostí o dovolenou a služební cesty;
- elektronické schvalování nadřízeným;
- dostupnost přehledu pro HR;
- předávání údajů do mzdového systému.
Tyto výsledky představují požadované obchodní výsledky, nikoli schválený návrh konkrétní technologie nebo implementace. Konkrétní řešení, integrační mechanismus, autentizace a provozní model jsou TBD – vyžadovány schválené návrhové a integrační podklady.
Rozsah
Zahrnutý rozsah
Na základě dostupného briefu je do pracovního rozsahu zahrnuto:
- podávání žádostí zaměstnanci;
- žádosti o dovolenou;
- žádosti o služební cesty;
- přístup přes web;
- přístup přes mobil;
- schvalování nadřízeným jedním kliknutím;
- přehled pro HR;
- export do mzdového systému;
- použití v organizaci o 300 zaměstnancích a 3 pobočkách.
Neurčený nebo vyloučený rozsah
Následující oblasti nelze bez dalších podkladů považovat za zahrnuté ani vyloučené:
- konkrétní typy dovolených;
- cestovní náhrady a jejich výpočet;
- evidence pracovního času;
- zastupování při nepřítomnosti nadřízeného;
- víceúrovňové schvalování;
- přístup externích osob;
- správa uživatelů a organizační struktury;
- notifikace a připomínky;
- archivace a retenční lhůty;
- podrobnosti exportu do mzdového systému;
- napojení na jiné podnikové systémy.
TBD – vyžadován schválený rozsah včetně zahrnutých a vyloučených procesů, dat, rozhraní a dotčených organizačních jednotek.
Předpoklady nebo závislosti, které mohou rozsah změnit, nejsou popsány. TBD – vyžadován seznam předpokladů, závislostí a autorita oprávněná schvalovat změny rozsahu.
Zainteresované strany a uživatelé
Ze vstupu lze identifikovat tyto obecné skupiny uživatelů:
- Zaměstnanci – podávají žádosti o dovolenou a služební cesty přes web nebo mobil. Konkrétní potřeby, oprávnění a výjimky jsou TBD – vyžadován vstup pro zainteresované strany a uživatele.
- Nadřízení – schvalují žádosti jedním kliknutím. Rozsah jejich odpovědnosti, zastupitelnost a rozhodovací pravomoc jsou TBD – vyžadován schválený model rolí a schvalování.
- HR – potřebuje přehled žádostí a export do mzdového systému. Rozsah přehledu, oprávnění, odpovědnost za data a akceptační role jsou TBD – vyžadován vstup HR a schválený model odpovědností.
- Správce nebo vlastník mzdového systému – může být dotčen exportem. Jeho existence, role a technické či obchodní požadavky nejsou potvrzeny. TBD – vyžadován integrační a stakeholderový vstup.
- Business owner a schvalovací autorita – jejich identita a pravomoc nejsou dodány. TBD – vyžadováno rozhodnutí o vlastnictví iniciativy a schvalování baseline.
- QA nebo akceptující tým – jejich účast není ve zdrojích potvrzena. TBD – vyžadováno určení akceptační role.
Použitá šablona: Business Requirements Document (BRD, CS)
Baaito připravil BRD podle ověřené struktury, rozdělil požadavky podle priorit a chybějící údaje označil k doplnění.
Jak to udělat rychleji
Popište potřebu vlastními slovy nebo přiložte stávající podklady. Baaito se doplňujícími otázkami zeptá na to, co v BRD chybí, a vytvoří dokument ve Wordu nebo PDF. Na webu i v Microsoft Teams a Copilotu.
Časté otázky
Kdo BRD píše? Obvykle business analytik ve spolupráci s vlastníkem procesu a klíčovými uživateli.
Jak podrobný má BRD být? Takový, aby dodavatel uměl odhadnout řešení a byznys ho uměl převzít. Technické detaily patří do funkční specifikace.
Nahrazuje BRD user stories? Ne. BRD určuje cíle a rozsah. User stories z něj vznikají při agilním vývoji jako menší, průběžně upřesňované požadavky.