Business requirements analyse: de uitleg

Business requirement analyse: in dit artikel wordt de business requirements analyse praktisch uitgelegd. Naast wat het is, belicht dit artikel ook wat bedrijfsvereisten zijn, de functionele en niet-functionele vereisten, het raamwerk van vijf basisstappen en de valkuilen van deze analyse. Na het lezen begrijpt u de basisprincipes van deze projectmanagementtool. Veel plezier met lezen!

Wat is een business requirements analyse?

Een business requirements analysis, business requirements analyse, of vereistenanalyse, is een proces waarin de verwachtingen en eisen van de gebruikers en belanghebbenden van een project of taak worden gedefinieerd.

De analyse van de bedrijfsbehoeften (business requirements) is een allesomvattende verklaring van wat een project of taak zou moeten bereiken. In dit document vind je een stapsgewijze procedure om alle vereisten verbonden aan een project of taak te documenteren.

Goede vereisten worden op zo een manier geformuleerd dat zij gedocumenteerd kunnen worden, bruikbaar zijn en meetbaar.

In projecten moet er volledige overeenstemming zijn over wat alle belanghebbenden willen en niet willen bereiken door middel van het project. Het is belangrijk dat dit gebeurd tijdens de initiële fase, of analysefase. Daarna worden de stappen gevolgd uit traditionele project managementmethoden zoals Six Sigma.

Over het algemeen bestaat deze business requirements analyse uit drie soorten activiteiten. Als eerste is er het identificeren van de vereisten van de verschillende belanghebbenden.

Daarna volgt de analyse op de vereisten. Hierbij wordt bepaald of de vereisten duidelijk zijn, volledig en consistent. De laatste stap is het bijhouden en monitoren van vereisten. Dit is een continue proces zolang het project loopt.

Wat zijn bedrijfsvereisten?

Bedrijfsvereisten, ook wel bekend als stakeholder requirements specifications (StRS), beschrijven de vereisten van een voorgesteld project of systeem vanuit het oogpunt van de belanghebbenden.

Het gaat hierbij om vereisten voor producten, systemen, software en andere processen die moeten voldoen aan zakelijke vereisten. StRS worden vaak gebruikt in project management, en in softwareontwikkeling.

De stakeholder requirement specifications (StRS) worden vastgesteld in een business requirements document, of BRD. De nadruk in dit document ligt op het nauwkeurig plannen en ontwikkelen van bedrijfsvereisten.

Voorbeelden van klantvereisten zijn:

• Operationele inzet
• Prestatieparameters
• Effectiviteit
• Levensduur
• Omgevingsfactoren

Andere categorieën bedrijfsvereisten zijn:

• Architectonische vereisten
• Structurele vereisten
• Prestatievereisten
• Ontwerpvereisten

Functionele en niet-functionele vereisten

In softwareontwikkeling en systems engineering zijn functionele vereisten verschillende functies van een systeem of een component. Onder functionele vereisten vallen berekeningen, technische details, verwerking en andere specifieke functionaliteiten.

Niet-functionele vereisten zijn over het algemeen kwaliteitseisen. Kwaliteitseisen kunnen beperkingen opleggen aan het ontwerp, of de implementatie door bijvoorbeeld betrouwbaarheid of beveiliging.

Het plan voor functionele vereisten is vastgesteld in het systeemontwerp. De kwaliteitseisen worden doorgaans opgenomen in het systeemarchitectuurplan.

De business requirements analyse gaat om Vereisten identificeren

Er is een aantal beproefde methodes voor het verzamelen van informatie voor een business requirements analyse. Enkele van de meest effectieve methoden worden hieronder uitgelegd.

Brainstormen

Brainstormen kan in relatief weinig tijd leiden tot veel ideeën over een bepaald onderwerp.

Zorg dat zoveel mogelijk mensen van verschillende gebieden aanwezig zijn, maar vermijd groepen groter dan 10-15 personen om gefocust te blijven. Gebruik whiteboards of tekeningen om de stroom van ideeën op gang te brengen.

Interviews

Het interviewen van mensen die betrokken zijn bij een bepaald project is zeer effectief om informatie te verkrijgen die niet altijd in een groep gedeeld wordt.

Het is wel belangrijk dat de juiste mensen met de juiste kennis geïnterviewd worden. Zorg dat er open vragen gesteld worden zodat een volledig antwoord vereist is.

Prototyping

Als het gaat om de ontwikkeling van een nieuw product of service kan een prototype gebouwd worden. Dit zorgt ervoor dat de klant zich makkelijker kan visualiseren hoe het uiteindelijke ontwerp er uit komt te zien.

Prototypes brengen vaak kwalen aan het daglicht die voor de introductie van het eindontwerp opgelost kunnen worden.

Business requirements analyse stappenplan

Het identificeren van bedrijfsvereisten lijkt misschien eenvoudig, maar een grondige analyse bevat in ieder geval de volgende vier stappen.

Figuur 1 – stappen voor het maken van een business requirements analyse

1. Identificeer belanghebbenden

Leer alles over de belanghebbenden van het project zoals sponsoren, klanten, eindgebruikers en meer. Het is essentieel om sponsoren of aandeelhouders te identificeren die bevoegd zijn om een beslissing te maken.

Hun opvattingen en behoeften zullen een sterke invloed hebben op het proces.

2. Identificeer alle vereisten

Vereisten zijn ofwel bekend of onbekend. Identificeer zoveel mogelijk van deze vereisten. Het verzamelen van behoeften is niet eenvoudig, en een kritische aanpak is noodzakelijk. Het lijkt eenvoudig om informatie te verzamelen van gebruikers en dit te documenteren.

Het is echter moeilijk om nauwkeurige en georganiseerde informatie vast te leggen. Informatie over behoeften en vereisten wordt uitgewisseld op verschillende manieren zoals e-mail, interviews, telefoongesprek, vergadering, etc. Het interpreteren, documenteren en verwerken van deze informatie is een zeer tijdrovende zaak.

Er zijn ook andere technieken om vereisten te identificeren zoals flow-charts, concurrentenanalyses en use cases.

3. Classificeer bedrijfsvereisten

In deze stap van een business requirements analyse worden vereisten georganiseerd, gedocumenteerd en verfijnd. Het product van dit stappenplan wordt beschouwd als een contract voor het uit te voeren project of taak tussen de principal en de agent.

Bij het ontwikkelen van software draait het hier om het zeer gedetailleerd documenteren van alle functies en vereisten van de eindgebruiker. Ontwikkelaars moeten deze vereisten makkelijk begrijpen om de nieuwe oplossing te kunnen ontwikkelen.

4. Analyseer bedrijfsvereisten

Identificeer de hoogste prioriteiten, en bepaal welke eisen haalbaar zijn en welke niet.

Indien er problemen ontstaan door twee vereisten zoals tegenstrijdige belangen moet dit worden opgelost. Probeer de impact van voorgestelde wijzigingen zo goed mogelijk te voorspellen. De definitieve lijst moet duidelijk, beknopt, logisch, haalbaar en relevant zijn voor het project.

5. Documenteer & monitor

Nu de bedrijfsvereisten volledig bekend zijn is het zaak dat er een regelboek ontwikkeld wordt. In dit document staat alle informatie over de belanghebbenden en hun vereisten, wat zij willen bereiken etc. Ook moeten belanghebbenden tijdens het project op de hoogte worden gehouden van ontwikkelingen binnen het project.

Business requirements analyse valkuilen

De weg naar een gestructureerd bestand met alle vereisten van een project is vaak geen rechte lijn. Er zijn verschillende belanghebbenden met verschillende eisen waar rekening mee moet worden gehouden, en er kunnen vele complicaties optreden zoals technologische ontwikkelingen of financiële problemen.

Hieronder staan de meest voorkomende valkuilen in het business requirements analyse proces.

Het ontbreken van belanghebbenden

De stakeholders zijn niet alleen de voor de hand liggende eindgebruikers van een oplossing of project. Andere belanghebbenden zijn de operationele teams, leveranciers, ontwikkelaars of sponsoren.

Als belanghebbenden en hun vereisten niet vooraf zijn meegenomen in het requirement plan kan dit voor vertraging of erger zorgen in latere fases van het project.

Conflicten

De verschillende perspectieven van stakeholders kunnen botsen. Hoewel onvermijdelijk, als er niet snel wordt opgetreden kan het voor een vertraging in het project zorgen.

Het is daarom belangrijk dat de signalen van verschillende perspectieven worden opgepikt en besproken. Lukt het niet om een conflict te voorkomen, lees dan meer over conflictoplossingen van Mary Parker Follett.

Vage bedrijfseisen

Het kan een uitdaging zijn om stakeholders de juiste vragen te stellen, en de juiste antwoorden te krijgen. Projectteams kunnen moeite hebben met het vinden van de vragen die bruikbare antwoorden zullen genereren, en eindigen daardoor met een lijst vage, weinig concrete vereisten.

Resumerend over de business requirements analyse

De business requirements analyse, of vereistenanalyse, is het proces in project management waarin alle vereisten van alle belanghebbenden worden gedefinieerd. Het is belangrijk dat alle belanghebbenden in overeenstemming zijn met elkaar, en dat het project voor iedereen levert wat gepland is.

Bedrijfsvereisten beschrijven de vereisten van een voorgesteld project of systeem vanuit het oogpunt van de belanghebbenden. Doorgaans worden deze vereisten opgenomen in het business requirements document (BRD). Er zijn verschillende vereisten, waaronder klantvereisten, systeemontwerpvereisten, prestatievereisten, ontwerpvereisten en veiligheidsvereisten.

Nu is het jouw beurt

Wat denk jij? Herken jij de uitleg over de business requirements analyse? Heb jij een dergelijke vereistenanalyse uitgevoerd in een project? Welke tools voor projectmanagement ken jij nog meer? Heb jij tips of opmerkingen?

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

Meer informatie

1. Abai, N. H. Z., Yahaya, J. H., & Deraman, A. (2013). User requirement analysis in data warehouse design: a review. Procedia Technology, 11, 801-806.
2. Hay, D. C. (2003). Requirements analysis: from business views to architecture. Prentice Hall Professional.
3. Herrmann, P., & Herrmann, G. (2006). Security requirement analysis of business processes. Electronic Commerce Research, 6(3-4), 305-335.
4. Mazón, J. N., Trujillo, J., Serrano, M., & Piattini, M. (2005). Designing data warehouses: from business requirement analysis to multidimensional modeling. REBNITA, 5, 44-53.

Citatie voor dit artikel:
Janse, B. (2019). Business requirements analyse. Retrieved [insert date] from Toolshero: https://www.toolshero.nl/project-management/business-requirements-analyse/

Oorspronkelijke publicatiedatum: 10/01/2019 | Laatste update: 29/02/2024

Wilt u linken naar dit artikel, dat kan!
<a href=”https://www.toolshero.nl/project-management/business-requirements-analyse/”>Toolshero: Business requirements analyse</a>

Artikel door:

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.