SMART requirements vs use cases vs user stories

Analisten stellen mijn geregeld de vraag: ‘Welke techniek kan ik het beste gebruiken om requirements te definiëren: SMART requirements, use cases, user stories of een combinatie daarvan?’

‘Dat hangt van je project af’ zeg ik dan meestal.

In een traditionele omgeving zijn use cases vaak een goede optie. User stories zijn populair in agile omgevingen en Use Case 2.0 is een goed alternatief. In projecten zie je vaak dat use cases en user stories gecombineerd worden. In de meeste gevallen raad ik dat af. Een opsomming van SMART requirements zinnen zou ik alleen gebruiken voor niet-functionele requirements.

Toelichting en nuancering

Hieronder licht ik toe wat SMART requirements, use cases en user stories zijn en wanneer je ze gebruikt.

SMART requirements zinnen

Software requirements moeten SMART geformuleerd worden en beginnen doorgaans met ‘Het systeem moet …’.

Voorbeeld van software requirements zijn:

  • Het systeem moet bij het reserveren van een vergaderruimte de overnachtings­mogelijk­heden laten zien.
  • Het systeem moet de relevante vacatures zoeken door de vacatureteksten te door­zoeken op de ingevulde trefwoorden.
  • Het systeem moet opnieuw naar de pincode vragen als uit de controle blijkt dat de eerder ingevoerde pincode onjuist is. Het systeem moet in totaal maximaal drie keer naar de pincode vragen.

Deze requirements zinnen moeten atomair zijn (niet meer dan één requirements bevatten) en aan het SMART acroniem voldoen. SMART is een aanduiding voor de voornaamste kwaliteitscriteria  voor requirements. De SMART criteria worden ook gebruikt voor het formuleren van persoonlijke doelen. Daar komen ze oorspronkelijk vandaan.

De letters in SMART staan voor:

  • Specifiek: een requirement moet exact en expliciet aangeven wat er gewenst is
  • Meetbaar: het moet mogelijk zijn om objectief vast te stellen of aan de requirement is voldaan
  • Acceptabel: de belanghebbenden moeten het met de requirement eens zijn
  • Realistisch: het moet mogelijk zijn om aan de requirement te voldoen met de middelen die beschikbaar zijn 
  • Tijdsgebonden: het moet duidelijk zijn op welk moment in de tijd aan de requirement voldaan moet zijn

Sinds het ontstaan van het vakgebied Requirements Engineering verwoorden we met deze zinnen de functionele en niet-functionele eisen aan het systeem (softwarerequirements).

Aan het begin van deze eeuw verschoof de focus echter van systeemeisen naar de behoeften van de gebruikers. De te ontwikkelen software moet immers van toegevoegde waarde zijn voor de gebruikers. Vanaf dat moment werden naast software requirements ook business requirements en user requirements onderscheiden.

Je kunt de SMART requirements zinnen ook voor business en user requirements gebruiken. Maar use cases zijn beter geschikt voor het specificeren van requirements vanuit het oogpunt van de gebruikers. Daar zijn ze voor uitgevonden.

Wat mij betreft genieten use cases dan ook de voorkeur boven (lange) opsommingen van SMART requirements zinnen.

Use cases

Met use cases leg je de focus op de gebruiker en hoe hij zijn doel met behulp van het systeem wil behalen. In een use case groepeer je alle (gedetailleerde) requirements die nodig zijn om dat gebruikersdoel te realiseren. Als het goed is, kom je voor een project uit op 20 tot maximaal 50 use cases.

In een use case beschrijving leg je de gewenste acties van de gebruiker en van het systeem stapsgewijs vast. Dit zijn de user requirements en de functionele software requirements. Het zou dubbelop zijn om die requirements ook nog in SMART requirements zinnen vast te leggen.

Anders is dat voor de use case overstijgende requirements. Die requirements gelden voor een groot aantal of alle use cases en moet je dus elders vastleggen. Het gaat dan voornamelijk om business requirements ofwel high level doelen en niet-functionele requirements. Voor beide zijn SMART requirements zinnen zeer geschikt.

Tegenwoordig is er in agile projecten minder behoefte aan documentatie. Requirements worden just in time opgesteld en voor een groot deel mondeling overgedragen. Om die nieuwe werkwijze te ondersteunen is in 2011 een gemoderniseerde versie van de use case techniek, Use Case 2.0, uitgebracht.

User stories

User stories komen voort uit de agile wereld. Ze faciliteren een intensieve samenwerking tussen de business en het ontwikkelteam. Zij werken de user stories en de details samen uit. Mondelinge communicatie is daarbij het meest effectief gebleken. Specificaties zijn daarom alleen nog ondersteunend. Een user story wordt bewust vaag en onvolledig  beschreven zodat men wel met elkaar in gesprek moet gaan.

In diverse andere blogartikelen ligt ik user stories en de manier waarop je daarmee omgaat, uitgebreid toe. Begin met deze artikelen:

 Use cases vs user stories

Bij veel organisaties die overgaan op agile zie ik dat ze user stories en (traditionele) use cases naast elkaar gebruiken.

Sommige onderkennen en beschrijven eerst use cases en destilleren daaruit user stories voor op de product backlog. Meestal komt dit voort uit de (traditionele) neiging om ruim van tevoren de requirements te gaan achterhalen. Bij toepassing van Use Case 2.0 is destilleren van user stories niet nodig omdat daarvoor use case slices in het leven zijn geroepen.

Andere organisaties werken met user stories en maken tijdens de sprint use case beschrijvingen ten behoeve van het beheer en onderhoud. Doordat je de documentatie niet voor maar parallel aan het realiseren van de software maakt, is de kans op verschillen tussen de opgeleverde software en de requirements documentatie veel kleiner.

Of use case beschrijvingen daar de meest geschikte vorm voor is, hangt van de doelgroep van die documentatie af. Vraag ze gewoon eens aan welke informatie ze behoefte hebben en in welke vorm ze die informatie het liefste aangereikt krijgen.

Welke techniek of combinatie van technieken heeft jou voorkeur? Werkt dat goed in jou specifieke situatie? Laat het me weten via het reactieveld hieronder.

Nicole de Swart, requirementstechnieken expert
Nicole de Swart

Gratis e-book ‘Vliegende start als agile analist’

Met 25 do’s en don’ts voor agile requirements en eens per maand een agile requirements tip
Nicole de Swart

Nicole de Swart

Requirementstechnieken expert

Ik help je de juiste mix van agile en traditionele requirementstechnieken toepassen

Volg Nicole op:

Tips voor de moderne analist

Je ontvangt eens per maand een nieuw artikel. Net zoals meer dan 5.500 collega abonnees.

Copy link
Powered by Social Snap