"Dat bedoelden we niet." Vier woorden die aan het eind van menig IT-project vallen, en die vrijwel altijd terug te voeren zijn op het begin. De business vroeg om een oplossing, IT bouwde wat er gevraagd werd, en pas bij oplevering bleek dat de vraag en de behoefte twee verschillende dingen waren. De kosten van zo'n misverstand zijn hoog: herbouw, vertraging en, misschien wel het duurst, verlies aan vertrouwen tussen afdelingen.
Goede requirements zijn de verzekering tegen dat scenario. Maar wat maakt requirements goed? Na jaren werken op het snijvlak van business en IT zien wij een aantal principes telkens terugkomen.
Begin bij het probleem, niet bij de oplossing
De meeste requirements-trajecten beginnen verkeerd om: met een gewenste oplossing. "We willen een app." "We hebben een dashboard nodig." Wie doorvraagt, ontdekt vaak dat achter die wens een heel ander probleem schuilgaat, dat soms met een veel eenvoudiger ingreep op te lossen is.
Een goede business analyst vraagt daarom eerst: welk probleem lossen we op, voor wie, en hoe weten we dat het opgelost is? Pas als daar een scherp antwoord op ligt, komt de oplossingsrichting in beeld. Dit voelt voor stakeholders soms als vertraging. In werkelijkheid is het de snelste route, omdat elke week aan de voorkant maanden herstelwerk aan de achterkant voorkomt.
Schrijf toetsbaar, niet volledig
Een klassieke valkuil is het requirements-document van tachtig pagina's dat niemand leest en dat bij de eerste sprintwijziging veroudert. Volledigheid is niet het doel. Toetsbaarheid wel. Een requirement is pas bruikbaar als objectief vast te stellen is óf eraan voldaan is.
Vergelijk "het systeem moet gebruiksvriendelijk zijn" met "een medewerker kan zonder training binnen twee minuten een nieuwe aanvraag registreren". De eerste formulering leidt tot discussie bij oplevering, de tweede tot een simpele test. Werken met concrete scenario's en voorbeelden helpt daarbij enorm: één goed uitgewerkt praktijkvoorbeeld voorkomt meer misverstanden dan tien abstracte regels.
Spreek beide talen
Requirements zijn een vertaling tussen twee werelden die elk hun eigen taal spreken. De business denkt in processen, klanten en uitzonderingen. Ontwikkelaars denken in datamodellen, schermen en logica. Een requirement dat alleen in één van beide talen geschreven is, laat de ander gissen.
In de praktijk betekent dit: beschrijf de bedoeling in gewone taal die de business herkent, en voeg daar de precisie aan toe die IT nodig heeft. Welke gegevens, welke regels, welke uitzonderingen. Laat beide groepen het resultaat lezen en vraag ze het in eigen woorden na te vertellen. Waar de navertellingen verschillen, zit het volgende misverstand al klaar.
Prioriteer expliciet en hardop
Niet alles kan, en zeker niet tegelijk. Toch bevatten veel requirements-lijsten tientallen wensen zonder rangorde, waarna de volgorde impliciet bepaald wordt door wie het hardst roept. Expliciet prioriteren, bijvoorbeeld met de bekende MoSCoW-indeling, dwingt het gesprek af dat anders pas bij tijdnood gevoerd wordt: wat is echt onmisbaar en wat is mooi meegenomen?
Even belangrijk is benoemen wat er níet komt. Een korte lijst met "buiten scope" voorkomt dat verwachtingen stilletjes meegroeien met het project.
Houd requirements levend
Requirements zijn geen contract dat je aan het begin tekent en in een la legt. Inzichten veranderen, zeker in agile trajecten. Behandel de requirements daarom als levend werkdocument: kort genoeg om bij te houden, belangrijk genoeg om bij elke sprintwissel even tegen het licht te houden. De vraag is niet of requirements wijzigen, maar of de wijzigingen bewust gebeuren.
Hoe wij hierbij helpen
De business analysts van Ben Data Consultancy begeleiden organisaties bij precies dit proces: van probleemverkenning en stakeholdersessies tot toetsbare requirements en begeleiding tijdens de realisatie. Zodat business en IT niet naast elkaar, maar met elkaar bouwen.