Functionele requirements zoals we die nu maken worden gekenmerkt door:
- ze zijn beschrijvend opgesteld, in de derde persoon enkelvoud. Ofwel, ze hebben het format: Het systeem moet … zus of zo … kunnen.
- de requirements zijn tijdloos, en kunnen in willekeurige volgorde opgesomd worden. Ze bevatten geen informatie over de proces flow.
Op deze wijze opgeschreven requirements noem ik daarom statisch beschrijvende functionele requirements.
Ze geven ruimte aan verschillende interpretaties. Tegelijkertijd zijn ze wel de basis voor het hele verdere ontwikkelproces.
De statisch beschrijvende functionele requirements zijn abstract en academisch. Toch leggen we de verantwoordelijkheid voor de beoordeling van deze requirements bij de mensen met de meeste kennis van het proces. De klant moet beoordelen of ze kunnen werken met het systeem wat hieruit gebouwd gaat worden. En dat is het probleem: Eindgebuikers denken niet abstract maar concreet. Hun schat aan concrete proceskennis kunnen ze daarom maar heel moeilijk terugvinden in de abstract geformuleerde requirements.
En hier zit de opdrachtgever met een dilemma:
- Eigenlijk wil hij niet tekenen voor de opdracht tot bouw omdat de requirements niet concreet genoeg zijn. De requirements zijn niet reviewbaar door eindgebruikers die de gedetailleerde proceskennis bezitten.
- Maar hij moet wel tekenen om überhaupt iets concreets te krijgen dat de eindgebruikers kunnen reviewen.
Dit is het Requirements Review Dilemma.