BRD (Business Requirements Document): čo obsahuje a ako ho napísať
BRD, teda dokument obchodných požiadaviek, opisuje, čo má riešenie firme priniesť, nie ako sa technicky postaví. Je to spoločný jazyk medzi biznisom a IT: biznis v ňom potvrdí, čo potrebuje, a dodávateľ alebo vývoj z neho vychádza pri návrhu riešenia. Dobrý BRD šetrí čas, peniaze aj nervy, lebo nedorozumenia odhalí ešte pred začatím vývoja.
Kedy BRD potrebujete
- pred výberom dodávateľa alebo vypísaním tendra,
- pred začiatkom vývoja nového systému alebo väčšej úpravy,
- keď na riešení závisí viac oddelení s rôznymi očakávaniami,
- keď treba zmluvne dohodnúť, čo sa dodá a podľa čoho sa to prevezme.
BRD verzus funkčná špecifikácia
BRD hovorí jazykom biznisu: aký problém riešime, aké procesy sa menia, čo musí používateľ vedieť urobiť a podľa čoho poznáme úspech. Funkčná špecifikácia (FSD) z neho vychádza a opisuje, ako bude systém fungovať: obrazovky, polia, integrácie, pravidlá. Najprv BRD, potom FSD.
Štruktúra BRD
1. Úvod a účel dokumentu – o aký projekt ide, pre koho je dokument určený a ako sa bude schvaľovať.
2. Obchodné ciele – čo má riešenie dosiahnuť, ideálne merateľne.
3. Rozsah – čo je súčasťou riešenia a čo výslovne nie je.
4. Zainteresované strany – kto riešenie používa, kto o ňom rozhoduje a kto ho podporuje.
5. Súčasný a budúci stav procesov – ako sa dnes pracuje, čo nefunguje a ako to má fungovať po zmene.
6. Obchodné požiadavky – zoznam požiadaviek s jednoznačným ID, popisom, prioritou (MoSCoW: must, should, could, won’t) a zdrojom.
7. Nefunkčné požiadavky – výkon, bezpečnosť, dostupnosť, ochrana osobných údajov, jazyky.
8. Predpoklady, obmedzenia a závislosti – rozpočet, termíny, existujúce systémy, legislatíva.
9. Akceptačné kritériá – podľa čoho biznis riešenie prevezme.
10. Slovník pojmov – aby všetci rozumeli rovnakým slovám rovnako.
Ako napísať dobrú požiadavku
Dobrá požiadavka je jednoznačná, overiteľná a nezávislá od technického riešenia.
- ❌ „Systém má byť rýchly a jednoduchý.“
- ✅ „Obchodník nájde históriu komunikácie so zákazníkom do 10 sekúnd od zadania jeho názvu.“
Každá požiadavka má mať vlastníka a prioritu. Ak sa nedá otestovať, nie je to požiadavka, ale želanie.
Najčastejšie chyby
- Riešenie namiesto požiadavky („chceme tlačidlo v pravom rohu“).
- Chýbajúci rozsah, takže sa projekt nekontrolovane rozrastá.
- Požiadavky bez priorít – všetko je „must“, takže nič nie je.
- Chýbajúce akceptačné kritériá, takže sa na konci nedá povedať, či je hotovo.
Ukážka: BRD vytvorený v Baaito
Zadanie, ktoré sme Baaito dali:
Firma chce nahradiť papierové a e-mailové schvaľovanie dovoleniek a služobných ciest. Zamestnanci majú žiadať cez web aj mobil, nadriadený schvaľuje jedným klikom, HR vidí prehľad a export do mzdového systému. 300 zamestnancov, 3 pobočky.
Ukážka dokumentu
Business Requirements Document — Elektronické schvaľovanie dovoleniek a služobných ciest
Prvé strany skutočného dokumentu, ktorý Baaito vytvoril zo zadania vyššie.
Business Requirements Document — Elektronické schvaľovanie dovoleniek a služobných ciest
Účel dokumentu
Tento dokument slúži ako pracovný základ na riadenie a overenie obchodných požiadaviek iniciatívy, ktorej cieľom je nahradiť papierové a e-mailové schvaľovanie dovoleniek a služobných ciest digitálnym procesom.
Dokument pokrýva:
- potrebu zamestnancov zadávať žiadosti cez webové a mobilné rozhranie,
- potrebu nadriadených schvaľovať žiadosti jedným kliknutím,
- potrebu HR získavať prehľad o žiadostiach,
- potrebu exportovať údaje do mzdového systému,
- relevantné obchodné požiadavky, pravidlá, dátové a procesné očakávania, akceptačné podmienky a sledovateľnosť.
Ako faktický vstup je potvrdené, že firma má 300 zamestnancov a 3 pobočky. Konkrétne organizačné hranice, schvaľovacie politiky, integrácie, vlastníci rozhodnutí, termíny a akceptačné prahy sú TBD — vyžaduje sa schválený rozsah iniciatívy, evidované pravidlá a rozhodnutia zainteresovaných strán.
Obchodný kontext a ciele
Podľa dodaného zadania firma v súčasnosti používa papierové a e-mailové schvaľovanie dovoleniek a služobných ciest. Požadovaný budúci stav zahŕňa digitálne zadávanie žiadostí cez web a mobil, jedným kliknutím vykonávané schválenie nadriadeným, prehľad pre HR a export do mzdového systému.
Potvrdené východiskové skutočnosti:
- predmetom iniciatívy sú dovolenky a služobné cesty,
- existujúce schvaľovanie je založené na papieri a e-mailoch,
- požadované používateľské kanály sú web a mobil,
- požadované úlohy nadriadeného zahŕňajú schválenie jedným kliknutím,
- HR má mať prehľad,
- požadovaný je export do mzdového systému,
- organizácia má 300 zamestnancov a 3 pobočky.
Ciele iniciatívy:
- C-01: Umožniť digitálne podávanie žiadostí o dovolenku a služobnú cestu — zdroj: dodaný brief.
- C-02: Umožniť nadriadenému schváliť žiadosť jedným kliknutím — zdroj: dodaný brief.
- C-03: Poskytnúť HR prehľad o žiadostiach — zdroj: dodaný brief.
- C-04: Umožniť export relevantných údajov do mzdového systému — zdroj: dodaný brief.
Podrobné obchodné dôvody, merateľné výsledky, dotknuté organizačné jednotky a schválené cieľové hodnoty sú TBD — vyžaduje sa schválený dokument obchodného kontextu a cieľov. Technické riešenie, konkrétna platforma a spôsob implementácie nie sú v dodanom vstupe určené.
Rozsah
Predbežne zahrnuté:
- elektronické zadávanie žiadostí o dovolenku a služobnú cestu,
- prístup zamestnancov cez web,
- prístup zamestnancov cez mobil,
- schvaľovanie nadriadeným jedným kliknutím,
- prehľad žiadostí pre HR,
- export údajov do mzdového systému,
- zamestnanci v organizácii s rozsahom 300 zamestnancov a 3 pobočiek.
Výslovne nepotvrdené alebo vylúčené:
- konkrétne schvaľovacie úrovne a zastupovanie — TBD; vyžaduje sa schválená schvaľovacia politika,
- konkrétne polia žiadostí — TBD; vyžaduje sa dátový katalóg alebo schválený návrh údajov,
- pravidlá výpočtu nároku na dovolenku — TBD; vyžaduje sa platná HR politika,
- pravidlá služobných ciest a náhrad — TBD; vyžaduje sa schválená cestovná politika,
- spôsob autentifikácie a autorizácie — TBD; vyžaduje sa schválenie bezpečnostných požiadaviek,
- technológia, architektúra a konkrétny mzdový systém — TBD; vyžaduje sa schválený technický a integračný rozsah,
- migrácia historických papierových alebo e-mailových záznamov — TBD; vyžaduje sa rozhodnutie o migrácii,
- konkrétne termíny, rozpočet a implementačné etapy — TBD; vyžaduje sa schválený projektový rámec.
Zmena hraníc rozsahu a autorita oprávnená takúto zmenu schváliť sú TBD — vyžaduje sa rozhodnutie vlastníka iniciatívy alebo inej určenej schvaľovacej autority.
Zainteresované strany a používatelia
Identita, zodpovednosti a rozhodovacie právomoci zainteresovaných strán nie sú v dodanom vstupe špecifikované. Nasledujúce roly vyplývajú iba z opisu požadovaného procesu a vyžadujú potvrdenie:
- Zamestnanci: podávajú žiadosti o dovolenku a služobné cesty. Ich konkrétne potreby, povinné údaje a konzultačná úloha sú TBD — vyžaduje sa záznam z elicitačných stretnutí.
- Nadriadení: posudzujú a schvaľujú alebo zamietajú žiadosti. Rozsah ich právomocí, pravidlá zastupovania a rozhodovacia autorita sú TBD — vyžaduje sa schválená schvaľovacia politika.
- HR: potrebuje prehľad o žiadostiach a pravdepodobne využíva export údajov. Konkrétne reportovacie, kontrolné a akceptačné zodpovednosti sú TBD — vyžaduje sa potvrdenie vlastníka HR procesu.
- Mzdový systém alebo jeho vlastník: prijíma exportované údaje. Identita systému, integračné rozhranie, formát a vlastník sú TBD — vyžaduje sa schválená integračná špecifikácia.
- Vlastník iniciatívy: schvaľuje rozsah a obchodnú baseline. Konkrétna osoba alebo organizačná rola je TBD — vyžaduje sa rozhodnutie o governance iniciatívy.
- Dodávateľ alebo realizačný tím: môže byť konzumentom požiadaviek. Účasť a zodpovednosti sú TBD — vyžaduje sa schválený realizačný model.
Použitá šablóna: Business Requirements Document (BRD, SK)
Baaito pripravil BRD podľa overenej štruktúry, rozdelil požiadavky podľa priorít a chýbajúce údaje označil na doplnenie.
Ako to urobiť rýchlejšie
Opíšte potrebu vlastnými slovami alebo priložte existujúce podklady. Baaito sa doplňujúcimi otázkami opýta na to, čo v BRD chýba, a vytvorí dokument vo Worde alebo PDF. Na webe aj v Microsoft Teams a Copilote.
Časté otázky
Kto BRD píše? Zvyčajne biznis analytik v spolupráci s vlastníkom procesu a kľúčovými používateľmi.
Aký podrobný má BRD byť? Taký, aby dodávateľ vedel odhadnúť riešenie a biznis ho vedel prevziať. Technické detaily patria do funkčnej špecifikácie.
Nahrádza BRD user stories? Nie. BRD určuje ciele a rozsah. User stories z neho vznikajú pri agilnom vývoji ako menšie, priebežne upresňované požiadavky.