Requirements, user stories en acceptatiecriteria¶
Bij het ontwikkelen van software is het cruciaal om een helder en gestructureerd overzicht te hebben van wat de software moet doen en hoe deze moet presteren. Dit begint met het opstellen van requirements, oftewel vereisten, die de basis vormen voor het ontwerp en de implementatie van de software. Requirements helpen ontwikkelaars, ontwerpers en belanghebbenden om een gemeenschappelijk begrip te creëren van de verwachtingen en functionaliteiten van het systeem.
In dit artikel wordt besproken hoe je software requirements formuleert, deze vervolgens vertaalt naar user stories en bijbehorende acceptatiecriteria opstelt. Er wordt een onderscheid gemaakt in functionele en niet-functionele requirements.
Functionele requirements¶
Functionele requirements beschrijven wat de software moet doen. Ze specificeren de functionaliteiten en gedragingen van het systeem, zoals invoer, verwerking en uitvoer van gegevens.
Voorbeelden van goed geformuleerde functionele requirements
“De gebruiker moet in staat zijn om in te loggen met een gebruikersnaam en wachtwoord.”
Toelichting: Dit is specifiek en beschrijft een duidelijke functionaliteit.
“Het systeem moet gebruikers in staat stellen om hun wachtwoord te resetten via een e-mailverificatie.”
Toelichting: Dit geeft een specifieke actie aan die de gebruiker kan ondernemen.
Voorbeelden van slecht geformuleerde functionele requirements
“De software moet goed werken.”
Toelichting: Dit is vaag en niet meetbaar. Wat betekent “goed werken”?
“De applicatie moet snel zijn.”
Toelichting: Dit is subjectief en geeft geen specifieke functionaliteit aan.
Niet-functionele requirements¶
Niet-functionele requirements beschrijven de kwaliteitseisen waaraan de software moet voldoen. Dit omvat aspecten zoals prestaties, beveiliging, gebruiksvriendelijkheid en onderhoudbaarheid.
Voorbeelden van goed geformuleerde niet-functionele requirements
“De applicatie moet binnen 2 seconden reageren op gebruikersinvoer.”
Toelichting: Dit is een meetbare eis die de prestaties van de software definieert.
“De software moet voldoen aan de AVG (Algemene Verordening Gegevensbescherming) voor databeveiliging.”
Toelichting: Dit geeft een duidelijke richtlijn voor de beveiligingseisen.
Voorbeelden van slecht geformuleerde niet-functionele requirements
“De software moet gebruiksvriendelijk zijn.”
Toelichting: Dit is subjectief en niet specifiek. Wat is “gebruiksvriendelijk”?
“De applicatie moet veilig zijn.”
Toelichting: Dit is te vaag en biedt geen concrete richtlijnen voor beveiliging.
Van requirements naar user stories¶
User stories zijn een veel gebruikte manier om requirements te vertalen naar een meer begrijpelijke en gebruikersgerichte vorm. Een user story volgt meestal de structuur:
“Als [type gebruiker] wil ik [doel], zodat [reden].”
Voorbeeld van een goed geformuleerde user story
“Als gebruiker wil ik in kunnen loggen met een gebruikersnaam en wachtwoord, zodat ik toegang heb tot mijn persoonlijke dashboard.”
Toelichting: Deze user story maakt duidelijk wie de gebruiker is, wat ze willen en waarom.
Voorbeelden van slecht geformuleerde user stories
“De software moet een inlogfunctie hebben.”
Toelichting: Dit is geen user story, omdat het niet de gebruiker of de reden beschrijft.
“De applicatie moet snel zijn.”
Toelichting: Dit is een niet-functioneel requirement en geen user story.
Acceptatiecriteria¶
Acceptatiecriteria zijn de voorwaarden waaraan een requirement of user story moet voldoen om als voltooid te worden beschouwd. Ze maken het resultaat meetbaar en helpen bij het testen en verifiëren of de functionaliteit correct is geïmplementeerd.
Voorbeelden van goed geformuleerde acceptatiecriteria
“De gebruiker kan inloggen met een geldig gebruikersnaam en wachtwoord.”
“De gebruiker ontvangt een foutmelding bij een ongeldige inlogpoging.”
“De gebruiker kan zijn wachtwoord resetten via een e-mailverificatie.”
Voorbeelden van slecht geformuleerde acceptatiecriteria
“De inlogfunctie moet goed werken.”
Toelichting: Dit is vaag en niet meetbaar.
“De applicatie moet veilig zijn.”
Toelichting: Dit biedt geen specifieke criteria voor acceptatie.
Regels voor het opstellen van requirements, user stories en acceptatiecriteria¶
Om requirements, user stories en acceptatiecriteria op te stellen is het verstandig om je te houden aan een aantal basisregels:
- Identificeer de belanghebbenden: praat met gebruikers, ontwikkelaars en andere betrokkenen om hun behoeften en verwachtingen te begrijpen.
- Gebruik de SMART-methode: zorg ervoor dat je requirements en user stories Specifiek, Meetbaar, Acceptabel, Realistisch en Tijdgebonden zijn:
- Specifiek: Het moet duidelijk en ondubbelzinnig zijn. Wat moet er precies gebeuren?
- Meetbaar: Er moet een manier zijn om te bepalen of er is voldaan aan een requirement of user story. Je kunt hiervoor criteria opstellen.
- Acceptabel: Het moet acceptabel zijn voor alle belanghebbenden. Dit betekent dat het moet voldoen aan hun verwachtingen en behoeften.
- Realistisch: Het moet haalbaar zijn binnen de gegeven middelen en tijdslijnen.
- Tijdgebonden: Dit is niet altijd noodzakelijk, maar als er een tijdsaspect relevant is voor de functionaliteit of prestatie, moet dit worden opgenomen.
- Documenteer en review: schrijf alles duidelijk op en laat het reviewen door belanghebbenden om ervoor te zorgen dat het correct en volledig is.
- Prioriteer: bepaal welke requirements/user stories essentieel zijn voor de eerste versie van de software en welke later kunnen worden toegevoegd. Gebruik hiervoor de MoSCoW methode. Meer informatie over deze methode vind je deze Knowledgebase.