3 min čteníPublikováno:

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.