Je legt acceptatiecriteria contractueel vast door per functie meetbare eisen op te schrijven, inclusief eisen aan snelheid, beveiliging en beschikbaarheid. Daarnaast spreek je een acceptatieprocedure af: wie test, hoe lang, met welke testset, welke bevindingen de acceptatie blokkeren, hoe de hertest verloopt en wanneer de software als geaccepteerd geldt.
Staat er in het contract alleen dat het systeem "facturen kan verwerken", dan hebben de projectleider, de inkoper en het ontwikkelteam elk een eigen beeld van wat dat betekent. Dit artikel beschrijft vanuit het project wat je vooraf vastlegt, zodat de oplevering eindigt in een besluit. Het gaat over de inhoud van de afspraken. Hoe een rechter ze uitlegt, valt buiten dit artikel.
Waarom de oplevering zo vaak in discussie eindigt
Onduidelijke eisen zijn duur, en ze worden duurder naarmate je ze later ontdekt. Barry Boehm en Victor Basili schreven in hun Software Defect Reduction Top 10 List (IEEE Computer, 2001) dat een probleem vinden en oplossen na de oplevering vaak 100 keer zo duur is als in de fase van eisen en ontwerp. Softwareprojecten besteedden volgens hetzelfde stuk 40 tot 50% van hun inspanning aan vermijdbaar herstelwerk, met haastig gespecificeerde eisen als een van de twee grote bronnen.
Het Project Management Institute kwam in zijn onderzoek naar requirements management uit 2014 op een vergelijkbaar beeld. Bij projecten die hun doelen niet haalden, was onnauwkeurig beheer van eisen in 47% van de gevallen de belangrijkste oorzaak. Van elke bestede dollar ging 5,1% verloren aan slecht requirements management.
De cijfers komen uit 2001 en 2014, en het patroon is nog altijd herkenbaar. Een discussie bij de oplevering draait meestal om een eis die op twee manieren te lezen was.
Wat goede acceptatiecriteria zijn
Een acceptatiecriterium is een voorwaarde waaraan de software moet voldoen om te worden goedgekeurd. Twee mensen moeten er onafhankelijk van elkaar dezelfde uitkomst uit halen. Een goed criterium is daarom:
- Meetbaar. Er staat een grens of een concrete uitkomst in, zoals een responstijd, een foutmelding of een berekende waarde.
- Per functie. Elk criterium hoort bij een benoemde functie of een proces uit het ontwerp, zodat je weet wat je test.
- Met een negatief scenario. Het criterium beschrijft ook wat er gebeurt bij foute invoer, ontbrekende rechten of een koppeling die niet antwoordt.
- Vooraf vastgesteld. Beide partijen kennen het criterium voordat de bouw begint.
Vergeet de niet functionele eisen niet. Snelheid, beschikbaarheid, beveiliging en onderhoudbaarheid blijven vaak impliciet, terwijl juist daar verwachtingen uiteenlopen. Het kwaliteitsmodel ISO/IEC 25010 beschrijft negen kwaliteitskenmerken en is een bruikbare checklist om na te gaan of je er een hebt overgeslagen. Maak ook die eisen meetbaar: noem het aantal gelijktijdige gebruikers waarbij een responstijd moet gelden en de datahoeveelheid waarmee je test.
Formuleringen als "gebruiksvriendelijk", "snel" of "zoals het huidige systeem" kun je niet toetsen. Zet ze om naar iets wat je kunt afvinken, of laat ze weg.
Acceptatiecriteria bij een user story en de acceptatie van een oplevering
De term acceptatiecriteria wordt voor twee verschillende dingen gebruikt. In een scrumteam horen ze bij een user story. De ISTQB omschrijft ze in de syllabus voor testers als de voorwaarden waaraan de uitwerking van een user story moet voldoen om door de betrokkenen te worden geaccepteerd. Ze bepalen de reikwijdte van de story, beschrijven positieve en negatieve scenario's en vormen de basis voor de test. De twee gangbare vormen zijn scenario's in de vorm Given/When/Then en een lijst met regels.
De acceptatie van een oplevering is een ander moment. Daar beslist de opdrachtgever formeel of een release, een deellevering of het geheel wordt goedgekeurd. Dat besluit heeft gevolgen: vanaf dat moment gaat vaak de garantie of het onderhoud in en kan een deel van de betaling opeisbaar worden.
Beide niveaus sluiten op elkaar aan. De criteria per story vormen samen een groot deel van de testset voor de oplevering. Daar komen de ketentest en de niet functionele eisen bij. Werk je iteratief, spreek dan uitdrukkelijk af of een story die de productowner in een sprint heeft goedgekeurd daarmee ook contractueel geaccepteerd is, of dat er aan het eind een aparte acceptatietest volgt.
Wat je in de acceptatieprocedure vastlegt
De acceptatieprocedure beschrijft hoe je van een levering tot een besluit komt. Leg in elk geval deze punten vast:
- Testperiode. Hoe lang de test duurt, wanneer die start en of productief gebruik in die periode is toegestaan.
- Testset en testdata. Welke testgevallen je uitvoert en met welke data. Gebruik je echte gegevens, dan zorg je ervoor dat dat mag.
- Testomgeving. Een aparte acceptatieomgeving die zoveel mogelijk lijkt op productie, met werkende koppelingen.
- Wie test. Namen of rollen, de beschikbare uren en wie het testverslag ondertekent.
- Classificatie van bevindingen. Welke categorieën er zijn en welke daarvan de acceptatie blokkeren.
- Hertest. Binnen welke termijn de leverancier herstelt en wat je bij de hertest opnieuw test.
- Het moment van acceptatie. Wanneer de software als geaccepteerd geldt, ook als niemand iets meldt, en wat ingebruikname betekent.
Die laatste afspraak blijft vaak liggen. Stilzwijgende acceptatie betekent dat de software als geaccepteerd geldt als je binnen de termijn geen bevindingen meldt, of zodra je haar in productie neemt. Een pilot die ongemerkt uitgroeit tot dagelijks gebruik kan zo een acceptatie worden. Plan ook de testcapaciteit van je eigen organisatie. Testers uit de lijn hebben meestal een volle agenda, en de testperiode loopt ook door als niemand tijd heeft.
Wat openbare voorwaarden als uitgangspunt nemen
Veel contracten verwijzen naar standaardvoorwaarden. Twee bekende sets in Nederland regelen de acceptatie verschillend. In de GIBIT geldt de standaardprocedure uit artikel 9 tenzij de overeenkomst, het implementatieplan of een testprotocol iets anders bepaalt. Kijk dus eerst welke set op je contract van toepassing is.
| Onderwerp | GIBIT 2025, artikel 9 | NLdigital Voorwaarden 2025, artikel 44 |
|---|---|---|
| Testperiode | Test na iedere levering, afgerond binnen vijf weken | Veertien dagen na aflevering of installatie |
| Productief gebruik | Ingebruikname voor productieve doeleinden geldt als acceptatie, tenzij dat door vertraging van de leverancier komt | Niet toegestaan tijdens de test; ingebruikname geldt als acceptatie |
| Einde testperiode | Partijen stellen samen een testverslag op en ondertekenen het | Geaccepteerd op de eerste dag na de testperiode |
| Kleine gebreken | Blokkeren niet als ze productief gebruik niet in de weg staan | Blokkeren niet; subjectieve aspecten zoals vormgeving ook niet |
| Deelleveringen | Na de laatste deellevering volgt een integrale acceptatie | Niet accepteren van een fase raakt eerdere fasen niet |
In de GIBIT 2025, de inkoopvoorwaarden van gemeenten, maakt de leverancier na het testverslag een herstelplanning en legt hij de levering opnieuw ter acceptatie voor. Wordt de levering een tweede keer afgekeurd, dan kan de opdrachtgever kiezen uit ontbinden, laten herstellen of voorwaardelijk accepteren. Van eenmalige vergoedingen is 30% pas opeisbaar na de integrale acceptatie. Meer over de voorwaarden lees je in ons artikel over GIBIT 2025.
De NLdigital Voorwaarden 2025 toetsen aan de functionele of technische specificaties die schriftelijk uitdrukkelijk zijn overeengekomen. Een fout moet aantoonbaar en reproduceerbaar zijn, en de testresultaten meld je uiterlijk op de laatste dag van de testperiode. Werken partijen volgens de iteratieve ontwikkelmethode uit artikel 50, dan vervalt het grootste deel van artikel 44 en aanvaardt de klant de software zoals die er aan het eind van de laatste ontwikkelfase bij staat. Spreken partijen dan testmomenten af, dan wordt alleen getest op objectieve, meetbare en vooraf overeengekomen criteria.
Welke bevindingen de acceptatie blokkeren
Zonder afgesproken classificatie wordt elke bevinding een onderhandeling. In een foutrapport hoort volgens de syllabus van ISTQB zowel de ernst (de impact) als de prioriteit om te herstellen. Voor de acceptatie is vooral de ernst van belang. Een indeling in drie niveaus is vaak genoeg:
- Blokkerend. Een kernproces kan niet worden uitgevoerd, er gaan gegevens verloren of een beveiligingseis wordt niet gehaald. Acceptatie volgt pas na herstel en hertest.
- Ernstig met omweg. De functie wijkt af van het criterium. Een tijdelijke omweg houdt het werk gaande. Je spreekt af of dit blokkeert en binnen welke termijn het wordt hersteld.
- Klein. Het werk kan zonder hinder door. Dit blokkeert de acceptatie niet en gaat naar de herstellijst.
Leg vast wie de indeling bepaalt, wat je doet bij verschil van inzicht en hoeveel ernstige bevindingen samen de acceptatie tegenhouden. De GIBIT kent daarnaast de mogelijkheid om in overleg een tijdelijke omweg te accepteren en de oplossing later te leveren. Zet in het testverslag per bevinding de categorie en de hersteldatum.
Hoe acceptatiecriteria samenhangen met het functioneel ontwerp
Acceptatiecriteria kun je pas goed opschrijven als duidelijk is wat de software moet doen. Die beschrijving staat in het functioneel ontwerp: de processen, de schermen, de regels en de koppelingen. Koppel elk criterium aan een onderdeel van dat ontwerp. Dan zie je direct welke functies nog geen criterium hebben en welke criteria nergens op aansluiten.
Wijzigt het ontwerp tijdens de bouw, dan wijzigen de criteria mee, via dezelfde wijzigingsprocedure en met een datum. Zo test je bij de oplevering tegen de laatste afgesproken versie.
Wie maatwerk software laat bouwen, heeft vanaf de eerste sprint baat bij die lijn van ontwerp naar criterium naar test.
Wij bouwen al ruim 30 jaar software, met 30+ engineers in Nijmegen en Sarajevo, en leverden 100+ projecten op, van MRO software voor de luchtvaart tot een platform voor subsidieadministratie en RFID in de supply chain. We werken volgens ISO 9001 en ISO 27001. Op onze pagina over QA en testen lees je hoe we handmatig en geautomatiseerd testen, en in de cases zie je voor wie we bouwden. Plan een gesprek en we kijken mee naar de acceptatiecriteria van je volgende project.
Veelgestelde vragen
Wat zijn acceptatiecriteria?
Acceptatiecriteria zijn de vooraf afgesproken voorwaarden waaraan software moet voldoen om te worden goedgekeurd. Goede criteria zijn meetbaar, horen bij een benoemde functie en beschrijven ook wat er gebeurt bij foute invoer. Ze gelden voor functionele eisen en voor niet functionele eisen zoals snelheid en beveiliging.
Wat is het verschil tussen acceptatiecriteria en een acceptatietest?
Acceptatiecriteria beschrijven waaraan de software moet voldoen. De acceptatietest is de uitvoering: de opdrachtgever voert in een afgesproken periode een testset uit en stelt vast of de criteria worden gehaald. De uitkomst staat in een testverslag.
Wat is stilzwijgende acceptatie bij software?
Bij stilzwijgende acceptatie geldt software als geaccepteerd zonder uitdrukkelijk besluit, bijvoorbeeld omdat de testperiode verloopt zonder melding of omdat de opdrachtgever de software in productie neemt. Zowel de GIBIT 2025 als de NLdigital Voorwaarden 2025 bevatten een regeling voor ingebruikname. Spreek daarom vooraf af wanneer acceptatie plaatsvindt.
Wie stelt de acceptatiecriteria op?
De opdrachtgever is eigenaar van de criteria, omdat die bepalen wanneer het resultaat bruikbaar is. In de praktijk stel je ze samen op: de productowner of projectleider levert de eisen uit het proces, de leverancier toetst of ze meetbaar en haalbaar zijn.
