Goed of foutIk krijg regelmatig de vraag ‘Welke techniek kan ik het beste toepassen: SMART requirementszinnen, use cases, user stories of een combinatie daarvan?’ Mijn antwoord is dan meestal: ‘dat hangt ervan af.’

Een opsomming van SMART requirementszinnen zou ik alleen gebruiken voor niet-functionele requirements. Use cases en user stories combineren raad ik af. In een traditionele omgeving zijn use cases zeer geschikt en in een agile omgeving liggen user stories meer voor de hand.

Hier volgt een nadere toelichting en nuancering.

SMART zinnen

Nieuw

Dit zijn de bekende zinnen die meestal beginnen met ‘Het systeem moet’. Sinds het ontstaan van ons vakgebied verwoorden we met deze zinnen aan welke functionele en niet-functionele eisen het systeem moet voldoen. Het is verstandig om deze requirementszinnen atomair en SMART te formuleren.

De focus verschoof aan het begin van deze eeuw van systeemeisen naar de gebruikersbehoeften. We ontwikkelen immers software voor de gebruikers, het systeem moet toegevoegde waarde leveren. Aan de tot dan toe bekende software requirements werden business en user requirements toegevoegd.

Het is mogelijk om de SMART requirementszinnen ook voor business en user requirements te gebruiken. Use cases zijn echter uitgevonden om de requirements goed vanuit het oogpunt van de gebruikers weer te geven. Ze genieten wat mij betreft de voorkeur boven (lange) opsommingen van SMART zinnen.

Use cases

Bril

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 functionele user en software requirements. Het zou dus dubbelop zijn om die requirements ook nog in SMART 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 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

Gesprek

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

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 zijn toegevoegd.

Andere organisaties werken met user stories en maken tijdens de sprint use case beschrijvingen ten behoeve van het beheer en onderhoud. De kans op verschillen tussen de opgeleverde software en de requirementsdocumentatie is dan kleiner. Toch adviseer ik analisten in deze organisaties altijd om met de beheerders te gaan praten. Vraag ze aan welke informatie ze het meeste behoefte hebben en in welke vorm ze die informatie het liefste aangereikt krijgen. Ga er dus niet bij voorbaat van uit dat use cases de goede documentatievorm is.

Welke techniek of combinatie van technieken heeft je voorkeur? Werkt dat goed in jullie specifieke situatie? Ik hoor graag van je via het reactieveld hieronder.

Succes met de requirements,

Nicole de Swart

Vond je dit artikel interessant? Deel het dan met je vakgenoten via de share knoppen aan de zijkant.

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.

Share This