Vrijwel elk mislukt IT-project heeft ergens in zijn geschiedenis een requirement die te vaag was om daadwerkelijk te bouwen — en te vaag om achteraf te toetsen of het resultaat wel klopte. "Het systeem moet snel zijn", "de interface moet intuïtief aanvoelen", "rapportages moeten flexibel zijn". Iedereen knikt tijdens de vergadering. Niemand kan zes maanden later zeggen of eraan is voldaan.
Het probleem met vage requirements is niet dat ze onwaar zijn — snelheid en gebruiksvriendelijkheid zijn legitieme wensen. Het probleem is dat ze niet toetsbaar zijn, en dus ruimte laten voor elke partij om er iets anders onder te verstaan.
Het verschil tussen een wens en een requirement
Een requirement die zijn naam waardig is, is specifiek, meetbaar en ondubbelzinnig. Het verschil wordt het duidelijkst in een direct voorbeeld.
Het verschil lijkt op het eerste gezicht vooral bureaucratisch — meer woorden voor hetzelfde idee. In werkelijkheid is het het verschil tussen een eis waar een ontwikkelaar tegen kan bouwen en testen, en een eis die pas bij oplevering tot discussie leidt over wat "snel" eigenlijk betekende.
Een requirement die niet getest kan worden, is eigenlijk geen requirement — het is een goede bedoeling.
Waarom vage requirements zo hardnekkig zijn
Vage requirements ontstaan zelden uit onzorgvuldigheid. Ze ontstaan omdat specificeren tijd kost, en omdat stakeholders in een vroeg stadium vaak zelf nog niet precies weten wat ze willen. "Gebruiksvriendelijk" voelt op dat moment als een compleet genoeg antwoord — totdat de bouwfase begint en blijkt dat drie verschillende mensen drie verschillende dingen bedoelden.
Functionele versus niet-functionele eisen: allebei nodig, allebei vaak vaag
Functionele eisen — wat het systeem moet doén — krijgen meestal wel de nodige aandacht, simpelweg omdat ze zichtbaar zijn in de uiteindelijke functionaliteit. Niet-functionele eisen — prestatie, beveiliging, beschikbaarheid, schaalbaarheid — worden vaker overgeslagen of te vaag gehouden, terwijl ze net zo bepalend zijn voor of een systeem in de praktijk bruikbaar is.
Een korte checklist om requirements te toetsen
- Kan ik dit toetsen met een concreet getal, een ja/nee-antwoord, of een observeerbaar gedrag?
- Zou een ander teamlid deze requirement op dezelfde manier interpreteren als ik?
- Weet ik wie verantwoordelijk is om te bevestigen dat aan deze eis is voldaan?
- Staat scope-uitsluiting er ook expliciet bij — wat valt hier bewust niet onder?
In het kort
- Een requirement die niet toetsbaar is, is een wens, geen eis om tegen te bouwen
- Vage requirements ontstaan vaak omdat stakeholders zelf nog niet precies weten wat ze willen
- Niet-functionele eisen (prestatie, beveiliging) worden structureel vaker te vaag gelaten dan functionele
- Twee redelijke interpretaties van dezelfde eis betekenen: de eis is nog niet af
Tijd investeren in het scherp krijgen van requirements voelt traag aan het begin van een project. Het bespaart bijna altijd meer tijd dan het kost — namelijk precies de tijd die anders verloren gaat aan discussies achteraf over wat er eigenlijk was afgesproken.