Waarschijnlijk heb je ook ervaren dat stakeholders niet al hun requirements direct aan het begin van het project paraat hebben. Het opstellen van requirements is niet alleen voor ons requirementsanalisten, maar ook voor de gebruikers een zoektocht naar het gewenste systeemgedrag. In dit kader is het goed om onderscheid te maken tussen bewuste, onderbewuste en onbewuste requirements.
Bewuste requirements zijn de requirements die de stakeholders direct noemen. Ze zitten ‘voor in zijn hoofd’. Het zijn de dingen die ze belangrijk vinden aan het nieuwe systeem. Bijvoorbeeld nieuwe functionaliteit, betere performance of bestaande functies die absoluut moeten blijven.
Onderbewuste requirements zijn alle dingen die zo vanzelfsprekend zijn dat de stakeholder er (in eerste instantie) niet aan denkt. Denk aan routinematige acties die zo voor de hand liggend zijn dat we er niet meer bij nadenken. Het probleem hierbij is dat gebruikers die diep in de materie zitten veel dingen vanzelfsprekend vinden die voor anderen helemaal niet vanzelfsprekend of zelfs totaal onbekend zijn. Hoe minder domeinkennis de projectteamleden hebben, hoe alerter je moet zijn op de onderbewuste requirements van de stakeholders. Dit wordt extra goed zichtbaar bij het outsourcen van de softwareontwikkeling. Onderbewuste requirements kunnen dan grote problemen veroorzaken.
Onbewuste requirements zijn requirements waar de stakeholder niet aan denkt omdat hij de mogelijkheden niet kent. Een stakeholder zal niet snel vragen naar iets wat hij nog nooit heeft gezien of nooit van heeft gehoord. Onbewuste requirements komen pas boven water nadat de gebruiker zich bewust wordt van die mogelijkheid. Gebruikers vragen meestal naar een verbeterde versie van de dingen die ze al kennen.
Henry Ford zei het heel treffend: ‘If I had asked people what they wanted, they would have said faster horses.’ Vooral bij totaal nieuwe bedrijfsprocessen en innovaties spelen onbewuste requirements een grote rol. In dit soort trajecten is het lastiger om de requirements te achterhalen.
Ken jij voorbeelden van onbewuste of onderbewuste requirements? Zet ze in het reactieveld onder dit artikel zodat andere lezers daar hun voordeel mee kunnen doen.
Hoe achterhalen?
De beste manier om requirements te achterhalen bestaat niet. Je kunt beter meerdere technieken naast elkaar gebruiken. Iedere techniek heeft immers voor- en nadelen en is geschikt voor specifieke situaties. Ook voor het achterhalen van de bewuste, onderbewuste en onbewuste requirements zijn afzonderlijke technieken vereist.
De bewuste requirements kun je het beste achterhalen met bijvoorbeeld interviews, scenario’s doorspreken, prototyping, use case workshops, observeren en enquêtes. Alle technieken die stakeholders houvast geven bij het uiten van hun wensen zijn goede opties. Interviews houden met stakeholders is veruit de meest gebruikte techniek. Het is wel aan te raden om interviews te combineren met één of meer andere technieken.
De onderbewuste requirements kun je het beste achterhalen met bijvoorbeeld observeren, systeemarcheologie, simulaties, interviews, storyboards, helpdesk review en video opnemen van de huidige situatie. Om deze requirements te achterhalen wordt meer van jou als requirementsanalist gevraagd. Je moet de onderbewuste requirements min of meer zelf ontdekken en vervolgens verifiëren bij de stakeholders. Hiervoor dient je je te verdiepen in de huidige (werk)processen en systemen.
De onbewuste requirements kun je het beste achterhalen met bijvoorbeeld brainstormen, brain writing, six thinking hats, prototypen en analogieën. Deze requirements zijn het moeilijkste te vinden. Gelukkig zijn ze lang niet voor alle projecten van belang. Je hebt technieken nodig die creativiteit stimuleren om onbewuste requirements te achterhalen. Er is namelijk veel creativiteit vereist om überhaupt kandidaat requirements te vinden. Dit kun je het beste doen door mensen met verschillende achtergronden bij elkaar te brengen in een workshop.
Het achterhalen van deze requirements is denk ik bijzaak. Een end to end ontwikkelketen (van requirement engineer tot en met release manager) met domeinkennis is vele malen belangrijker.
In mijn ogen kun je alleen dan de requirements goed interpreteren en implementeren.
@Paveke: dat suggereert dat je ontwikkelketen zelf wel de requirements bepaalt? Ergens in het verhaal zal die stakeholder toch zelf ook die requirement “willen”?