Het user requirements onderzoek deel 2: 4 tips voor een succesvol onderzoek

In deel 1 hebben we je kennis laten maken met de verschillende soorten software requirements en methoden voor het onderzoek. In dit deel gaan we verder waar we gebleven zijn. We vertellen je hoe je de requirements op een effectieve manier kunt documenteren. Daarnaast delen we hoe je de requirements op basis van prioriteit kunt indelen en hoe je ze kunt valideren. Als laatste delen we een aantal uitdagingen en tips voor een effectief user requirements onderzoek.

Hoe je requirements effectief kunt documenteren

Het nauwkeurig documenteren van requirements is cruciaal voor het succes van het project. De complete documentatie vormt een blauwdruk voor alle stakeholders die precies laat zien waar de software aan moet voldoen. We zetten een aantal tips voor het effectief documenteren van requirements op een rij:

1. Gebruik duidelijke taal

De requirements moeten voor alle belanghebbenden direct duidelijk zijn. Duidelijke en beknopte taal is hierin van groot belang. Probeer vaagheid en ambiguïteit te vermijden, want deze kunnen leiden tot verwarring en misinterpretatie. Dit wil je voorkomen, want verwarring leidt vaak tot onnodige rework in een latere fase. Probeer ook technisch jargon zoveel mogelijk te vermijden, tenzij het noodzakelijk is en de betekenis voor iedere belanghebbende partij volledig duidelijk is.

2. Gebruik user stories of use cases

Een effectieve manier om requirements te documenteren is door user stories of use cases te beschrijven. Door de requirements vanuit het perspectief van de gebruiker te beschrijven, wordt het voor belanghebbenden makkelijker om de behoeften en verwachtingen te begrijpen. Over het algemeen vertellen user stories wie de gebruiker is, wat ze willen bereiken en waarom ze dat willen. Bij use cases wordt de nadruk meer gelegd op de interacties tussen de software en de gebruiker, waarbij in stappen kan worden beschreven hoe de gebruiker tot een gewenst resultaat komt.

3. Gebruik tools voor requirement beheer

Om de voortgang van het project te bewaken en tegelijkertijd alle requirements samen te bundelen in één overzicht, kan een tool enorm helpen. Tools als JIRA en Confluence bieden alle functionaliteiten die je nodig hebt om requirements te verzamelen en te wijzigen. Maar ze helpen je ook bij het beheren van het project in een later stadium.

4. Regelmatige updates en herzieningen

Hoewel we bij Four Digits het liefst zien dat alle afspraken tijdens de oriëntatiefase helder en overeengekomen zijn door alle belanghebbenden, kan het altijd zijn dat er gedurende het project requirements wijzigen. Het is belangrijk om iedere wijziging te noteren en te delen met alle belanghebbenden om latere verwarring te voorkomen. Door tijdens iedere meeting de wijzigingen samen met de klant door te nemen, ben je er zeker van dat je werk blijft voldoen aan de verwachtingen.

Het prioriteren van requirements

Uiteindelijk is het doel van maatwerk software om zo veel mogelijk waarde toe te voegen voor de klant. Maar hoe bepaal je deze waarde? Daar gebruiken we het prioriteringsproces voor. Het prioriteren van requirements heeft als doel om te bepalen welke functies de meeste waarde toevoegen voor de klant. Dit kun je doen door een van de volgende methoden te gebruiken:

De MoSCoW-methode:

MosCoW staat voor Must have, Should have, Could have, Would have. In deze methode worden requirements ingedeeld op basis van deze 4 categorieën. Hierdoor creëer je een direct overzicht van de verschillende prioriteiten per requirement.

De ICE-methode:

ICE staat voor Impact, Confidence en Ease. Het beoordeelt de prioriteit per requirement op basis van deze drie criteria. De impact bepaalt de waarde voor de gebruiker of organisatie. Confidence bepaalt hoe zeker we zijn van onze verwachtingen met betrekking tot deze requirement en Ease bepaalt hoe gemakkelijk het is om de requirements te implementeren.

Het valideren van requirements

Naast prioriteren is het valideren van de requirements van belang. Dit houdt in dat je per requirement controleert of ze realistisch zijn, haalbaar zijn, en in lijn zijn met de organisatiedoelstellingen. Je kunt requirements valideren door:

1. Feedbacksessies met stakeholders waarbij de requirements onder de loep worden genomen en kritisch bevraagd worden.
2. Prototype testing waarbij prototypes van de software kunnen worden ontwikkeld om feedback te verzamelen. Dit geeft vervolgens inzicht in of de requirements voldoen aan de verwachtingen van de gebruiker.
3. Gebruikersonderzoek waarbij de behoeften, voorkeuren en pijnpunten van de eindgebruikers onderzocht worden. Dit helpt om de relevantie en effectiviteit van de requirements te meten.

Veelvoorkomende uitdagingen tijdens het proces

Ieder onderzoek kent zijn uitdagingen. Zo ook het user requirements onderzoek. Toch kunnen deze uitdagingen grotendeels vermeden worden door onze tips op te volgen. Maar eerst gaan we kijken naar een aantal uitdagingen die we vaak terugzien in onze trajecten.

De eerste uitdaging is de continu veranderende behoeften van een organisatie. Zowel markten als organisaties veranderen continu, wat kan leiden tot onvoorziene veranderingen in het ontwikkeltraject. Daarnaast is het soms lastig om de gebruikersverwachtingen helder te krijgen door het groot aantal verschillende meningen en perspectieven van gebruikers. Een andere uitdaging die we soms tegenkomen zijn de beperkingen op technisch gebied. Sommige requirements zijn nu eenmaal niet technisch haalbaar. Door hier vroegtijdig bewust van te zijn voorkom je dat de klant verwachtingen heeft die niet waargemaakt kunnen worden.

4 tips voor een effectief user requirements onderzoek

Om de uitdagingen effectief aan te pakken en hopelijk zelfs te voorkomen, geven we je 4 concrete tips voor een succesvol onderzoek:

1. Werk de requirements regelmatig bij

Alles draait om het voldoen aan verwachtingen. Daarom is het belangrijk om regelmatig, bij voorkeur tijdens iedere meeting de wijzigingen op de requirements door te nemen en te documenteren in de bijbehorende tickets of documenten.

2. Betrek alle stakeholders

Als je in de oriëntatiefase zorgt dat alle belanghebbenden worden betrokken, voorkom je dat er later negatieve feedback komt. Daarnaast zorgt het voor een gevoel van saamhorigheid en vermindert het risico op miscommunicatie.

3. Flexibiliteit voorop

Zorg dat je bereid bent om aanpassingen door te voeren wanneer dat nodig is. Hoe vervelend het soms ook is, veranderingen horen bij een project. Het vermogen om hier adequaat en begripvol op te reageren is essentieel voor het succes van het project. Sta dan ook open voor feedback. Bij grote afwijkingen beschrijven we de nieuwe wensen en plaatsen we deze op de backlog. Zo zorgen we dat scope-creep in projecten zo veel mogelijk wordt vermeden.

4. Stimuleer een continu leer- en verbeterproces

Het user requirements onderzoek is een steeds terugkerend proces. Door te leren van je ervaringen met eerdere onderzoeken kun je het proces continu blijven verbeteren. Door juist in de oriëntatiefase van een project zoveel mogelijk requirements helder te krijgen, verminder je de kans op verwarring en negatieve feedback door het niet voldoen aan verwachtingen.

Onze eigen succesvolle strategie

We hebben binnen Four Digits onze eigen succesvolle strategie ontwikkeld voor user requirements onderzoeken. Door in de oriëntatiefase precies helder te krijgen wat we gaan ontwikkelen, zorgen we ervoor vrijwel altijd aan de verwachtingen van alle belanghebbenden te voldoen. We hebben hierbij ons eigen afsprakendocument (in-depth blog 9 – de voorbereidingen) ontwikkeld, die later gebundeld wordt met het functioneel ontwerp als blauwdruk voor de uiteindelijke software.

Ben je benieuwd hoe we jouw software traject in goede banen kunnen leiden? Vraag een gratis adviesgesprek aan.