Het verschil tussen requirements gedreven en businesswaarde gedreven ontwikkelen

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 zitten 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, requirementstechnieken expert
Nicole de Swart

Nicole de Swart

Nicole de Swart

Auteur Handboek Requirements

Volg Nicole op:

Priya Soekhai

Priya Soekhai

Expert agile samenwerken

Volg Priya op:

Tips over agile requirements

Je ontvangt eens per maand een nieuw artikel. Net zoals meer dan 5.000 collega abonnees.

Abonneren op de tips

Je kunt je op elk moment weer uitschrijven

Copy link