Analisten stellen mijn geregeld de vraag: ‘Welke techniek kan ik het beste gebruiken om requirements te definiëren: user stories, use cases, SMART requirements 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 agile team. 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

Misschien vind je dit ook interessant

5 reacties

  • pauldm

    Ik merk dat in de discussie use case versus user stories, dikwijls het verschil niet wordt gemaakt tussen use cases en use case descriptions. De eerste zijn grafische voorstellingen van functionele vereisten (de lucifermannetjes en de ballonnetjes), de laatste tekstuele uitwerkingen van de gebruikersinteracties met de toepassing volgens verschillende scenario’s (happy flows en alternate flows). Indien men bovenstaand verschil maakt, dan lijken mij use cases en user stories wel degelijk samen te gaan. User stories zijn dan veel sneller op te stellen dan de meer gedetailleerdere use case descriptions.

    • Nicole de Swart

      Bedankt voor je aanvulling. Use case diagrammen en user stories kunnen inderdaad prima samengaan. Dat lijkt dan erg op Use Case 2.0 overigens.

  • Bert Stevens

    “Een user story wordt bewust vaag en onvolledig beschreven zodat men wel met elkaar in gesprek moet gaan”

    Teveel detail in user stories kan het gesprek inderdaad in de weg staan, en developers lezen lange teksten sowieso amper. Een aanpak die ik en vele guru’s meer voorstaan is alles in prototypes gieten wat visueel te maken is, en dan heeft een interactie ontwerper genoeg aan een korte user story. Echter de analist heeft nogsteeds veel te onderzoeken en schrijven, de business case, waarom een gebruiker/klant iets nodig heeft (de WHY), business rules, acceptatie criteria, maar dat staat niet in user stories, etc.

  • Bob

    Hoe ver moet je gaan met SMART specificeren bij selectie van standaard verkrijgbare software (pakketten). Al dan niet SaaS.

    • Nicole de Swart

      Dat is een lastige vraag Bob, want het hangt van de specifieke situatie af. Essentieel is in elk geval om je te realiseren dat 100% SMART niet mogelijk is. Daarom is de flexibiliteit van het pakket, de leverancier en het contract ook een belangrijke factor. Is de leverancier bereidt om mee te denken, snappen ze jullie business, hoe goed is de software instelbaar/aanpasbaar?
      Zoek een leverancier waarmee je goed kunt samenwerken in plaats van een traditionele opdrachtgever-opdrachtnemers verhouding.

Geef een reactie