## Iedere reviewer een andere checklist

We passen altijd filters toe

De volgende situatie is waarschijnlijk bekend: je kijkt op je horloge om te zien of je nog tijd hebt voor een kop koffie. Je concludeert dat dat best nog kan. Dan vraagt ​​iemand in de rij van de koffiecorner hoe laat het is. Je moet opnieuw naar je horloge kijken.

Dit gebeurt omdat je de eerste keer naar je horloge keek met de vraag : "heb ik tijd voor koffie?", wat een berekening vereist met de huidige tijd en de deadline die je hebt. De huidige tijd is niet 'opgeslagen in het geheugen', je vergeet het zodra je het antwoord op je vraag weet. Misschien heb je iets opgeslagen als "Ik heb vijf minuten".

Nog een voorbeeld: Je bent op zoek naar een meisje in een menigte (café? Treinstation? Klaslokaal?). Zie je haar? Nee. Je loopt verder. Wanneer iemand vraagt: Wie heb je gezien? weet je dat niet. Het enige dat je weet is dat zijer niet was.

Checklists bieden het juiste filter
Als we iets zoeken, filteren we onze waarnemingen naar onze zoekvraag. Vertaald naar inspecties betekent dit dat het uitermate moeilijk is om spelfouten en goede ontwerpkeuzes op hetzelfde moment te zoeken.

De checklist zal het filter van de reviewer focussen en ervoor zorgen dat elke reviewer een andere focus heeft, waardoor het resultaat gemaximaliseerd wordt (het aantal mogelijke verschillende gevonden problemen).

Format van een inspectiechecklist
Een inspectiechecklist bestaat uit vragen die twee mogelijke antwoorden hebben:

- Ja (alles is goed)
- Nee (hier is mogelijk een probleem)

Wanneer je nog nooit een inspectie hebt gedaan kun je de volgende drie basisvragen gebruiken voor iedere checklist:

1. Standaarden, b.v.
   - Codeerstandaard
   - Spelling en grammatica
   - Documentatiestandaard
   - Methodestandaard (UML, Archimate, PBMN, enz.)
2. Overeenstemming met de input
   - Is het product compleet?
   - Is het product correct?
3. Bruikbaarheid
   - Begrijp ik dit?
   - Kan ik dit gebruiken?

Voorbeeld checklist voor Functioneel Ontwerp