Niet-functionele eisen als User Stories
In de Product Backlog worden de eisen voor een product vastgelegd. Als je deze vanuit het perspectief van de gebruiker wilt formuleren, wordt vaak het User Story-format gebruikt. Hierin worden de functionele eisen voor het product helder en specifiek beschreven. Maar hoe zit het met de niet-functionele eisen? Ook die horen thuis in een Product Backlog. Hier lees je waarom niet-functionele eisen belangrijk zijn en hoe je ze het beste kunt integreren in de Product Backlog, bijvoorbeeld aan de hand van het User Story Template.
De verschillen tussen functionele en niet-functionele requirements
In productmanagement wordt al lange tijd onderscheid gemaakt tussen functionele en niet-functionele requirements. Ook bij agile requirements management worden deze twee begrippen van elkaar onderscheiden. Hier lichten we kort de verschillen toe.
Functionele vereisten
Deze eisen beschrijven concrete functies en specificaties van het product. Als User Story worden de eisen zo nauwkeurig en volledig mogelijk opgesomd die belangrijk zijn voor de gebruiker. Het gaat om productspecifieke eisen die doorgaans niet zomaar op elk willekeurig ander product kunnen worden toegepast. Deze voorbeelden zijn typische functionele eisen:
Als gebruiker van een tekstverwerkingsprogramma wil ik een tabel kunnen invoegen.
Het programma moet op basis van een formule het caloriegehalte van het menu kunnen berekenen.
Niet-functionele vereisten
Niet-functionele eisen zijn minder specifiek. Ze beschrijven bijvoorbeeld een kwaliteit, een voorwaarde of een eigenschap van het product. Deze eisen zijn niet per se productspecifiek. Ze kunnen algemeen gelden voor meerdere producten of zelfs voor het complete ontwerp of de architectuur van een software:
Gebruiksvriendelijke interface
Snelle reactietijden
Door hun niet-specifieke karakter bestaat het gevaar dat deze eisen bij het opstellen van de Product Backlog stiefmoederlijk worden behandeld. Toch zouden deze eisen daar wel in moeten staan, omdat ze voor de gebruiker van groot belang zijn. Wanneer kwaliteit, betrouwbaarheid of snelheid niet worden afgestemd op de behoeften van de klant, dan zal het product hoogstwaarschijnlijk niet worden gebruikt — functionaliteit alleen is namelijk niet genoeg om gebruikers tevreden te stellen. Daarom is de vraag hoe niet-functionele eisen in de productontwikkeling kunnen worden opgenomen. Het helpt om ze als User Story te formuleren, zodat je dit type eisen kunt prioriteren.
Zo kun je niet-functionele eisen in Scrum als User Stories beschrijven
- Niet-functionele eisen moeten meetbaar beschreven worden
- Niet-functionele eisen vanuit het perspectief van de klant bekijken
- Is de niet-functionele eis misschien beter op zijn plek in de "Definition of Done"?
Niet-functionele eisen moeten meetbaar beschreven worden
De uitspraak dat je pagina een zo snel mogelijke reactietijd moet hebben, is voor het ontwikkelteam te vaag. Hier worden geen meetbare eisen beschreven. "Snel" is in dit geval een onnauwkeurige uitspraak die vrijwel elke ontwikkelaar anders definieert.
Voor het team is het in dit voorbeeld nuttig als het precieze specificaties krijgt. Deze kunnen gezamenlijk worden uitgewerkt. Een middel kan een beperking zijn die met betrekking tot de eis wordt gesteld. Daardoor worden eigenschappen tastbaarder en kunnen ze probleemloos worden geïmplementeerd. De eis kan hier bijvoorbeeld luiden:
De pagina moet in minder dan x seconden laden.
Het calorieënverbruik moet na de klik in minder dan 8 seconden worden weergegeven.
Niet-functionele eisen vanuit het perspectief van de klant bekijken
Bij het opstellen van User Stories is het belangrijk dat alle betrokkenen zich verplaatsen in het perspectief van de klant. Voor het schrijven van een User Story kan het handig zijn om met behulp van een vast format het product concreet voor je te zien:
„Als <gebruiker> wil ik <doel>, zodat <reden>"
Dit simpele format kan jou en je team helpen om naar de reden achter een vereiste te vragen. Waarom kan het voor een gebruiker belangrijk zijn dat het caloriegebruik van het menu in minder dan 8 seconden wordt weergegeven? Omdat de gebruiker dan snel een referentiewaarde heeft waarmee hij zelf het menu binnen zijn eigen tijdsplanning kan samenstellen.Je moet hier echter het resultaat kritisch bekijken en de formule alleen als "denkhulpmiddel" beschouwen. Als het antwoord op de "waarom?"-vraag te ingewikkeld of verwarrend uitvalt, zoek dan het directe gesprek met de klant of gebruiker op. Vraag de mensen waarom een bepaalde eigenschap voor hen persoonlijk belangrijk is. Soms blijkt dat een niet-functionele vereiste helemaal niet zo vaag is, maar gewoon onnauwkeurig geformuleerd.
Is de niet-functionele requirement misschien beter op zijn plek in de „Definition of Done"?
Gaat het om overkoepelende punten zoals bijvoorbeeld de reactietijden van een programma? Dan kan het zinvol zijn om deze op te nemen in de „Definition of Done". Samen met je team en eventueel de stakeholders kun je overwegen of een snelle reactietijd niet standaard een criterium voor het hele systeem zou moeten zijn.
Het opnemen van een niet-functionele requirement in de Definition of Done betekent dat elk item hieraan moet voldoen. Dat is voordelig als het bijvoorbeeld gaat om een design en de conformiteit met de corporate identity of iets dergelijks.
Niet-functionele eisen omzetten naar functionele eisen
Niet-functionele eisen kunnen, net als functionele eisen, als User Story worden geformuleerd. Dat zou ook moeten gebeuren, zodat ze niet over het hoofd worden gezien of worden verwaarloosd. Belangrijk is dat ze meetbaar worden geformuleerd en op de een of andere manier worden afgebakend. Als je zelf geen afbakening kunt maken, helpt de hierboven gepresenteerde formule je verder. Die vraagt naar het „Waarom?" en kan zo een hulpmiddel zijn om je gedachten te ordenen. Verder helpt een direct gesprek met je team, de gebruikers of stakeholders.
Eerste informatie over Scrum en User Stories vind je op onze website. Wil je diepgaande kennis over Scrum opdoen? Meld je dan het beste aan voor een Scrum training en leer de basisprincipes van agile werken!
