EHBO-R: Eerste hulp bij onvolledige requirements

Eerste hulp bij onvolledige requirements

Veel intermediairs tussen Business en ICT, zoals functioneel beheerders en informatieanalisten, zullen dit herkennen. Ze voeren gesprekken met belanghebbenden en schrijven al hun wensen en eisen op. Na afloop weten ze precies welke producten er nodig zijn en wat die producten moeten kunnen doen.

En toch blijkt keer op keer dat ze essentiële informatie hebben gemist, want de klant blijkt uiteindelijk niet tevreden te zijn met het geleverde product.

In de praktijk zie je dat intermediairs vaak vergeten zijn te vragen welke concrete resultaten de klant wil bereiken met de producten en met de specifieke functies ervan.

En dat is eigenlijk merkwaardig, want het zijn juist die concrete resultaten die ervoor zorgen dat klanten juist wel of juist niet tevreden zijn. Klanten willen namelijk helemaal geen producten, ze willen resultaten!

En zo kan het dus gebeuren dat er een product wordt opgeleverd dat voldoet aan alle functionele wensen en eisen, maar waar de klant toch niet tevreden mee is.

Dat kan ook anders. Hoe? Door tijdens gesprekken een requirementsmodel te gebruiken waarbij je niet alleen vraagt naar de gewenste producten en productfuncties, maar óók met welke concrete en meetbare resultaten de klant tevreden is.

Zo’n model werkt als een soort EHBO-R, Eerste Hulp bij Onvolledige Requirements, en bevat de volgende soorten wensen en eisen:

1. Behoeften
Behoeften geven antwoord op de vraag: Welk resultaat wil je uiteindelijk bereiken?

Voorbeeld: Aandeel in spaarmarkt verhogen van 25% naar 30%.

2. Benodigdheden
Benodigdheden geven antwoord op de vraag: Wat heb je nodig om dat eindresultaat te bereiken? Vaak zijn dat producten of diensten.

Voorbeeld: een nieuw spaarproduct, promotiemateriaal, helpdesk en softwaresysteem.

3. Functies
Functies geven antwoord op de vraag: Wat moet een product (vaak systeem) kunnen doen om het eindresultaat te bereiken?

Voorbeeld: registreren klant, overboeken geld, opvragen jaarrekening en bijschrijven rente.

4. Kwaliteiten
Kwaliteiten geven antwoord op de vraag: Hoe goed moet de functie worden uitgevoerd om het eindresultaat te bereiken? Hoe snel? Hoe accuraat? Hoe veilig? Et cetera…

Voorbeeld: Overboeking is na 0,2 seconde verwerkt, klant kan alleen na identificatie geld overboeken.

Er zijn ook kwaliteiten die antwoord geven op de vraag: Hoe goed moet het product als geheel zijn om het eindresultaat te bereiken? Wanneer beschikbaar? Welke uitstraling? Et cetera…

Voorbeeld: Alle functies zijn 24×7 beschikbaar voor de klant, alle schermen voldoen aan de huisstijl van de bank.

5. Randvoorwaarden
Randvoorwaarden geven antwoord op de vraag: Welke grenzen worden gesteld aan de oplossingsrichting? Aan welke regelgeving en standaarden moet worden voldaan?

Voorbeeld: voldoen aan wetgeving van De Nederlandse Bank (DNB), voldoen aan de regels van de Autoriteit Financiële Markten (AFM).

Dit model zorgt als het ware voor een piramide aan wensen en eisen, waarbij alle wensen en eisen moeten bijdragen om het gewenste eindresultaat te behalen.

Ook zorgt dit model ervoor dat je veel minder essentiële informatie gaat missen. Hou het daarom altijd in je achterhoofd tijdens het gesprek zodat je de belanghebbende met een gerichte vraag stuurt naar die onderdelen waar je (nog) meer informatie over wilt hebben.

Het toepassen van bovenstaand model is slechts één van de hulpmiddelen om onvolledige requirements te voorkomen. Welke middelen gebruik jij nog meer? En welke werkt volgens jou het beste?

Laat het ons weten en laat een reactie achter.

,

No comments yet.

Leave a Reply