Wat hoort er wel (en niet) in een requirements-document?
Een requirements-document dat twintig pagina's telt maar geen enkele meetbare eis bevat, helpt niemand vooruit. Toch is dit een veelvoorkomend probleem bij softwaretrajecten. Het document groeit uit tot een uitgebreide wensenlijst, leveranciers interpreteren het naar eigen inzicht, en uiteindelijk sluit de gekozen oplossing niet aan op wat de organisatie écht nodig had. Een sterk requirements-document is beknopt, concreet en onderbouwd. Het geeft softwareleveranciers houvast en helpt jouw organisatie om gefundeerde keuzes te maken. In deze blog lees je wat er absoluut in moet staan, wat je beter kunt weglaten, en hoe een goede business analyse het fundament legt voor een bruikbaar document.
Wat is een requirements-document precies?
Een requirements-document, ook wel een programma van eisen of PvE genoemd, beschrijft de functionele en niet-functionele eisen waaraan een softwareoplossing moet voldoen. Het dient als leidraad tijdens de softwareselectie: leveranciers beoordelen hun oplossing aan de hand van jouw eisen, en jij beoordeelt hun aanbod op basis van hetzelfde document.
Het document is dus geen productbeschrijving van de gewenste software. Het beschrijft wat de software moet kunnen doen en onder welke voorwaarden, niet hoe de oplossing technisch wordt gebouwd.
Welke onderdelen mag een requirements-document nooit missen?
Functionele eisen: wat moet de software kunnen doen?
Functionele eisen beschrijven de concrete taken en processen die de software moet ondersteunen. Denk aan: het registreren van klantgegevens, het genereren van rapportages, of het integreren met een bestaand ERP-systeem.
Een goede functionele eis is specifiek en verificeerbaar. "De software moet facturen kunnen verwerken" is te vaag. "De software moet inkoopfacturen automatisch kunnen matchen aan purchase orders en afwijkingen van meer dan 5% signaleren" is een eis waaraan een leverancier concreet kan toetsen.
Dit soort scherp geformuleerde eisen is precies waar het bij een gestructureerde softwareselectie om draait: hoe concreter de eis, hoe beter leveranciers onderling te vergelijken zijn en hoe kleiner de kans op een verkeerde aanschaf. Werk je toe naar een specifiek systeem, bijvoorbeeld een WMS selectie, dan geldt dit principe des te sterker: vage eisen leiden bij warehouse-systemen vaak tot dure aanpassingen achteraf.
Niet-functionele eisen: onder welke voorwaarden moet het werken?
Niet-functionele eisen gaan over de kwaliteitskenmerken van de oplossing: beschikbaarheid, beveiliging, schaalbaarheid, gebruiksvriendelijkheid en prestaties. Deze worden in de praktijk regelmatig vergeten, met alle gevolgen van dien.
Voorbeelden van niet-functionele eisen:
- De applicatie moet beschikbaar zijn op minimaal 99,5% van de tijd tijdens kantooruren.
- Inloggen moet ondersteund worden via single sign-on (SSO) met Azure Active Directory.
- De responstijd bij het ophalen van een standaardrapportage mag niet meer dan drie seconden bedragen.
Prioritering: must-have, should-have, could-have
Niet alle eisen zijn even zwaarwegend. Door eisen te prioriteren, bijvoorbeeld via het MoSCoW-model (Must have, Should have, Could have, Won't have), geef je leveranciers inzicht in wat absoluut noodzakelijk is en wat mooi meegenomen zou zijn.
Dit voorkomt dat een leverancier afvalt omdat hij één nice-to-have niet ondersteunt, terwijl hij op alle kritieke eisen hoog scoort. Prioritering maakt je selectieproces eerlijker en efficiënter.
Meetbare criteria en acceptatiecondities
Een eis is pas bruikbaar als je kunt vaststellen of eraan voldaan wordt. Voeg daarom voor elke belangrijke eis een meetbare acceptatieconditie toe. Hoe wordt gecontroleerd of de software aan de eis voldoet? Tijdens een demo, een technische test, of op basis van documentatie?
Context en achtergrond van de organisatie
Geef leveranciers voldoende context: wat doet jullie organisatie, hoeveel gebruikers zijn er, welke systemen zijn er al in gebruik, en wat is de aanleiding voor dit traject? Zonder die context is het voor een leverancier lastig inschatten of zijn oplossing past bij jullie situatie.
Wat moet je juist niet in een requirements-document zetten?
Oplossingen in plaats van eisen
Een veelgemaakte fout is het beschrijven van een oplossing in plaats van een behoefte. "De software moet werken met een drag-and-drop-interface" is een ontwerpkeuze. De achterliggende eis is waarschijnlijk: "Gebruikers zonder technische achtergrond moeten zelfstandig workflows kunnen configureren." Door de eis te formuleren vanuit de behoefte, geef je leveranciers ruimte om met een passende, soms betere, oplossing te komen.
Wensen zonder onderbouwing
Een requirements-document dat bestaat uit honderd eisen waarvan zeventig "nice to have" zijn zonder enige toelichting, verliest zijn waarde snel. Elke eis zou terug te herleiden moeten zijn naar een concreet knelpunt of een zakelijke doelstelling. Ontbreekt die onderbouwing? Dan is het waarschijnlijk geen eis, maar een wens.
Technische specificaties die thuis horen in een RFP
Een requirements-document beschrijft wat de software moet doen. Technische implementatiedetails, zoals hostingarchitectuur, API-specificaties of migratieplannen, horen thuis in een Request for Proposal (RFP) of worden later in het traject uitgewerkt. Door die scheiding aan te houden, blijft het requirements-document overzichtelijk en doelgericht.
Interne discussies en onafgemaakte punten
Formuleer eisen alleen als er intern overeenstemming over is. Een requirements-document met opmerkingen als "dit moet nog worden afgestemd met de directie" of "of misschien toch anders?" ondermijnt het vertrouwen van leveranciers en vertraagt het selectieproces.
Waarom een goede business analyse het verschil maakt
Een sterk requirements-document begint niet met het invullen van een template. Het begint met het doorgronden van de organisatie: welke processen lopen stroef, waar zitten de echte knelpunten, en wat wil je over twee jaar anders zien?
Dat is precies wat een business analyse oplevert. Door bedrijfsprocessen in kaart te brengen, stakeholders te bevragen en huidige knelpunten te documenteren, ontstaan eisen die geworteld zijn in de praktijk. Het verschil tussen een requirements-document dat is opgesteld na een grondige business analyse en één dat in een middag is samengesteld, is zichtbaar in de kwaliteit van de leveranciersreacties, en uiteindelijk in de kwaliteit van de gekozen oplossing.
Deze aanpak is bijvoorbeeld direct van toepassing wanneer een organisatie worstelt met productdata die verspreid over meerdere systemen staat: goed pim advies begint dan ook niet met een systeemkeuze, maar met diezelfde grondige analyse van waar de data vandaan komt en wie ermee moet werken. Hetzelfde geldt wanneer je een nieuw planningssysteem overweegt: projectmanagement software implementeren zonder eerst de knelpunten in de huidige planning en samenwerking te doorgronden, leidt vaak tot een tool die de oude problemen simpelweg digitaliseert in plaats van oplost.
Een business analist stelt daarbij ook de kritische vraag: is dit echt een eis, of is het een aanname? Die vraag stellen, en eerlijk beantwoorden, scheidt een bruikbaar document van een uitgebreide wensenlijst.
Inhoudsopgave
Klaar voor de volgende stap in je digitale transitie?
