Mijn eerste jaar als docent bij het ontwerpproject in het eerste kwartaal van het eerste jaar van Werktuigbouwkunde richtte ik me bij het programma van eisen vooral op het uitleggen van toetsbaarheid: operationalisatie en toegankelijkheid. Maar op het tentamen bleek dat studenten dat compleet verkeerd begrepen hadden. In plaats van dat ze keken naar of een criterium objectief meetbaar was (bijv. ‘zo licht mogelijk’), hadden ze vooral opgepikt dat er een harde grens moest zijn (bijv. ‘lichter dan de vorige versie’). Als er wél een grens was, maar géén objectief meetbare grootheid, dan rekenden ze het criterium goed (bijv. ‘makkelijker te gebruiken dan het product van de concurrent’). Vice versa hadden studenten begrepen dat criteria zonder harde grens, maar wel met een goed meetbare variable, niet goed waren (bijv. ‘zo goedkoop mogelijk’).
Het volgende jaar heb ik daarom niet alleen aandacht besteed aan toetsbaarheid, maar ook aan verschillende typen criteria. Het belangrijkst daarbij was het onderscheid tussen functionele eisen (‘Wat MOET het doen?’) en prestatiecriteria (‘Wanneer doet het dat GOED?’). Maar ook randvoorwaarden en specificaties had ik onderdeel van de stof gemaakt. Dit ging beter, maar het verschil tussen die 4 typen criteria kreeg ik maar lastig overgebracht.
De ronde dáárop besloot ik om de stof in het eerste kwartaal te beperken tot de absolute kern. Toetsbaarheid legde ik grondig uit. Maar zaken zoals validiteit en compleetheid van het programma van eisen liet ik buiten beschouwing. En wat betreft de verschillende typen criteria bracht ik het terug tot het belangrijkste onderscheid: wat MOET het doen, en hoe meten we of het dat GOED doet? In andere woorden: alleen functionele eisen en prestatiecriteria. Dat was erg effectief. Maar het leverde in het tweede kwartaal wel heel vreemde programma’s van eisen op, waarin bijvoorbeeld ‘lengte maximaal 30cm’ onder ‘functionele eisen’ staat.
Ik ben er nog niet tevreden over. Deel van het probleem is waarschijnlijk dat ik een beter plan moet hebben van wat je in het eerste kwartaal/ontwerpproject behandelt, wat in het tweede en/of derde, en hoe. Maar ik wil ook het onderscheid tussen die vier typen criteria (functionele eisen, prestatiecriteria, randvoorwaarden, en specificaties) in een heldere structuur vangen zonder meteen hele lappen tekst zoals in Roozenburg & Eekels over mijn studenten uit te storten.
Het lijkt erop dat dit moet kunnen met iets in de richting van een Venn diagram. Een functionele eis is immers:
- Binair, zwart-wit, met een harde grens – in tegenstelling tot prestatiecriteria, waarop je wisselend kunt scoren.
- Oplossingsonafhankelijk geformuleerd – in tegenstelling to specificaties, wat voorgeschreven ontwerpbeslissingen zijn.
- Een doel voor het te ontwerpen object zelf – in tegenstelling tot randvoorwaarden, die grenzen aan de te gebruiken ruimte en middelen stellen.
Prestatiecriteria (wensen), randvoorwaarden, en specificaties zijn elk ten opzichte van functionele eisen te definiëren doordat ze op één van die drie eigenschappen het tegenovergestelde van functionele eisen zijn. Hoe je dat precies verwoord. Als je dat als 3 overlappende gebieden visualiseert zou dat er misschien zo uit kunnen zien:
Je zou ook termen voor de grenzen kunnen geven, of die grenzen definiëren in termen van drie tegenstellingen. Dat zou eventueel zoiets kunnen worden:
Update: het eindresultaat (interactieve video van 3 minuten).