Het uitvragen van requirements lijkt op het eerste gezicht niet zo moeilijk. Maar dat blijkt al snel behoorlijk tegen te vallen. Zeker als je de requirements van te automatiseren bedrijfs- of werkprocessen wilt uitvragen. Zodra je erin duikt blijken werkprocessen altijd ingewikkelder te zijn dan ze op voorhand lijken. Je hebt misschien ook wel ervaren dat er dan allerlei (belangrijke en onbelangrijke) subprocessen, uitzonderingen en details naar voren komen.

Meedenken

Om de requirements boven water te krijgen is alleen vragen stellen aan gebruikers­(vertegen­woor­digers) of medewerkers niet toereikend. Medewerkers zitten meestal zo diep in hun processen dat ze allerlei blinde vlekken hebben. Ze zijn zich dikwijls niet bewust van de eigenaardigheden in hun werkprocessen en onvolkomenheden in de huidige systemen.

Voor medewerkers is het erg lastig om precies aan te geven wat hun eisen en wensen zijn. Daarom biedt je als analist veel toegevoegde waarde door je in te leven en mee te denken. Zo breng je ook vaak nieuwe inzichten bij de medewerkers teweeg.

Een houding van ‘u vraagt wij draaien’ is niet meer van deze tijd. Je bent immers geen notulist. Aan de andere kant is het ook niet de bedoeling om al te veel te sturen. Pas op dat je zelf niet gaat bepalen wat goed is voor de organisatie. Een balans vinden is belangrijk.

Alleen als je de medewerkers en hun werkprocessen goed begrijpt, kun je samen met hen de juiste requirements opstellen. Je moet als het ware in de huid van de ander kruipen. Je wilt immers een systeem dat hun werkzaamheden optimaal ondersteunt. En je wilt voorkomen dat er functionaliteit ontbreekt en dat er work arounds nodig zijn.

Uitvragen requirements

Het uitvragen van requirements omvat dus veel meer dan eenvoudigweg vragen naar de eisen en wensen van de toekomstige gebruikers. Wat je onder andere moet doen is:

  • de juiste vragen stellen
  • in de huid van de medewerkers kruipen
  • nieuwe inzichten teweeg brengen
  • de juiste requirements boven water halen

Om je daarbij te helpen volgt hieronder een lijst met praktische tips. Je kunt ze meteen toepassen. Het kost je hooguit een beetje extra tijd, maar het gaat je ongetwijfeld veel opleveren. En niet in de laatste plaats betere requirements.

10 praktische tips voor het uitvragen van requirements

De onderstaande tips komen uit de Elicitation & Consolidation training van het Advanced programma van IREB (International Requirements Engineering Board). Daarin leer je hoe je juist de requirements snel op tafel krijgt mét commitment van je stakeholders.

Hier komen de tips:

  1. Probeer erachter te komen in wat voor omgeving de medewerker werkzaam is. Als het kan spreek dan op zijn werkplek af of vraag tijdens het videobellen om een indruk van de omgeving.
  2. Vraag de medewerker om bepaalde werkzaamheden voor te doen, zodat je zelf precies ziet welke acties hij achtereenvolgens doet.
  3. Stel vragen zodat je precies begrijpt wat hij doet en waarom hij op deze manier werkt.
  4. Neem geen genoegen met een proces- of procedurebeschrijving, want dat is vrijwel nooit de huidige praktijk.
  5. Onderbreek de medewerker niet meer dan nodig is terwijl hij zijn werkzaamheden demonstreert. Vragen die kunnen wachten stel je pas nadat hij iets afgerond heeft.
  6. Stel na afronding van de taak vragen over specifieke gevallen, fouten, relaties tussen taken, beweegredenen, ergernissen, problemen etc.
  7. Vraag of je de gebruikte formulieren, documenten en eventueel schermafdrukken mag meenemen.
  8. Spreek meerdere keren met dezelfde medewerker(sgroep) af, zodat je tijd hebt om de verkregen informatie te analyseren en aanvullende vragen te stellen.
  9. Hanteer een iteratief proces waarin je steeds focust op andere werkzaanheden en detailniveaus.
  10. Beperk je in eerste instantie tot de huidige werkwijze. Pas als je die inzichtelijk hebt, ga je samen met de medewerker op zoek naar verbeterpunten en naar de gewenste systeemondersteuning (dat zijn de requirements).

Er zijn uiteraard nog veel meer tips voor het uitvragen van requirements te geven. Wat is jouw ervaring met het uitvragen van requirements? Heb je aanvullende tips, wat werkt wel en wat werkt niet voor jou?

Nicole de Swart

Misschien vind je dit ook interessant

10 reacties

  • Rik Manhaeve

    Schitterende lijs, vooral de breedte die erin naar voor komt is cruciaal. Daarom zou ik er nog een tip willen aan toevoegen:
    11. Maak en onderscheid tussen management en gebruikers. Het management betaalt meestal (of krijgt het op zijn budget), de gebruikers gebruiken. Elk heeft zijn eigen verwachtingen en noden.
    Deze tip kan impliciet verwerkt zijn in de bovenstaande 10, ik zou hem wel expliciet vermelden want dat wordt dikwijls over het hoofd gezien.
    Technieken die hiervoor bruikbaar zijn:
    – stakeholder analyse omdat die alle groepen kan aangeven
    – personas die als startpunt voor een bevraging kunnen dienen en op basis van deze bevraging worden bijgestuurd.

    • Nicole de Swart

      Rik, bedankt voor de extra tip.

  • Steven

    Nicole,

    Is het niet onhandig om over gebruikers te spreken? De interpretatie die dan snel volgt is dat het om oude of nieuwe IT gaat waar je aan werkt, en dat zou een, in mijn ogen ongewenste, beperking zijn.

    Steven

    • Nicole de Swart

      Steven, je interpretatie is correct. Ik beperk me bewust tot IT-oplossingen omdat daar mijn expertise en ervaring ligt. Overigens gaat officieel het vakgebied requirementsengineering ook alleen over IT (maar dat is geen goed argument om zelf niet breder te kijken).

      • Steven

        Nicole,

        Dank voor je antwoord.

        Het gaat immers om het op de juiste manier van de juiste informatie op het juiste moment voorzien en dan zal er inderdaad vaak IT bij komen als er naar oplossingen gekeken gaat worden. Op voorhand over gebruikers van IT praten betekent een beperking in je functioneren als requirement analyst omdat je daarmee de mogelijke oplossingen, en die zijn altijd van een moment, meeweegt en dat beperkt wat je kunt doen voor een organisatie.

        Ik begrijp dat je van je achtergrond en expertise moet uitgaan. Wie doet dat niet, en daar ben je gelukkig ook echt eerlijk over. Alleen als je dan over IREB spreekt, en daar ben jij mee bezig zoals ik begrijp, en het certificeren volgens die regels, dan zou het erg ongelukkig zijn als zo’n uitgangspunt daar ook gehanteerd wordt. Is dat ook daar geval? Zou wel bij een Engelse/Amerikaanse aanpak passen. Maar zou ook heel erg jammer zijn.

        Steven

        • Nicole de Swart

          Steven,
          Ik had je verkeerd begrepen en dacht dat je op projecten volledig buiten het IT-domein doelde. Mijn expertise ligt bij IT-projecten. Natuurlijk ben ik het met je eens dat we in IT-projecten ook breder moeten kijken dan IT alleen: bij het zoeken naar mogelijke oplossingen zoals je aangeeft en ook bij het uitwerken van requirements voor een IT-systeem. Een IT-systeem staat immers niet op zichzelf en heeft invloed op allerlei andere bedrijfsaspecten.

          Dus inderdaad mogen we ons blikveld niet beperken tot alleen IT. Als het woord ‘gebruikers’ die suggestie oproept, moet ik het zorgvuldiger formuleren. Ik heb daarom mijn artikel aangepast. Dank je wel voor je (aanhoudende) reactie.

  • Frans van Koppen

    Neem er genoegen mee dat bepaalde requirements in eerste instantie nog niet SMART zijn. Gebruik de iteraties niet alleen voor vebreding maar ook voor verdieping. (zit ook een beetje in 8.)
    En inderdaad de requirement is in eerste instantie bedoeld om de medewerker het mogelijk te maken zijn proces uit te voeren. Als tijdens de analyse het duidelijk wordt dat dit niet door een geautomatiseerde oplossing (tijdig) wordt ondersteund, dan moet er ruimte zijn voor andere oplossingen. De requirement blijft dan (in een bepaalde vorm) wel bestaan.

  • Karel Auwerda

    Requirements engineering komt oorspronkelijk uit systems engineering: vliegtuigen, bruggen, tunnels, en ander complexe, system of systems bouwwerken. Telelogic, de oorspronkelijke producent van Doors (req. man. tool) geeft hier ook veel voorbeelden van.

  • Robin Doesburg

    Mijn ervaring met punt 3: Vraag altijd waarom bepaalde gegevens worden genoteerd / ingevoerd en of de invoerder weet wat het nutis van deze gegevens? Wanneer je met de ontvanger van deze gegevens praat of met management hierover kom je vaak bij de achtergrond hiervan terecht. In veel gevallen worden gegevens genoteerd uit gewoonte en worden ze door niemand meer gebruikt en zelfs alleen als lastig gevonden. Bij bestaande processen worden veel zaken gedaan die niet meer nodig zijn en soms zelfs in de weg zitten. Door het ontbreken van de redenen durft men ook niet meer te snijden. Dat kan nu dus wel. Pure winst!

    • Nicole de Swart

      Erg herkenbaar, Robin. Ik kom dat helaas ook geregeld tegen bij organisaties. Wel een mooie kans voor ons als analisten om toegevoegde waarde te leveren. Inderdaad winst voor iedereen.
      Bedankt voor je tip.

Geef een reactie