‘Wat zijn agile requirements eigenlijk precies?’ Dit is een vraag die ik geregeld krijg. Dat is niet zo vreemd want het is beetje een vreemde term. We zeggen immers ook niet waterval requirements.
Agile requirements zijn gewoon requirements, maar dan toegepast in een agile omgeving
Maar laat ik beginnen met de term ‘requirements’.
Wat zijn requirements?
Het meest gegeven antwoord op deze vraag is ‘Requirements zijn eisen en wensen’. Op zich klopt dat. De letterlijke vertaling van het Engelse woord requirement is inderdaad ‘eis’ of ‘vereiste’.
Maar realiseer je dat niet alle eisen en wensen die aan een systeem worden gesteld tevens requirements zijn. Je mag eisen en wensen dus niet als synoniem voor requirements gebruiken. Om verwarring te voorkomen kun je beter de andere letterlijke vertaling van requirements nemen. Dat is ‘behoefte’.
Een requirement is een behoefte van de business aan systeemondersteuning
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 steeds verder in detail uit. Je daalt als het ware af van high level naar low level requirements.
Requirements hebben geen vaste omvang: ze kunnen high level en low level zijn en alles daar tussenin
Dit geldt overigens ook voor user stories. High level user stories hebben de naam ‘epic‘ gekregen. En low level user stories worden soms ‘sprint ready stories’ genoemd.
Wat zijn agile requirements?
Met ‘agile requirements’ duiden we op de manier waarop je in een agile omgeving met requirements omgaat. Dit in tegenstelling tot Requirements Engineering in het pre-agile tijdperk. Dat noem ik altijd ‘traditionele requirements’.
We zijn gewend om requirements voor meerdere doeleinden te gebruiken. Op het eerste gezicht lijkt dat verstandig. Maar of het ook effectief is, is de vraag.
Hoe goed kun je met één en dezelfde set aan requirementsdocumenten de volgende doelen dienen?
- Offerte aanvragen bij en contract afsluiten met de partij die de software gaat ontwikkelen
- Aan de ontwikkelaars duidelijk maken wat ze moeten bouwen
- Functioneel beheer en impactanalyses vereenvoudigen
- Requirements hergebruiken in toekomstige projecten
Agile requirements zijn alleen bedoeld voor het ontwikkelen van de juiste software. Ze spelen uitsluitend een rol in het voortbrengingsproces.
De hele aanpak en alle agile requirementstechnieken zijn hierop gericht. Waar heeft de business de meeste behoefte? Wat levert de meeste businesswaarde en heeft prioriteit? Hoe maak je op het juiste moment aan de ontwikkelars duidelijk wat er gebouwd moet worden?
Deze focus op het voortbrengingsproces biedt allerlei mogelijkheden om je werkwijze effectiever in te richten. Dit in vergelijking met het vastleggen van requirements voor gebruikers, managers, ontwikkelaars, testers, beheerders en collega-analisten.
Agile requirements niet geschikt voor …
In tegenstelling tot traditionele requirements zijn agile requirements niet bedoeld en niet geschikt als:
- Programma van eisen, offerte of contract
Dat is in een agile aanpak ook niet nodig. Je werkt namelijk businesswaarde gedreven en niet requirements gedreven. - Specificaties
Dat is in een agile aanpak ook niet nodig. Je plaatst agile requirements (meestal in de vorm van user stories) op de product backlog om overzicht te creëren en verwachtingen te managen. Vervolgens werk je de user stories samen met het agile team en just in time and just enough uit. - Systeemdocumentatie
Dit is in een agile aanpak ook niet nodig. Systeemdocumentatie maak je tijdens de sprint, parallel of direct nadat de user story gerealiseerd is. Niet ervoor. En niet per se met requirements. Het gaat namelijk niet zozeer om de behoeften van de business, maar om de (gerealiseerde) functionaliteit.
Conclusie
Agile requirements en traditionele requirements zijn in essentie gewoon de behoeften van de business. Het grote verschil zit hem in het proces en het gebruik. Meer weten? Kijk dan eens bij Meester in agile requirements. In dit online programma ontdek je waarom agile practices vaak indruisen tegen traditioneel vakmanschap.
Wat is jouw conclusie? Worden er in jouw organisatie vooral gewerkt met traditionele of agile requirements? Of is het een mix geworden? Dat zie je namelijk vaak bij organisaties in transitie naar agile.
Nicole de Swart
Nicole, wat is jouw visie op hoe je dan wel de volgende doelen moet behalen:
•Functioneel beheer en impactanalyses vereenvoudigen
•Requirements hergebruiken in toekomstige projecten
En hoe breng je daarin structuur en overzicht aan?
Requirements management wordt nu heel makkelijk overboord gegooid, maar het heeft veel voordelen. Naast het dienen van de bovengenoemde doelen ondersteunt het ook nog
1. een complete en goede analyse (inclusief voorkomen van dubbelingen en conflicten, daar kun je m.i. niet vroeg genoeg bij zijn).
2. en kun je de impact van wijzigende/nieuwe requirements tijdens het ontwikkelproces makkelijker bepalen.
3. en wat ik in de (agile) praktijk toch ook vaak zie is dat men achteraf niet meer weet waarom iets nu zo was gebouwd. Ook daar kan requirements management helpen. Op het gebied van kennismanagement.
4. en ook bij regressietesten; je wilt dan tenslotte testen of nog aan de originele requirements wordt voldaan en niet of er is gebouwd wat in de functionele documentatie staat beschreven (want dat wordt in agile omgevingen vaak door eenzelfde persoon opgezet dus dan mis je een controleslag, en het is soms ook te summier of onvolledig om als goede testbasis te dienen).
Ik zie niet zo snel hoe je het gemis daarvan in een dergelijke agile omgeving compenseert?
Zelf heb ik sterk het gevoel dat een gestructureerde high-level requirements analyse als onderdeel van je ‘sprint 0’ / productvisie een heel goed idee is. Je moet dat dan natuurlijk wel agile / pragmatisch aanpakken en niet allerlei templates gaan vullen. Als de high-level structuur er is, kunnen daar vervolgens epics en user stories ‘onder gehangen’ worden. Dan heb je je kaders en scope enigszins duidelijk, en kun je je high-level requirements ook managen met alle voordelen van dien.
Wat is jouw visie op requirements management in Agile omgevingen?
In agile begin je inderdaad met high level requirements (productvisie in Scrum), de stip op de horizon waar je naar toe werkt dus. Bij een agile en dus een waarden gedreven aanpak bouw je eerst een primitieve versie van het systeem. Die breidt je dan geleidelijk uit tot een volwaardig systeem. Iedere sprint verbeter/wijzig/breid je de software verder uit. Eén van de eerste dingen waarvoor een agile team moet zorgen zijn geautomatiseerde (regressie)testen.
Ook voor requirements geldt dat je ze steeds verder uitbreidt, eerste de requirements voor een basaal en primitief systeem en dan op basis van feedback gaandeweg steeds meer requirements toevoegen. Een complete analyse is dan niet nodig. Van iedere toevoeging/wijziging schat het agile team de impact (beter: ontwikkelinspanning) in. Als het goed is, is iedereen (agile team en business) actief betrokken bij het opstellen van de user stories. Daarvoor worden minimaal 1 x per week Backlog Refinement sessies houden.
Tijdens de sprint leg je de benodigde informatie voor functioneel beheer en hergebruik vast. Dat wordt in de praktijk vaak gedaan in use cases, maar een hele andere (specifiek toegespitst op het beheer) documentatievorm is ook mogelijk.