Antwoord

Een businessanalist moet de acceptatiecriteria (acceptance criteria) voor elke vereiste formaliseren, zodat ze duidelijk en ondubbelzinnig zijn voor alle projectdeelnemers: de klant, ontwikkelaars en testers. Hiervoor worden specificatietechnieken toegepast, zoals het formuleren van criteria in Gherkin-notaties (Given-When-Then), checklists en use cases. De analist documenteert de criteria in de vereistenartefacten en zorgt ervoor dat er voor elke vereiste een set objectieve voorwaarden is waarmee de voltooiing van de taak ondubbelzinnig kan worden bevestigd.

Belangrijke kenmerken:

• Duidelijke, meetbare formulering van criteria met zakelijke en technische termen.
• De betrokkenheid van de klant bij de bevestiging van de criteria vóór de start van de ontwikkeling.
• Inclusie van criteria in gebruikersverhalen, specificaties en testcases.

Misleidende vragen.

Kan men gebruikersverhalen alleen gebruiken om vereisten te beschrijven, zonder aanvullende acceptatiecriteria?

Nee, gebruikersverhalen zonder expliciete acceptatiecriteria zijn te abstract en kunnen op verschillende manieren worden geïnterpreteerd. Criteria zijn nodig om te begrijpen of de vereiste correct is geïmplementeerd.

Moeten niet-functionele vereisten (bijvoorbeeld prestaties) worden opgenomen in de acceptatiecriteria?

Ja, niet-functionele vereisten moeten ook worden geformaliseerd in de criteria, anders is het risico groot dat ze ongemerkt worden vergeten of niet volledig worden geïmplementeerd.

Wie moet de acceptatiecriteria goedkeuren: alleen de businessanalist?

Nee, het is altijd noodzakelijk om de criteria met de klant en, indien mogelijk, het ontwikkelingsteam af te stemmen om misverstanden te minimaliseren.

Veelgemaakte fouten en anti-patronen

• Het negeren van de afstemming van criteria met de klant.
• Het laten over aan het ontwikkelingsteam om de criteria te bepalen.
• Het laat toevoegen van criteria na de start van het werk.

Voorbeeld uit de praktijk

Negatieve case: De businessanalist heeft de acceptatiecriteria niet met de klant afgestemd, en de ontwikkelaars interpreteerden de vereisten op hun eigen manier. Voordelen: Snelle ontwikkeling, geen vertraging door gesprekken. Nadelen: Na de release voldeed 70% van de functionaliteit niet aan de werkelijke verwachtingen, wat leidde tot een conflict.

Positieve case: De analist heeft formele acceptatiecriteria opgesteld, deze met beide partijen afgestemd en toegevoegd aan de gebruikersverhalen. Voordelen: Begrip tussen de klant en het team, minimaal aantal bugs na de release. Nadelen: Aan het begin kostte het iets meer tijd voor afstemming.