Hoe weet je dat je ALLE requirements hebt?

Hoe voorkom je dat de requirements onvolledig zijn?
In traditionele ontwikkeltrajecten verzamelt men, in theorie, eerst alle requirements om vervolgens te starten met het ontwerp en de bouw. Een vraag die ik vaak krijg is:

“Maar wanneer heb ik dan alle requirements?”
“Hoe weet ik dat mijn set volledig is?”

Helaas heb ik dan altijd slecht nieuws te melden. Je kunt namelijk vooraf NOOIT met zekerheid stellen dat er requirements ontbreken. Gedurende het vervolgtraject kan bijvoorbeeld blijken dat er belangrijke belanghebbenden zijn vergeten. En dus ook hun requirements. Of er is bij hen sprake van ‘voortschrijdend inzicht’. Of er blijkt ineens een nieuw technologisch snufje op de markt te zijn gekomen.

Het enige wat je dus kunt doen is zoveel mogelijk requirements zien te achterhalen. Om de wijzigingen, die zeker komen gaan, en hun consequenties zoveel mogelijk te beperken.

Begin daarom altijd eerst met een goede inventarisatie van alle belanghebbenden bij het (nieuwe) systeem. Vergeet je belangrijke belanghebbenden bij het traject te betrekken dan ga je zeker ook belangrijke requirements missen.

Ga vervolgens bij alle belanghebbenden op zoek naar de 3 soorten requirements die van invloed zijn op hun tevredenheid met het nieuwe systeem. Volgens het KANO-model zijn dit:

1. Bewuste requirements  (‘satisfiers’) 

Dit zijn de requirements die belanghebbenden direct en expliciet noemen. Vaak zijn dit problemen die ze in de toekomst willen vermijden. Ontbreken één of meer van deze requirements, dan zal de tevredenheid van de belanghebbenden met het systeem afnemen. Kortom, hoe meer een nieuw systeem dit soort requirements bevat hoe beter.

2. Onderbewuste requirements (‘dissatisfiers’)

Dit zijn de impliciete requirements die belanghebbenden ‘vergeten’ te melden, omdat men ze (te) vanzelfsprekend vindt. Deze requirements worden vaak bepaald door bestaande systemen en belanghebbenden willen deze dan ook minimaal in het (nieuwe) systeem terug zien. Zo niet, dan zullen ze erg teleurgesteld en ontevreden zijn.

3. Onbewuste requirements (‘delighters’)

Dit zijn de requirements waarvan de belanghebbenden zich niet bewust zijn dat ze die hebben. Vaak omdat men zich niet bewust is van de nieuwe technologische mogelijkheden. Deze requirements zorgen voor de ‘wauw!’-ervaring bij de implementatie van het nieuwe systeem.

Realiseer je echter wel dat belanghebbenden na verloop van tijd deze ‘wauw’-requirements ook weer als vanzelfsprekend zullen ervaren. Denk bijvoorbeeld maar eens aan de mobiele telefoon die je nu hebt en het mobieltje dat je 5 of 10 jaar geleden had.

Tot slot, kies voor elke soort requirement de juiste techniek om ze te achterhalen. Wat werkt om bewuste requirements boven water te krijgen, zoals bijvoorbeeld het interviewen van belanghebbenden, werkt niet per se ook goed voor de andere soorten requirements.

Gebruik dus naast het interview ook andere communicatietechnieken. Zo zijn prototyping, creatieve workshops en brainstorming heel geschikt voor het ontdekken van onbewuste requirements. Terwijl studie van bestaande systemen, documenten en requirements en observatie van gebruikers tijdens de uitvoering van hun werk juist weer inzicht geven in onderbewuste requirements.

Samenvattend, je zult vooraf nooit 100% zekerheid krijgen dat je alle requirements hebt verzameld. Het enige wat je kunt doen is zoveel mogelijk requirements zien te achterhalen door verschillende communicatietechnieken toe te passen.

Er zijn vast nog meer tips.
Wat doe jij om zoveel mogelijk requirements te achterhalen?

,

No comments yet.

Leave a Reply