Posted on by wrote in Agile.

Het meest moeilijke waar teams tegenaan lopen is het afronden van user stories in een iteratie. Duidelijke user stories zijn goed te testen. Door de testbaarheid van je user stories te verhogen ontstaat kwaliteit. Er zijn user stories die altijd moeilijk testbaar zijn en ze kunnen ook niet in een iteratie worden afgerond. Deze user stories worden non-functional requirements genoemd en vormen de fundering van een product.

Goede user stories zijn testbaar zodat ze kunnen worden afgerond. Duidelijke user stories zijn goed te testen zodat het ontwikkelteam weet dat er geen programmeerwerk meer nodig is. In mijn werk de afgelopen 12 jaar heb ik mij groen en geel geërgerd aan onderdelen die fouten vertoonde door aanpassingen of introducties van nieuwe onderdelen.

Automatisch heeft de voorkeur

Om de kwaliteit te verhogen van het gehele product ben ik groot voorstander van automatische tests. Ieder onderdeel in het product dat een stuk waarde representeert voor de business zou een automatische test moeten bevatten naar mijn mening. Het ontwikkelteam weet dan bij het ontwikkelen van nieuwe onderdelen wat er stuk is gegaan door de introductie hiervan. Hiermee ontstaat niet alleen een verhoogde kwaliteit maar ook rust in het team. De opdrachtgever moet het hier natuurlijk wel mee eens zijn. Indien deze hier niet voor kiest is het wel nodig om de gevaren en het risico kenbaar te maken.

Non-functional requirements

Er zijn dus user stories die moeilijk testbaar zijn. Deze user stories vallen veelal onder de zogeheten non-functional requirements (aanvullende eisen). Deze non-functional requirements hebben allemaal een gemeenschappelijke eigenschap. Deze kun je niet op het planboard plaatsen of in de backlog van je product. Ze kunnen namelijk niet worden afgerond als los onderdeel omdat ze gelden voor je gehele product. Laten we eerst eens kijken naar een aantal voorbeelden van non-functional requirements.

Als gebruiker wil ik dat de applicatie gebruiksvriendelijk is zodat ik niet gefrustreerd raak

Als gebruiker wil ik niet lang wachten voordat een scherm geladen is zodat ik niet gefrustreerd raak

Deze non-functional-requirements zijn niet te bouwen als onderdeel maar gelden dus voor het gehele product. Deze voorbeelden zijn niet testbaar laat staan dat deze tests geautomatiseerd kunnen worden. Ga altijd voor jezelf na hoe non-functional requirements testbaar gemaakt kunnen worden. Vroeg of laat kom je deze namelijk tegen in de acceptatie van de applicatie. De bovenstaande user stories kunnen op de volgende manier herschreven worden zodat automatische tests mogelijk worden.

Als gebruiker wil ik dat de navigatiestructuur niet dieper is dan 3 niveaus zodat ik niet de weg kwijt raak ik de structuur

Als gebruiker wil ik dat 90% van de schermen binnen 3 seconden geladen zijn zodat ik niet gefrustreerd raak

Indeling in categorieën

Natuurlijk zijn er meerdere user stories mogelijk voor non-functional requirements. De bovenstaande voorbeelden zijn enkel voor usability en prestatie. Non-functional requirements bestaan in een aantal categorieën. Hieronder een overzicht.

Proces

  • Documentatie
  • Business controle of audit
  • Herstel
  • Onderhoudbaarheid

Product

  • Beveiliging
  • Prestatie
  • Capaciteit
  • Beschikbaarheid
  • Betrouwbaarheid
  • Integriteit
  • Compatabiliteit en interfacing
  • Usability

Extern

  • Sociaal
  • Wetgeving
  • Economisch
  • Politiek
  • Technisch

Als metafoor kun je de non-functional requirements zien als de fundering van een gebouw.

Als in het project blijkt dat je een flat aan het bouwen bent maar de fundering is bedacht voor een woonhuis, ontstaan er problemen in de betrouwbaarheid van de constructie.

Met deze blog komt een einde aan een serie blogs over het ezelsbruggetje INVEST. Ik ben benieuwd of er teams zijn die goed met non-functional requirements omgaan of een andere benadering hebben die werkt.

Referenties

Tags: , , ,