---
title: "Het risico zit in de eisen: begin bij het formuleren"
description: Veel programma’s van eisen vormen een risico. Wat onderzoek laat zien over de kosten van laat ontdekte fouten, en waarom je al bij het formuleren begint.
---

[Insights](https://basewise.ai/insights)

# [Het risico zit in de eisen: begin bij het formuleren](https://basewise.ai/insights/programmas-van-eisen)

 Geschreven door [Christian van Eken](https://basewise.ai/insights/author/christian-van-eken) | Oct 21, 2026, 10:00:32 AM

Je komt ze geregeld tegen: programma’s van eisen die om aandacht schreeuwen. Niet omdat het fantastische programma’s van eisen zijn. Juist niet. Ze schreeuwen om aandacht omdat ze een risico vormen. Ze zijn genummerd, netjes opgemaakt en ogenschijnlijk compleet, maar bevatten eisen die op twee manieren te lezen zijn, waarvan niemand precies weet hoe je ze toetst, of die uitgaan van aannames die nergens staan.

Meestal wordt dat pas zichtbaar op het verkeerde moment: tijdens een audit, een verificatie of een discussie met de opdrachtgever. Dat komt zelden door onzorgvuldigheid van degene die het programma van eisen opstelde. Zo’n document ontstaat onder tijdsdruk, met meerdere auteurs, en vaak met honderden of duizenden regels. Een zin die voor de schrijver helder is, is dat voor de lezer, of voor een collega over een paar maanden, lang niet altijd.

### 01 | Wat onderzoek wel en niet laat zien

Eerst de infrastructuur. Flyvbjerg, Holm en Buhl onderzochten 258 transportinfrastructuurprojecten (spoor, bruggen, tunnels en wegen) in twintig landen, samen ongeveer 90 miljard dollar waard. Bij ongeveer negen op de tien projecten liepen de kosten op ten opzichte van de raming, gemiddeld met 28 procent. Ook bleek dat elk jaar dat de looptijd tussen het besluit om te bouwen en de ingebruikname langer duurde, samenging met gemiddeld ongeveer 4,6 procentpunt extra kostenstijging. Hun advies: los problemen op in de voorbereiding, voordat ze als vertraging terugkomen in de uitvoering. Dat onderzoek meet de kwaliteit van eisen overigens niet. Het laat zien wat vertraging kost, niet wat één onduidelijke eis kost.

Over de kosten van laat ontdekken komt het bekendste onderzoek uit de software. Boehm en Basili brachten in 2001 empirische gegevens samen: een probleem dat pas na oplevering wordt gevonden en hersteld, is vaak ongeveer honderd keer zo duur als wanneer het in de eisen- of ontwerpfase was opgespoord. Bij kleine, niet-kritieke projecten ligt die factor eerder rond de vijf. Ze schatten ook dat op softwareprojecten van toen 40 tot 50 procent van de inspanning naar vermijdbaar herwerk ging. Als twee grote bronnen daarvan noemen ze hastig opgestelde eisen en een ontwerp dat alleen het normale geval uitwerkt. Dat zijn softwarecijfers en een bouwproject is geen softwareproject, dus de factor honderd moet je niet één op één vertalen. De richting is wel herkenbaar: hoe later een fout boven water komt, hoe duurder hij is.

### 02 | De patronen die steeds terugkomen

Wie veel programma’s van eisen doorneemt, ziet steeds dezelfde soort problemen:

- Vage termen: "waar mogelijk", "zo nodig", "indien van toepassing". Woorden die ruimte laten voor interpretatie, terwijl een eis juist bedoeld is om die ruimte weg te nemen.
- Ontsnappingsclausules: voorwaarden die een eis feitelijk vrijblijvend maken, zonder dat dat de bedoeling was.
- Niet-verifieerbare eisen: mooi geformuleerd, maar niemand kan objectief vaststellen of eraan is voldaan.
- Meerdere eisen in één zin: waardoor een deel makkelijk over het hoofd wordt gezien bij verificatie.
- Ontbrekende eenheden of onduidelijke verwijzingen: "het systeem" of "de gebruiker", zonder dat vaststaat welk systeem of welke gebruiker bedoeld wordt.

Op zichzelf lijkt zoiets klein. Bij honderd eisen is het een ergernis. Maar veel programma’s van eisen bestaan uit honderden of duizenden regels, geschreven door meerdere auteurs en aangepast over meerdere revisies. Dan stapelt het zich op, en het wordt duurder naarmate het later wordt ontdekt.

### 03 | Begin bij het formuleren

Een tool als RQA (Requirements Quality Analyser) wordt vaak gezien als controle achteraf op een bestaand programma van eisen. Dat kan, en soms is dat precies wat nodig is. Maar het is minstens zo nuttig tijdens het formuleren zelf, bijvoorbeeld in het proces rond de klanteisenspecificatie (KES) of de stakeholdereisenspecificatie. Dan haal je een vage term, een niet-toetsbare formulering of een eis die twee dingen tegelijk vraagt eruit voordat hij in het programma van eisen belandt. Dat is het moment waarop herstel het goedkoopst is.

RQA toetst eisen aan de INCOSE-regels voor het schrijven van eisen. Je uploadt je eisen in Excel en elke eis krijgt een score van 1 tot 5, een uitleg welke regels worden geraakt en een verbetervoorstel. Dat voorstel staat eerst in concept: jij accepteert of past aan. Daarnaast controleert RQA de set op tegenstrijdige en dubbele eisen. Wie aan de andere kant van de tafel zit, bijvoorbeeld een inschrijver die een programma van eisen ontvangt, kan dezelfde analyse draaien als executeur. Dan krijg je per eis ook het risico, de aanname en concrete vragen die je aan de opdrachtgever kunt voorleggen.

### 04 | Worden alle eisen dan niet hetzelfde?

Laatst had ik een KES-sessie met een bouwteam waarin we RQA gebruikten. De opdrachtgever was er enthousiast over, maar had ook een kanttekening: als straks iedereen zulke AI-tools gebruikt, krijg je dan niet overal dezelfde uitwerkingen en dezelfde aanbiedingen?

Bij AI-tools voor tenders geef ik hem daarin gelijk. Als verschillende inschrijvers dezelfde tooling gebruiken, kom je op een gegeven moment op dezelfde EMVI-maatregelen uit.

Bij RQA zit het anders, en dat is juist het mooie en het menselijke eraan. RQA beoordeelt hoe een eis is opgeschreven, niet of het de juiste eis is. Wat je vraagt en hoeveel ruimte je laat, blijft aan de opdrachtgever. Wil je tot op detailniveau eisen specificeren, of bepaal je zelf de speelruimte en leg je de kansen bij de opdrachtnemers? Daar zit de ruimte voor innovatie en de kennis om tot mooie oplossingen te komen. Daarom kun je bij RQA de strengheid instellen, regels aan- of uitzetten en kiezen voor een lichte check, omdat eisen soms bewust ruimte laten voor de oplossing.

De oplossingen zelf bedenkt RQA niet. Die komen van mensen met kennis van zaken. Ik hoop dat dat zo blijft, al sluit ik niet uit dat AI daar op termijn een grotere rol in krijgt. Wat je daarna wel met RQA kunt doen, is die oplossingen scherp formuleren als nieuwe eisen.

### 05 | Benieuwd hoe dit er in de praktijk uitziet?

[Hier](https://basewise.ai/nl/rqa?hsLang=nl) lees je meer over hoe RQA werkt, of neem contact met ons op voor een toelichting op maat.

Bronnen

- Flyvbjerg, B., Holm, M.K.S. & Buhl, S.L. (2004). *What Causes Cost Overrun in Transport Infrastructure Projects?* Transport Reviews, 24(1), 3–18.
- Boehm, B. & Basili, V.R. (2001). *Software Defect Reduction Top 10 List.* IEEE Computer, 34(1), 135–137.

[Volledig bericht weergeven](https://basewise.ai/insights/programmas-van-eisen)

```json
{
  "@context" : "http://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Christian van Eken"
  },
  "dateModified" : "2026-10-21T10:09:10.865Z",
  "datePublished" : "2026-10-21T10:00:32Z",
  "headline" : "Het risico zit in de eisen: begin bij het formuleren",
  "image" : {
    "@type" : "ImageObject",
    "height" : 455,
    "url" : "https://48895798.fs1.hubspotusercontent-na1.net/hubfs/48895798/RQA%20problems.png",
    "width" : 733
  },
  "mainEntityOfPage" : "https://basewise.ai/insights/programmas-van-eisen",
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "height" : 60,
      "url" : "/hs/hsstatic/content_shared_assets/static-1.4092/img/default-amp-logo.png",
      "width" : 60
    },
    "name" : "Insights"
  }
}
```