BRD vs FRD

Laatst bijgewerkt op 4 december 2023 door Ewen Finser

Projectdocumentatie is een van de meest kritieke stappen in elk bedrijfs- of softwareontwikkelingsproces. Belanghebbenden moeten een gedeeld begrip hebben van wat ze willen bouwen. Door requirements nauwkeurig te documenteren, kunnen bedrijven scope creep voorkomen, ervoor zorgen dat iedereen op één lijn zit en de ontwikkeling versnellen. 

Uit een onderzoek uit 2014 van het Project Management Institute (PMI) blijkt dat 37% van de projecten mislukt door het onnauwkeurig verzamelen van vereisten. Het vooraf vaststellen van de juiste vereisten voorkomt later dure wijzigingen.

Bedrijfsanalisten gebruiken meestal twee verschillende vereisten documenten: het Business Requirements Document (BRD) en het Functional Requirements Document (FRD). Er bestaan echter nog andere documenten, die samen een uitgebreid beeld van het project geven.

Enkele van deze documenten zijn:

• Document met productvereisten (PRD)
• Use Case Specificatiedocument (USD)
• Requirements Traceability Matrix (RTM)
• Document Marktvereisten (MRD)
• Gebruikersverhalen 

Hier richten we ons op BRD vs FRD. Beide zijn belangrijk, maar ze hebben verschillende doelen. Verderop bespreken we hoe de twee documenten verschillen, wat hun kenmerken zijn en wanneer je ze allebei moet gebruiken.

Bottom Line Up Front

Het belangrijkste verschil tussen BRD vs FRD is dat BRD's zich richten op wat het product zou moeten doen, terwijl FRD's zich richten op hoe het product het zou moeten doen.

Een business requirements document (BRD) is een formeel contract tussen de klant en de leverancier dat al het werk in een project vastlegt. Een functioneel eisen document (FRD) definieert uitgebreid de oplossing die nodig is om te voldoen aan de zakelijke behoeften die zijn geïdentificeerd in het BRD.

Belangrijkste verschillen tussen BRD vs FRD

De belangrijkste verschillen tussen BRD en FRD zijn:

• Het primaire publiek van een BRD zijn de zakelijke belanghebbenden, klanten en cliënten, terwijl het primaire publiek van een FRD het ontwikkelteam, de engineers en de testers zijn.
• Een BRD beschrijft wat het product moet doen, terwijl een FRD beschrijft hoe het project dat moet doen.
• Een BRD is bedoeld om eisen van de klant te verkrijgen, terwijl een FRD bedoeld is om eisen voor het ontwikkelteam te definiëren. 
• De opmaak van een BRD is vrij met een mix van tekst en visuals, terwijl de opmaak van een FRD stijver is en vaak gebruik maakt van Unified Modeling Language (UML).
• Een bedrijfsanalist stelt het BRD document op, terwijl de bedrijfsanalist het FRD opstelt onder supervisie van een technisch expert (d.w.z. een architect).

Wat is een BRD (Business Requirements Document)?

Een business requirements document (BRD) is een overzicht op hoog niveau van een project. Bedrijfsanalisten gebruiken BRD's om de doelen van een project vast te leggen vanuit het perspectief van het bedrijf of de organisatie. Het is een van de eerste stappen in een softwareontwikkelingsproces en het wordt meestal gemaakt voordat het technische werk begint.

Ontwikkelaars gebruiken het als hulpmiddel om het project uit te voeren en de juiste oplossing te bouwen. De BRD bevat een overzicht van wat het product moet doen, wie het zal gebruiken en hoe ze het zullen gebruiken. Het stelt ook meetbare succescriteria vast die nodig zijn om te beoordelen of het eindproduct voldoet aan de behoeften van het bedrijf.

Als document dat volgende stappen vastlegt en de ontwikkeling begeleidt, is een BRD essentieel om het juiste product te bouwen. Verschillende projecten hebben unieke vereisten, dus de bedrijfsanalist moet een BRD maken die nauwkeurig de specifieke behoeften van het betreffende project weerspiegelt. 

Onderdelen van een Business Requirement Document (BRD)

Het unieke karakter van een BRD betekent dat er geen standaardsjabloon bestaat voor het document. Alle BRD's hebben echter gemeenschappelijke kenmerken en elementen. Essentiële onderdelen van een BRD zijn:

1. Samenvatting: Een samenvatting van de BRD moet een overzicht geven van het project. Het legt een verband tussen de doelstellingen van het project en de behoeften van het bedrijf. In wezen beantwoordt het de vraag: "Welk probleem proberen we op te lossen en hoe gaat dit project ons daarbij helpen?".
2. Omvang van het project: De projectscope is een overzicht op hoog niveau van wat het project zal bereiken en omvat deliverables, tijdlijnen, kosten en risico's. Het legt de verantwoordelijkheden van de organisatie, de business en het ontwikkelteam uit. Het verklaart de verantwoordelijkheden van de organisatie, de business en het ontwikkelteam.
3. Doelstellingen overzicht: In het doelstellingenoverzicht staan specifieke doelen die het project moet bereiken. Elke doelstelling moet SMART zijn: specifiek, meetbaar, haalbaar, relevant en tijdgebonden. Het beschrijft de achtergrond van het project en geeft een lijst van belanghebbenden, zakelijke drijfveren (operationeel, markt, financieel, enz.) en primaire succesfactoren.
4. Identificatieproces van belanghebbenden: Een stakeholderidentificatieproces is een hulpmiddel voor het identificeren en analyseren van de stakeholders van het project. Bedrijfsanalisten gebruiken het om de rol van elke stakeholder te begrijpen, hun invloed op het project te beoordelen en strategieën te ontwikkelen om verwachtingen te managen. 
5. Meetwaarden: Meetbare indicatoren zijn KPI's die helpen om te beoordelen of het project succesvol was. Voorbeelden zijn verhoogde inkomsten, verlaagde kosten of verhoogd marktaandeel.
6. Projectbeperkingen: Elk project heeft beperkingen, dit zijn voorwaarden of beperkingen die het succes van het project kunnen beïnvloeden. Bekende voorbeelden zijn budget, tijd, reikwijdte en middelen.

Deze onderdelen dekken de basis van een BRD. Het document kan echter ook andere kenmerken bevatten, zoals aannames en risico's die specifiek zijn voor het project. 

Doelstellingen van een Business Requirement Document (BRD)

Een BDR is de basis van een project, dus de doelstellingen zijn breed. In het algemeen moet een BRD

• Eisen uitvragen bij belanghebbenden: Om het juiste product te bouwen, moeten ontwikkelaars de behoeften van de business begrijpen. Een BRD is een van de eerste stappen in het verzamelen van deze vereisten.
• Succescriteria definiëren: De meetbare resultaten van de BRD helpen om te beoordelen of het project succesvol was.
• Scope creep minimaliseren: Door de doelstellingen, risico's en beperkingen van het project te documenteren, kan een BRD scope creep helpen voorkomen.
• Als referentiepunt dienen: De BRD is een levend document dat voortdurend moet worden bijgewerkt. Het is echter ook een referentiepunt voor alle belanghebbenden. Het geeft een overzicht van de doelen, doelstellingen en deliverables van het project.
• Consensus bereiken met belanghebbenden: Een BRD kan bedrijfsanalisten helpen om buy-in te krijgen van belanghebbenden. Door iedereen vanaf het begin op één lijn te krijgen, kunnen ze misverstanden en meningsverschillen voorkomen.

Wat is een Functional Requirement Document (FRD)?

Een functioneel eisen document (FRD) is een type eisen document dat specificeert wat een systeem moet doen en hoe het moet werken.  Het bevat meer specifieke informatie over hoe het product of project moet functioneren, inclusief beschrijvingen van elke functie. In de basis is het een afgeleide van een BRD en benadrukt het de functionele vereisten. 

Bedrijfsanalisten zijn onder toezicht van een technisch expert verantwoordelijk voor het maken van een FRD. Het document moet duidelijk, beknopt en vrij van technisch jargon zijn. Het moet ook gemakkelijk te begrijpen zijn voor alle belanghebbenden. Net als een BRD beschrijft het ook een overzicht op hoog niveau van functionaliteit, maar richt het zich op technische en specifieke details.

Een FRD voor een webgebaseerde applicatie kan bijvoorbeeld specificeren dat de aanmeldpagina velden voor een gebruikersnaam en wachtwoord moet hebben. Het zou ook beschrijven hoe het systeem de authenticatie moet afhandelen. In een BRD voor dezelfde applicatie staat daarentegen alleen dat de aanmeldpagina beveiligd moet zijn. 

Onderdelen van een Functional Requirements Document (FRD)

Er is geen vaste standaard waaraan alle FRD's moeten voldoen. De meeste FRD's bevatten echter vergelijkbare elementen, waaronder:

1. Inleiding: De inleiding moet een overzicht geven van het systeem en het doel ervan. Het doel, het toepassingsgebied, de aannames en de beperkingen van het systeem moeten gedetailleerd worden beschreven. Belangrijke belanghebbenden moeten ook worden geïdentificeerd.
2. Achtergrond: Het achtergrondgedeelte biedt meer context voor het systeem. Het moet de huidige staat van het systeem beschrijven en eventuele problemen die het nieuwe systeem moet oplossen. 
3. Functionele vereisten: De requirements sectie is het vlees van het FRD. Het bevat een lijst van alle functionele vereisten, georganiseerd per categorie. Elke eis zou een unieke identificatie, naam, beschrijving en bron moeten hebben. In sommige gevallen kunnen de eisen gepaard gaan met een acceptatiecriterium.
4. Gebruikersinterfaces: Het gebruikersinterface-gedeelte moet een overzicht op hoog niveau geven van de interfaces van het systeem. Het moet beschrijven hoe gebruikers zullen interageren met het systeem en eventuele speciale vereisten voor de interface. 
5. Modelleren van illustraties: Het modelleergedeelte moet visuele representaties van het systeem geven. Deze illustraties kunnen diagrammen, stroomdiagrammen, prototypes en mockups zijn. Het moet ook gebruikerseisen, use cases en andere relevante modellen bevatten.
6. Woordenlijst: De verklarende woordenlijst moet een lijst bevatten van alle termen, acroniemen en afkortingen die in het FRD worden gebruikt. Het moet ook definities geven voor elke technische term. 

Het gebruik van FRD's hangt af van de organisatie, het project en het product. Het moet het beleid, de processen en de procedures van de organisatie volgen.

Doelstellingen van een Functional Requirement Document (FRD)

Hoewel de doelstellingen van een FRD van organisatie tot organisatie kunnen verschillen, zijn er enkele gemeenschappelijke doelen die de meeste FRD's nastreven, waaronder:

• De functie van een systeem definiëren: Het primaire doel van een FRD is het definiëren van de functie van een systeem. Het moet beschrijven wat het systeem moet doen en hoe het moet werken. 
• Onderlinge afhankelijkheden: Een FRD moet ook alle onderlinge afhankelijkheden tussen verschillende functies identificeren. De aanmeldfunctie kan bijvoorbeeld afhankelijk zijn van de authenticatiefunctie.
• Risico's en kosten inschatten: Een FRD kan ook helpen om de risico's en kosten van een project in te schatten. Door alle vereisten te schetsen, is het gemakkelijker om potentiële risico's tijdens het ontwikkelingsproces te identificeren. 
• Verbeter de communicatie: Een FRD kan ook de communicatie tussen verschillende belanghebbenden verbeteren. Door een duidelijk en beknopt overzicht van het systeem te geven, is het voor iedereen gemakkelijker om de vereisten en doelstellingen van het project te begrijpen. 
• Zorg voor een holistische kijk op elke vereiste: De FRD moet een holistisch beeld geven van elke vereiste, hoe klein of onbeduidend deze ook lijkt. Bijvoorbeeld, een vereiste om een foutmelding weer te geven wanneer een gebruiker een ongeldig wachtwoord invoert kan triviaal lijken. Toch is het een vereiste die opgenomen moet worden in de FRD. 

Belangrijkste verschillen tussen BRD's en FRD's

Nu we de basisprincipes van BRD's en FRD's hebben doorgenomen, gaan we dieper in op de belangrijkste verschillen tussen deze twee soorten documenten. 

1. Toepassingsgebied

Het belangrijkste verschil tussen een BRD en een FRD is de reikwijdte. Een BRD is een overzicht op hoog niveau van het hele project. Het moet een breed overzicht geven van de doelstellingen, vereisten en tijdlijn van het project. Een FRD daarentegen is een meer gedetailleerd document dat zich richt op de functionele eisen van het systeem.

Bij het bekijken van de reikwijdte van een project is het essentieel om het doel van elk document in gedachten te houden. De BRD moet een algemeen overzicht geven van het project, terwijl de FRD een meer gedetailleerd systeemoverzicht moet geven. In de BRD kan bijvoorbeeld staan dat het project "de verkoop moet verhogen met 10%". Het FRD geeft dan in detail aan hoe het systeem dit doel moet bereiken. 

2. Publiek

Het publiek van een BRD is de projectsponsor, het senior management of kritische andere besluitvormers. De BRD moet deze belanghebbenden voldoende informatie bieden om weloverwogen beslissingen over het project te kunnen nemen. 

De doelgroep van een FRD is meestal het ontwikkelteam. Het moet genoeg informatie geven voor deze belanghebbenden om de systeemeisen te begrijpen en aan het project te beginnen. Het geeft ook het kwaliteitsborgingspersoneel de informatie om testplannen en testgevallen te maken. 

3. Lengte

De lengte van een BRD kan variëren afhankelijk van het project. Een klein project kan bijvoorbeeld maar een paar pagina's vereisen, terwijl een groter project een gedetailleerder document kan vereisen. Over het algemeen zijn BRD's echter korter dan FRD's. 

FRD's daarentegen zijn meestal langere documenten. Deze documenten bevatten uitgebreide documentatie van de systeemvereisten. Daarom zijn ze meestal veel langer dan BRD's. Een standaard FRD is ongeveer 10 tot 100 pagina's lang, terwijl een groter project een langer document kan vereisen. 

4. Wie bereidt het document voor?

Alleen bedrijfsanalisten zijn verantwoordelijk voor het maken van BRD. Sommige organisaties betrekken er projectmanagers bij om ervoor te zorgen dat het document voldoet aan de behoeften van het project. 

Bedrijfsanalisten werken onder toezicht van systeemanalisten of technische experts om een FRD op te stellen. Een implementatieteam kan deelnemen aan de ontwikkeling van een FRD. Hun betrokkenheid is echter beperkt tot het leveren van input over de functionaliteit van het systeem. 

5. Flexibiliteit

BRD's zijn meestal flexibeler dan FRD's omdat ze concepten op een hoger niveau behandelen die minder snel zullen veranderen naarmate een project vordert. FRD's daarentegen zijn meer rigide omdat ze vaak specifieke technische details beschrijven die nauwkeurig gevolgd moeten worden om een systeem correct te laten werken. 

Wanneer BRD en FRD gebruiken

Zowel BRD- als FRD-documenten zijn essentieel voor elk project. Zodra je de BRD hebt, kun je deze gebruiken om de FRD te maken. Nadat het FRD compleet is, kun je het gebruiken om de functionele specificaties van het project te ontwikkelen. 

Er kunnen echter momenten zijn waarop je het ene document boven het andere moet gebruiken. Als je bijvoorbeeld het project aan het senior management presenteert, zul je het BRD willen gebruiken. Aan de andere kant, als je samenwerkt met het ontwikkelteam, zul je het FRD willen gebruiken. 

Hieronder vindt u een overzicht van wanneer u elk document moet gebruiken: 

Gebruik BRD wanneer: 

• Je moet het senior management overtuigen om het project goed te keuren 
• Je presenteert het project voor het eerst 
• Je wilt een overzicht geven van de doelstellingen, vereisten en tijdlijn van het project 
• Bij het opstellen van projectvereisten 
• Bij het maken van een overzicht op hoog niveau van het project 

Gebruik FRD wanneer: 

• Je wilt gedetailleerde informatie geven over de functionaliteit van het project 
• Je werkt samen met ontwikkelaars om de functionele specificaties van het systeem te maken 
• Je moet ervoor zorgen dat iedereen in het team de systeemvereisten begrijpt 
• Bij het schetsen van gedetailleerde technische specificaties voor het project 
• Bij het verstrekken van informatie die ontwikkelaars gebruiken om testplannen en testgevallen te maken 

Een grotere organisatie kan beide documenten van begin tot eind gebruiken. In dit geval wordt de BRD gebruikt om goedkeuring te krijgen voor het project. Zodra het project is goedgekeurd, maakt de bedrijfsanalist het FRD. Nadat het FRD compleet is, wordt het doorgegeven aan het ontwikkelteam om de functionele specificaties van het systeem te ontwikkelen. 

Niet alle projecten of bedrijven hebben beide documenten nodig. Een klein bedrijf of een klein project met weinig complexiteit kan bijvoorbeeld alleen een BRD nodig hebben. Een project kan echter niet draaien op een FRD alleen, omdat het een afgeleide is van de BRD. 

FAQ's

Conclusie

Een BRD en FSD zijn essentiële documenten voor elk project. Het belangrijkste verschil tussen de twee is dat een BRD een document op hoog niveau is dat de bedrijfsdoelen schetst, terwijl een FRD een meer gedetailleerd document is dat de functionele vereisten van het project beschrijft.

Beide documenten worden opgesteld door de bedrijfsanalist en beoordeeld door belanghebbenden en materiedeskundigen. 

Wanneer je beslist welk document je gaat gebruiken, is het essentieel om rekening te houden met het doel van het project en wie het document gaat gebruiken. Kleine bedrijven met weinig complexiteit hebben misschien alleen een BRD nodig, terwijl grotere bedrijven of projecten beide documenten nodig kunnen hebben.