Requirements achterhalen die stakeholders je niet 1-2-3 zullen vertellen

Impliciete requirements achterhalen

Het achterhalen van alle requirements die stakeholders kunnen hebben is niet een makkelijke opgave. Sommige requirements kunnen ze direct opnoemen, maar een groot deel hebben ze niet meteen paraat.

De hele verzameling requirements die stakeholders kunnen hebben kun je dan ook goed vergelijken met een ijsberg. Boven water bevinden zich de requirements die stakeholders je meteen en expliciet melden, zoals bijvoorbeeld nieuwe functies, zaken en handigheidjes die beslist niet mogen ontbreken of problemen die ze met het huidige systeem ervaren en graag opgelost zien.

Maar onder water bevinden zich de requirements die stakeholders je niet 1-2-3 uit zichzelf zullen vertellen, bijvoorbeeld omdat ze deze te vanzelfsprekend vinden en ze daarom vergeten te melden, of omdat ze de nieuwste technologische snufjes niet kennen en er dus ook niet om kúnnen vragen.

Vooral het missen van ‘vanzelfsprekende’ of impliciete requirements leidt nogal eens tot grote teleurstelling en ontevredenheid bij de implementatie en acceptatie van een nieuw systeem. Denk maar eens aan pubers als je hen een nieuwe mobiele telefoon zou geven zonder camerafunctie. Zij weten niet beter dan dat ze met een mobiele telefoon ‘selfies’ kunnen maken.

Het is dus zaak om zoveel mogelijk van deze impliciete requirements te achterhalen. Maar hoe doe je dat? Hoe zorg je ervoor dat stakeholders zich wéér bewust worden van deze wensen en eisen? En ze je wel expliciet gaan vertellen?

Wat in ieder geval niet werkt is het stellen van een algemene vraag. Dan krijg je nl. ook een algemeen antwoord terug, zoals bijvoorbeeld: “Het moet minimaal hetzelfde kunnen als wat ik nu kan.”

Maar voordat je er zinnige en specifieke vragen over kunt stellen zul je eerst zelf dieper de materie in moeten duiken. Je moet eerst zien te achterhalen welke functionaliteit allemaal in het huidige systeem aanwezig is. Dit kun je bijvoorbeeld doen met documentatiestudie, observatie en/of systeemarcheologie.

Op een overzichtelijke lijst laat je vervolgens iedere stakeholder, per relevante functionaliteit, aangeven hoe vaak hij/zij deze gebruikt. Hiervoor kun je eventueel een meetschaal gebruiken zoals bijvoorbeeld: “Heel vaak – vaak – regelmatig – zelden – nooit” of “Iedere dag – week – maand – kwartaal – half jaar – jaar – nooit”.

Vraag daarna per functionaliteit: Hoe erg zou het zijn als deze functie niet meer beschikbaar is? Waar loop je dan tegen aan? Wat zijn voor jou dan de gevolgen?

Zo krijg je niet alleen zicht op de requirements die zich onder de waterspiegel bevinden, maar zo kom je er ook achter welke functionaliteit in het huidige systeem overbodig is, niet zal worden gemist en je dus met een gerust hart uit het nieuwe systeem kunt laten. En hier kun je enorm veel kosten mee besparen, zoals recent onderzoek maar weer eens heeft aangetoond.

Heb jij ook nog tips om de impliciete requirements van stakeholders te achterhalen? Of wil je reageren op dit artikel? Laat dan hieronder je reactie achter.

,

No comments yet.

Leave a Reply