Requirements zijn geen doel op zich, maar een hulpmiddel om de juiste software te realiseren. Software die aansluit op de behoeften van de business. Maar ook die software is geen doel op zich. Dat is evengoed een middel.

Maar wat wil de business dan echt? Waar het de opdrachtgever eigenlijk om gaat is bijvoorbeeld kostenverlaging, vergroten van het marktaandeel, een fikse boete of imagoschade voorkomen of de klant- of medewerkers­tevredenheid vergroten. Hij wil zijn bedrijfsdoel halen.

Toch ligt in de meeste IT projecten de focus op het implementeren van de gedefinieerde requirements. En hooguit indirect op het realiseren van het bedrijfsdoel.

Requirements gedreven ontwikkelen

Softwareontwikkeltrajecten zijn doorgaans requirements gedreven. Daar bedoel ik mee dat de requirements uitgangspunt zijn voor de andere disciplines. Bij het ontwerpen, bouwen en testen van de software bijvoorbeeld gaat men uit van de gedefinieerde requirements.

Goede requirements opstellen is daarom enorm belangrijk. Fouten in de requirements werken immers door in de rest van de keten. In traditionele omgevingen hebben analisten de cruciale taak om de requirements correct, volledig en ondubbelzinnig te definiëren. We spreken in dit kader vaak van SMART requirements.

Dit is geen eenvoudige (om niet te zeggen onmogelijke) opgave. Je moet namelijk zien te achterhalen welke requirements uiteindelijk leiden tot het behalen van het bedrijfsdoel (bijvoorbeeld marktaandeel vergroten). Daar zit nog een aantal stappen tussen.

Requirements zelf leveren geen businesswaarde (hoewel we dat vaak kortweg wel zo zeggen). Software die aan de requirements voldoet, levert ook geen businesswaarde.

De software helpt de gebruikers en andere stakeholder om hun processen beter uit te voeren. En dat levert businesswaarde. Dat leidt ertoe dat het bedrijfsdoel gehaald wordt.

Requirements definiëren

Bij requirements gedreven ontwikkelen definieer je eerst de requirements. Zodat je daarna in één keer de juiste software kunt bouwen.

Dit impliceert dat:

  • De business op strategisch, tactisch en operationeel niveau helder heeft hoe ze de klant- of werkprocessen in willen (gaan) richten
  • De gebruikers(vertegenwoordigers) tot in detail weten welke systeemondersteuning ze voor hun (nieuwe of bestaande) operationele processen nodig hebben
  • Requirements volledig en SMART te definiëren zijn

Het komt er eigenlijk op neer dat je alles vooraf probeert te voorspellen. En dat vraag je ook van de business stakeholders. Je vraagt ze nu aan welke ondersteuning ze in hun toekomstige proces behoefte hebben.

Businesswaarde gedreven ontwikkelen

In het rapport ‘The State Of Modern Product Delivery’ van Forrester kwam ik het volgende statement tegen:

“People often don’t know what they want, but they know what they (don’t) want, when they see it”

Met businesswaarde gedreven ontwikkelen speel je daarop in. Je geeft de business de gelegenheid om gaandeweg het ontwikkeltraject te ontdekken wat voor hen het beste werkt.

Daartoe realiseer je zo snel mogelijk (al na enkele sprints) een uitgekleed en basaal systeemincrement.

Deze eerste versie van het systeem bevat nog nauwelijks functionaliteit. Maar het werkt wel echt. En zou zelfs al in productie genomen kunnen worden, als de product owner (of opdrachtgever) daartoe besluit.

Het eerste systeemincrement laat je geleidelijk uitgroeien tot een volwaardig systeem. Sprint na sprint breid je het verder uit. En zorg je ervoor dat de software steeds meer businesswaarde levert.

Je gaat er bij voorbaat van uit dat het team de software die ze nu ontwikkelt, later nog moet aanpassen.

Het is dan slim om met zo weinig en zo eenvoudig mogelijke software te beginnen. Net genoeg om de business een beeld te geven en zinvolle feedback te ontvangen. Desnoods alleen feedback van een selecte groep gebruikers in een proeftuin.

Op basis van de inzichten en feedback die dat oplevert, blijf je het systeem doorontwikkelen. Net zolang totdat de business haar bedrijfsdoel ermee kan realiseren. Het is aan de product owner om dat te beoordelen.

Conclusie

Met businesswaarde gedreven ontwikkelen stuur je op businesswaarde en het halen van het bedrijfsdoel. De focus ligt op het toetsen en voortdurend uitbreiden en bijstellen van de ontwikkelde software. Agile werkt op deze manier.

Met requirements gedreven ontwikkelen stuur je op het implementeren van vooraf gedefinieerde requirements. Daarbij ga je ervan uit dat met de klant- of werkprocessen die door de nieuwe software ondersteund gaan worden, het bedrijfsdoel behaald kan worden.

Voor traditioneel opgeleide vakmensen die willen leren denken als een agile analist, heb ik het verhelderende online programma Meester in agile requirements ontwikkeld.

Nicole de Swart

Misschien vind je dit ook interessant

10 reacties

  • Michael van der Steen

    Ik ben het eens met de stelling dat projecten requirement driven zijn en dat men vaak niet kan verwoorden wat men nodig heeft of wil. Dat zou ik graag willen verfijnen naar “wat men nodig heeft of wil van software”. Mijn ervaring is dat men heel goed kan verwoorden wat men nodig heeft of wil vanuit bedrijfsperspectief. Zelfs zo goed, dat men dat ook kan doen kijkend naar de toekomst. Het zijn dan ook niet deze requirements die moeilijk te verwoorden zijn, maar meer de systeem specificaties. Een oplossingsrichting is namelijk volatiel. De behoefte die bestaat in een bedrijf is dat minder of niet. Agile is dus met name geschikt voor het leveren van software, niet persé voor het vaststellen van wat waarde heeft. Althans, dat is mijn ervaring.

  • Rudolf Jan

    Ook als je business-value gedreven werkt, heb je requirements nodig. Al is het maar om de scope van de ontwikkeling voldoende in te perken om binnen budbet te blijven en ervoort e zorgen dat je tot oplevering komt. Mijn ervaring is dat ontwikkelteams totaal verschillend met requirmeents omgaan. We hebben een facturatiesysteem waarvan de ontwikkelaars de requiremetns tot in detail uitgewerkt willen zien (op dit moment kun je voor dit systeem niet eens Agile ontwikkelen). Bij andere teams volstaat een globaal verhaal om te starten en kan de werking in het ontwerp verder worden uitgewerkt. Hoe precies dit moet, hangt ook af van de vrijheid die er is. Ik doe veel met complexe facturatie-oplossingen, waarbij het er op aan komt de businessrules heel goed te doordenken. Dat doe je niet achteraf maar vooraf en dat is gewoon vakmanschap.

    • Robin Doesburg

      Dat is ook mijn ervaring Rudolf Jan. Het blijft en vak. En business-value driven moet ook in de cultuur van de firma zelf zitten. Ik heb bij een klant (de grootste vereniging van Nederland met 4.000.000 leden) meegemaakt dat bij elke beslissing die gemaakt wordt en elke requirement die wordt vastgesteld wordt nagedacht of het in het belang is van het lid.En dat door de hele organisatie heen. Echt om je petje voor af te nemen. Maar als dat niet het geval is is het natuurlijk zaak om in het vroegste stadium van een project de business value te onderkennen. Een Goede business case moet je dus wel naleven en alle requirements moeten hieraan tegemoet komen. Maar nog steeds heb je de requirements nodig voor je systeem.

  • Hans Bezemer

    Ik zie het verschil niet tussen deze twee. Wat jij schetst is een bekend fenomeen, nl. dat klanten het moeilijk vinden om hun “echte” requirements te formuleren. Dat is echter geen verschil tussen “requirements” en “business values”, maar tussen waterval en agile – een heel bekende tegenstelling. Overigens zit ik ook op Agile 😉 laten we daar niet moeilijk over doen. Echter het nut om oude wijn in nieuwe vaten te gieten ontgaat me een beetje. BTW, een chapta met spaties tik ik ook in als spaties, maar dat terzijde.

    • Nicole de Swart

      Hans, het verschil tussen requirements-gedreven en business value-gedreven (oftewel tussen traditioneel en agile) ontwikkelen, is hoe je met dat bekende fenomeen omgaat. Probeer je om de ‘echte’ requirements op voorhand helder te krijgen (requirements-gedreven) voordat je de bijbehorende software bouwt en dat in één keer goed probeert te doen? Of ontdek je gaandeweg het project samen met de business wat het systeem moet doen door het in kleine stapjes en voortdurende inspect and adapt-loops vorm te geven.

      Eliane zegt terecht dat er wel een aantal basiskenmerken van het systeem bekend moeten zijn. Wanneer je gebruik maakt van de technische agile praktices is dat alleen veel minder dan we gewend zijn.

  • Eliane

    Ben in principe met de stelling van Nicole eens. Wat wel in de praktijk moelijk lijkt en blijft is hoe je aan het begin van een project het grotere plaatje van de oplossing maakt om vervolgens dit plaatje steeds aan te vullen of in te kleuren. Zeg maar een overal architectuur plaatje. Want dat maakt veel uit. Je kunt ook geen huis bouwen als je niet weet waar en aan welke minimale eisen het moeten voldoen.
    Mijn inziens kun je niet een basale systeem bouwen en steeds beter maken als je niet van tevoren weet een aantal basis kenmerken van het systeem. Om bij het plaatje in het artikkel van Nicole te blijven je moet wel eerste weten dat een baby twee armen, twee benen en een hoofd heeft. En dit kind kan dan groeien tot een volwassen person (ook met twee armen, twee benen en een hoofd). Maar als je de basis kenmerken niet van tevoren weet c.q. bepaalt wordt het later moelijk en duur om er een person met vier armen, geen benen en twee hoofden van te maken.

  • Wilco Charité

    Hai Nicole,
    ik had een mooie reactie geschreven maar de input is helaas gelimiteerd op 2000 tekens……..

  • André

    Ik hou wel van een business-value gedreven aanpak, of beter geformuleerd: ik hou wel van een gelaagde aanpak, beginnende bij de bedrijfsdoelstellingen en hoe een project daaraan kan bijdragen. Die project bijdrage aan de bedrijfsdoelstellingen kennen we een business value toe, en aan die business values kennen we highest level business requirements toe, die we in een laag eronder wat meer detailleren, totdat we uiteindelijk bij systeem of software requirements; Voor mij staat het los van Agile of andere varianten van software bouw methodes. Ik hou ook wel van een agile/incrementele bouw fase, maar dit gaat gewoon niet als je met externe leveranciers via (fixed-price) contracten zaken doet helaas, in een organisatie die heel erg met jaarbudgetten en projectinvesteringen werkt, maar dat zijn heel andere discussies.

    • Nicole de Swart

      Bij (traditionele) fixed-price contracten is het inderdaad moeilijk om businesswaarde gedreven te ontwikkelen. Dat komt omdat in die contracten niet alleen de prijs maar ook de doorlooptijd en de scope/requirements vastgelegd zijn. Dat die requirements van de bedrijfsdoelen afgeleid zijn, maakt de aanpak nog niet businesswaarde gedreven. Daarvoor zou je als scope niet de requirements maar het behalen van een bedrijfsdoel (bv kosten van de backoffice met x% omlaag) moeten opnemen. Je geeft dan het team + stakeholders de ruimte om proefondervindelijk te ontdekken wat er nodig is om het vastgestelde doel te behalen in plaats van VOORAF te bedenken wat ervoor nodig is en dat als requirements vast te leggen. Ik denk dat daar vooral de opdrachtgever zelf bij gebaat zou zijn. Hij wil tenslotte zijn doel halen. Hoe dat doel behaald wordt en op welke requirements je dan uitkomt, komt op de 2e plaats.

      André (en andere lezers), mocht je daar anders over denken of bezwaren zien dan hoor ik het graag. Leuk onderwerp / discussiepunt dit 🙂

      • André van den Berg

        Nicole, ik denk dat je gelijk hebt. Weliswaar beslissen we over de bedrijfswaarde van requirements tijdens (het begin van) het project, maar omdat de requirements vooraf zijn afgeleid van de bedrijfsdoelstellingen kun je daar al “de fout” in gaan als blijkt dat je daarmee je doelstellingen niet optimaal kan realiseren.

Geef een reactie