Business requirements opstellen: de uitleg

Business requirements: in dit artikel wordt het onderwerp business requirements praktisch uitgelegd. Het artikel begint met een algemene definitie van dit concept, gevolgd door een praktische uitleg, bruikbare voorbeelden en een downloadbaar Business Requirement Document (BRD) template om zelf aan de slag te gaan met het ontwikkelen en beoordelen van zakelijke eisen. Veel leesplezier!

Wat zijn business requirements?

Business requirements, in het Nederlands zakelijke vereisten, beschrijven de kenmerken van een project of activiteit waardoor de organisatie zijn einddoelstellingen kan bereiken. Het wordt ook wel stakeholder requirements specifications (StRS) genoemd.

In dit artikel gaat het om zowel zakelijke vereisten voor het halen van organisatorische einddoelen, als om functionele en niet-functionele vereisten voor de ontwikkeling van producten, systemen en software.

Vrijwel alle producten, systemen en software zijn manieren om zakelijke vereisten te leveren aan de markt. Als het gaat om business requirements gaat het vaak om het ontwikkelen of aanschaffen van software of systemen.

Functionele vereisten vs. niet-functionele vereisten

Bij het ontwikkelen van systeem- of softwarevereisten staat de eindgebruiker meestal centraal. Dit leidt doorgaans tot de productie van een systeem, product of software die aan hun behoeften voldoet. De vereisten bestaan uit functionele vereisten en niet-functionele vereisten.

Functionele vereisten gaan over functies van het systeem in het gebruik ervan. Een voorbeeld van niet-functionele vereisten zijn prestatie- en beveiligingsaspecten die van toepassing zijn op bedrijfsniveau.

Business requirements worden vaak vastgesteld in een zogenaamd Business Requirement Document (BRD). De focus van dit document en deze werkwijze ligt op het proces van planning en ontwikkeling van de vereisten.

Waarom zijn business requirements belangrijk?

Zakelijke vereisten in de ontwikkeling van systemen, producten of software vormen als het goed is het middelpunt in dergelijke ontwikkelingsprocessen. Zonder dat vereisten duidelijk zijn is het niet mogelijk om van start te gaan met de ontwikkeling ervan.

De voordelen van een goed gedefinieerd plan lijken voor de hand liggend, maar het is de moeite waard om de volgende voordelen van een BRD te overwegen:

• Het kan de doorslaggevende factor zijn voor het al dan niet uitvoeren van een project
• Het verkleint de kans dat projecten mislukken als gevolg van slecht gedefinieerde eisen
• Het kan een project koppelen aan specifieke zakelijke doelen
• Het kan de communicatie tussen belanghebbenden verbeteren

Elementen van een Business Requirement Document (BRD)

In het Business Requirements Document (BRD) worden de volgende zaken opgenomen:

• Samenvatting (deze wordt als laatste geschreven)
• Visie voor het project
• Doelstellingen van het project
• Context en achtergrond van het project
• Einddoel van het project
• Identificatie van belanghebbenden
• Gedetailleerde zakelijke vereisten
• Reikwijdte van de oplossing
• Beperkingen zoals kosten, tijdslimieten en risico’s

Het document kan worden aangevuld met andere elementen, zoals een SWOT-analyse of een kosten-batenanalyse. In de meeste gevallen gaat het om een document met in ieder geval de bovenste elementen.

Waaraan moet een goed gedefinieerde vereiste voldoen?

Een goede vereiste moet voldoen aan verschillende criteria. Deze lijken enigszins op de criteria van de SMART-methode.

Specifiek

Een goede eis is helder, specifiek en beknopt. Hoewel kort en bondig, brengt het een heldere en specifieke behoefte over. Een heldere eis is niet dubbelzinnig en kan slechts op een manier geïnterpreteerd worden. Overweeg het volgende:

• Consistente terminologie
• Vermijd het gebruik van bijwoorden om verwarring te voorkomen

Verifieerbaar

Verifieerbaar betekent in deze context dat het mogelijk moet zijn ome en product te testen om te zien of het aan de gestelde eisen voldoen. Bedenk bij het opstellen van de vereisten hoe u kunt aantonen dat het eindproduct hieraan voldoet.

Haalbaar

Een goede vereiste is haalbaar. De eis moet passen in het budget van het project, is technisch haalbaar en er bestaan ook geen bezwaren omtrent de planning. Betrek leden van ontwikkelteams om technische problemen te bespreken en voorkomen.

Duidelijk

Een goede eis is duidelijk en wordt begrepen door alle belanghebbenden. Een goede eis communiceert een enkel kernidee, uitgedrukt in simpele zinnen met consistente terminologie. Gebruik zo nodig acroniemen en veelgebruikte afkortingen om het document overzichtelijk en beknopt te houden.

Business Requirements Document voorbeeld template

In dit artikel kun je een praktisch voorbeeld downloaden van een Business Requirement Document. Hiermee kan je direct zelf aan de slag.

Tips voor het schrijven van een Business Requirements Document (BRD)

Het belangrijkste element uit de BRD zijn de functionele vereisten van een product of van de software. Dit zijn de functies die een systeem moet kunnen uitvoeren om aan de vereisten te voldoen.
Deze omvatten bijvoorbeeld:

1. Technische details
2. Berekeningen
3. Gegevensmanipulatie
4. Verwerking
5. Andere kenmerkende functies van een systeem

Als er geen specifieke functionele vereisten zijn vastgelegd, is het onmogelijk om de ontwerpdesigns te beoordelen.

De volgende tips kun je in het achterhoofd houden bij het werken aan een BRD:

• Oefen het definiëren van sterke vereisten
• Gebruik duidelijke taal zonder buitensporig moeilijk taalgebruik
• Onderzoek soortgelijke projecten die in het verleden zijn uitgevoerd
• Valideer documentatie
• Controleer de feiten
• Houd rekening met tijdsvakken
• Integreer visualisaties en andere ondersteunende middelen

Voordat gestart wordt met het schrijven van een Business Requirements Document (BRD), is het belangrijk dat enige voorbereiding gedaan is. Overweeg de volgende zaken.

Betrek zoveel mogelijk stakeholders bij het proces van het schrijven van een dergelijk document. Om er zeker van te zijn dat in het document alle zaken opgenomen zijn aangaande het project, is het belangrijk om verschillende belanghebbenden met verschillende perspectieven erbij te betrekken. Dit kunnen verschillende mensen zijn, zoals projectmanagers, projecteigenaren, analisten, ontwikkelaars, marketeers en nog veel meer.

Dit is een buitengewoon effectieve manier om het project vanuit verschillende invalshoeken te evalueren en om vroegtijdig mogelijke valkuilen of barrières te identificeren. Het zorgt daarnaast ook voor de generatie van innovatieve oplossingen en creatieve ideeën.

Bespreek met deze groep welke vereisten in ieder geval in het document moeten worden opgenomen. Dit is een van de belangrijkste eerste stappen die voltooid moeten worden. Er zijn verschillende technieken die gebruikt kunnen worden voor het genereren van input.

De eerste daarvan is brainstormen. Dit houdt in dat verschillende stakeholders zoals productmanagers en architecten bij elkaar gebracht worden om samen na te denken over dingen die goed zullen werken.

Een andere methode is 1-op-1 interviews. Middels deze methode wordt een plan opgesteld met een enkel individu of een kleine groep mensen zoals eindgebruikers en/of klanten.

De derde methode om vereisten vast te stellen is door observatie. Het is soms mogelijk om te observeren hoe een bepaald proces functioneert. Aan de hand daarvan kunnen specifieke eisen worden opgesteld.
Ook het laten invullen van vragenlijsten is een manier om feedback en vereisten te vergaren.

Nu is het jouw beurt

Wat denk jij? Herken jij de uitleg over business requirements? Werk jij met een BRD? Of denk jij wel eens goed na over de specifieke vereisten van een product of service waar jij aan werkt? Welke andere tools kunnen ingezet worden voor het ontwikkelen van een kwalitatief goede BRD? Heb jij tips of opmerkingen? Mis jij een artikel over een onderwerp? Laat het weten in de opmerkingen of vul het contactformulier in.

Deel jouw kennis en ervaring via het commentaar veld onderaan dit artikel.

Meer informatie

1. Hay, D. C. (2003). Requirements analysis: from business views to architecture. Prentice Hall Professional.
2. Jonasson, H. (2007). Determining project requirements. Auerbach Publications.
3. Kazhamiakin, R., Pistore, M., & Roveri, M. (2004, September). A framework for integrating business processes and business requirements. In Proceedings. Eighth IEEE International Enterprise Distributed Object Computing Conference, 2004. EDOC 2004. (pp. 9-20). IEEE.
4. Verma, K., & Kass, A. (2008, October). Requirements analysis tool: A tool for automatically analyzing software requirements documents. In International semantic web conference (pp. 751-763). Springer, Berlin, Heidelberg.

Citatie voor dit artikel:
Janse, B. (2023). Business requirements opstellen: uitleg plus voorbeeld template. Retrieved [insert date] from Toolshero: https://www.toolshero.nl/strategie/business-requirements/

Gepubliceerd op: 17/02/2023 | Laatste update: 31/07/2023

Wilt u linken naar dit artikel, dat kan!
<a href=”https://www.toolshero.nl/strategie/business-requirements/”>Toolshero: Business requirements opstellen: uitleg plus voorbeeld template</a>

Article by:

Ben Janse

Ben Janse is een young professional en werkzaam als Content Manager bij Toolshero. Daarnaast houdt hij zich binnen zijn studie International Business aan de Hogeschool Rotterdam bezig met het analyseren en ontwikkelen van managementmodellen. Dankzij zijn theoretische en praktische kennis weet hij hoofd- en bijzaken goed te onderscheiden waardoor de essentie van elk artikel goed naar voren komt.