FietserEen paar weken geleden stelde Jeroen deze vraag aan me: Wat zijn agile requirements precies? Zijn vraag leidde tot een interessant gesprek over requirements in een agile omgeving. En bovenal wat daar anders aan is. Ik deel het graag met je.

Agile requirements is eigenlijk een vreemde term. We zeggen bijvoorbeeld ook niet waterval-requirements. Toch raakt de term agile requirements steeds meer ingeburgerd. Agile requirements zijn gewoon requirements, maar dan toegepast in een agile omgeving.

Wat zijn requirements?

Als ik deze vraag stel, krijg ik steevast het antwoord: ‘Requirements zijn eisen en wensen’. Op zich klopt dat, maar niet alle eisen en wensen zijn tevens requirements. Je mag eisen en wensen niet als synoniem voor requirements gebruiken. Om deze verwarring te voorkomen kun je uitgaan van de andere letterlijke vertaling van het Engelse woord requirement, namelijk behoefte. Een requirement is dan een behoefte van de business aan systeemondersteuning.

Wat is de omvang van een requirement?

Denk jij bij requirements ook direct aan een opsomming van gedetailleerde eisen? Dat komt waarschijnlijk omdat we veruit de meeste tijd besteden aan het helder krijgen van gedetailleerde requirements. Daar zit de bulk van ons werk in. Toch mogen we ook de high level requirements niet vergeten. Als het goed is begin je met requirements op hoofdlijnen en werk je die verder in detail uit.

Een (agile) requirement heeft geen vaste omvang. Requirements stel je op verschillende niveaus op, waarbij je afdaalt van high level naar low level requirements.

Wat is het doel van agile requirements?

Doel

De requirements, ofwel de behoeften van de business, waarop je je in een agile project richt, noemen we dus agile requirements. Requirements dienen bij agile slechts 1 doel, namelijk het aan het ontwikkelteam duidelijk maken wat de behoeften zijn. Daardoor kunnen ze de juiste software bouwen en de business value maximaliseren.

Niet geschikt voor andere doeleinden

In tegenstelling tot traditionele requirements zijn agile requirements niet bedoeld en niet geschikt voor meerdere doeleinden:

  • Agile requirements zijn geen onderdeel van een contract
    Je hanteert een waardegedreven in plaats van een plangedreven aanpak.
  • Agile requirements zijn geen specificaties
    Je plaatst ze op de product backlog en stemt ze just in time and just enough af met het ontwikkelteam.
  • Agile requirements zijn geen requirementsdocumentatie
    Na implementatie gooi je het product backlog-item (meestal user story) weg. Inzicht geven in de (daadwerkelijk gerealiseerde) functionaliteit van het systeem doe je niet met requirements (behoeften). Voor zover het niet toereikend is om het bestaande systeem te raadplegen (in de productie- of testomgeving), leg je daarvoor op andere plekken specifieke informatie vast.

We zijn gewend om requirements voor meerdere doeleinden te gebruiken. Op het eerste gezicht lijkt dat verstandig omdat het efficiënt is. Of het ook effectief is, is de vraag. Hoe goed kun je met 1 en dezelfde set aan requirementsdocumenten de volgende doelen dienen?

Meerdere doeleinden
  • Offerte aanvragen bij en contract afsluiten met de partij die het systeem gaat realiseren
  • Aan ontwikkelteam duidelijk maken wat voor systeem gewenst is
  • Functioneel beheer en impactanalyses vereenvoudigen
  • Requirements hergebruiken in toekomstige projecten

Met agile requirements zorg je ervoor dat het ontwikkelteam het juiste systeem bouwt. Niets meer en niets minder. De hele aanpak en alle agile requirements­technieken zijn daar op gericht. Waaraan heeft de business de meeste behoefte? Hoe maak je op het juiste moment aan het ontwikkelteam duidelijk wat ze moeten bouwen? Wanneer je je uitsluitend focust op deze 2 vragen, ziet je werkwijze er opeens heel anders uit dan wanneer je requirementsdocumenten opstelt voor gebruikers, managers, ontwikkelaars, testers, beheerders en collega-analisten.

Toen Jeroen zich dit realiseerde, ging hij anders tegen zijn werk als agile analist aankijken. Afstemmen en samenwerken met het ontwikkelteam en de business werd toen belangrijker en alles goed documenteren werd minder belangrijk.

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 dont's 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:

Share This