Best practises voor requirementsanalyse

Zorg voor betrokkenheid

Mijn naam is Bram Nederlof, adviseur bij Vellekoop en Meesters. In mijn opdrachten wordt mij regelmatig gevraagd om een requirementsanalyse uit te voeren. Requirementsanalyse is een belangrijke stap in projecten, met name bij softwareontwikkeling, productontwikkeling en procesverbetering. In deze blog neem ik je mee in de wereld van requirementsanalyse: wat het belang is, hoe het werkt en wat je nodig hebt om het  succesvol uit te voeren.

Wat is requirementsanalyse?

Rondom een project zijn er vaak allerlei belanghebbenden (ook wel: stakeholders). Doel van een requirementsanalyse is om de behoeften en verwachtingen van stakeholders te verzamelen, analyseren en documenteren. Deze behoeften worden vertaald naar concrete en haalbare vereisten (requirements) die richting geven aan de ontwikkeling van een product, dienst of systeem. Je hebt verschillende soorten requirements, volgens IREB (een veelgebruikte standaard voor requirementsanalyse) zijn er twee verschillende soorten: functionele requirements en non-functionele requirements. Dit zal ik hierna verder toelichten.

Je gebruikt de verschillende soorten requirements om structuur aan te brengen in de analyse en je zeker weet dat het eindresultaat aansluit bij de verwachtingen van de gebruiker.

Waarom is requirementsanalyse belangrijk?

Requirementsanalyse vormt de basis voor succesvolle projecten. Als de requirements niet duidelijk zijn, dan lopen projecten het risico om:

• Foutief opgeleverd te worden: als de wensen van stakeholders niet goed begrepen worden, voldoet het eindresultaat vaak niet aan hun behoeften. Zij krijgen een resultaat dat ze niet willen en (delen van) het resultaat moeten opnieuw gerealiseerd worden. De requirementsanalyse helpt je om continu zicht te houden op de wensen van de stakeholders en om te zien wat de impact is als een gebruikerswens wijzigt. Zo vormt de analyse een stuurmiddel om continu in de gewenste richting te blijven werken.
• Tijd en budget te overschrijden: onduidelijke of veranderende eisen leiden vaak tot extra werk, vertragingen en hogere kosten. Als een requirement pas in de ontwikkelfase van een project wordt onderkend, kan realisatie ervan tot wel 100x zo duur zijn als wanneer deze vanaf het begin van het project is meegenomen. Door met het vastleggen en bijhouden van requirements goed zicht te houden op de wensen van de stakeholders kun je deze risico’s minimaliseren, verwachtingen bijstellen en de kans op een succesvol project vergroten.

De belangrijkste stappen van requirementsanalyse

Het proces van requirementsanalyse bestaat uit meerdere fasen, die in praktijk vaak overlappen of iteratief plaatsvinden:

1. Stakeholders identificeren: Bepaal wie (direct of indirect) betrokken zijn bij het project en welke rol zij spelen. Denk hierbij aan klanten, bestuurders, eindgebruikers, projectmanagers en technische teams.
2. Vastleggen van behoeften (eliciteren & documenteren): inventariseer behoeften en leg ze vast. Dit kun je op verschillende manieren doen. Welke methode je kiest hangt af van de situatie en van de stakeholders. Voorbeelden van methodes zijn; interviews, workshops, enquêtes, observaties of brainstormsessies. Zelf vind ik interviews en workshops het fijnste: deze manieren zijn persoonlijker en hiermee kun je beter doorvragen om erachter te komen wat de stakeholder nu echt wil (de ‘vraag achter de vraag’). Het doel van requirementsanalyse is immers om requirements op te stellen samen met de stakeholders, zodat ze een product krijgen waar ze echt enthousiast over zijn. Soms dwingt tijd of omvang van de stakeholdersgroep om voor andere methoden te kiezen, zoals vragenlijsten. Het is belangrijk om een methode te kiezen die past bij de context/situatie. In het documenteren van de behoeftes is er een belangrijke regel, en dat is om deze zo veel mogelijk SMART op te schrijven. Dit betekent dat ze: Specifiek, Meetbaar, Acceptabel, Realistisch en Tijdgebonden zijn. Dit help om te voorkomen dat vereisten voor meerdere uitleg vatbaar zijn.
3. Analyseren en prioriteren: niet alle wensen zijn even belangrijk. Categoriseer en prioriteer de vereisten op basis van hun impact, haalbaarheid en toegevoegde waarde. Het is wel belangrijk om al deze aspecten tijdens de analyse in je achterhoofd te houden. Iets wat voor een stakeholder belangrijk is, kan namelijk voor de andere stakeholder geen enkele prioriteit hebben of onbetaalbaar zijn voor de organisatie.
4. Valideren en communiceren: toets de requirements met stakeholders om te controleren of ze volledig en correct zijn. Daarnaast is het belangrijk dat je in contact blijft met de stakeholders zodat er geen misverstanden kunnen ontstaan.
5. Beheren van wijzigingen: Requirements veranderen vaak tijdens een project. Daarom is het belangrijk om vast te leggen wat de bron van een requirement is. Op die manier kun je zien wat de impact is als een requirement verandert. En andersom: als een bepaalde requirement niet gerealiseerd kan worden, dan kun je terug naar de bron om alternatieven te bespreken.

Soorten requirements

Requirements worden vaak onderverdeeld in twee soorten:

• Functionele requirements: deze beschrijven wat een product of systeem moet doen. Het zijn de specificaties van de gewenste functies en gedrag. Bijvoorbeeld: “Het systeem moet gebruikers toestaan om een bestelling te plaatsen via een mobiele app.”
• Niet-functionele requirements: dit zijn de kwaliteitseisen waaraan het systeem moet voldoen, zoals op het gebied van performance, veiligheid of schaalbaarheid. Bijvoorbeeld: “De app moet binnen 0,2 seconden reageren op een gebruikersinvoer.”

Best practices voor een succesvolle requirementsanalyse

• Betrek stakeholders vroeg, regelmatig en behoud het contact: Voorkom verrassingen door iedereen vanaf het begin te betrekken en betrokken te houden.
• Wees duidelijk en concreet: Vermijd vage termen en zorg dat iedereen dezelfde taal spreekt. Het kiezen van een passende methode voor het uitvragen van requirements en het SMART specificeren van requirements helpen daarbij.
• Documenteer zoveel mogelijk: In requirementsanalyse is de gedachtegang, de bron waarvan je de requirements vandaan hebt, de afwegingen die tijdens de analyses gemaakt zijn, erg belangrijk om ook mee te nemen in de analyse. Hierdoor begrijpen de stakeholders beter waarom er voor een bepaalde gedachtegang gekozen is.
• Wees flexibel: Bereid je erop dat requirements tijdens het project kunnen wijzigen en dat je daarvoor terug moet naar gebruikers. Wees daarop voorbereid en denk mee over alternatieven. Dat komt het eindresultaat alleen maar ten goede.