Minister Kamp, economische zaken, houdt voet bij stuk. Hij blijft zijn privémail zakelijk gebruiken. Ondanks een phishingaanval én waarschuwingen van het openbaar ministerie. Het is de mens eigen, het zelf bedenken van oplossingen. Een goede eigenschap. Meestal. In geval van specialismen, zoals bij ICT, kan dit beter samen met professionals worden opgepakt, omdat er niet zelden een verkeerde oplossing aan een relevant probleem binnen de organisatie wordt gekoppeld. En dáár ligt een belangrijke rol voor de professional die de oplossing bedenkt. Als deze goed werk levert, dan wordt er doorgevraagd tot de kern. Meegaan in de eerste oplossing die de opdrachtgever voor ogen heeft, resulteert vaak in een gedeeltelijke antwoord op de vraag.

Welk bedrijfsprobleem speelt er?

Wil een organisatie minder tijd kwijt zijn? Betere kwaliteit leveren? Of de samenwerking met een andere partij verbeteren? Of missen de medewerkers wellicht overzicht? Business requirements tonen aan welke toegevoegde waarden een systeem moet leveren aan diezelfde business. ICT-systemen ontlenen een belangrijk deel van hun bestaansrecht aan die toegevoegde waarden. Het is essentieel dat voor aanvang van een software-ontwikkeltraject de business requirements helemaal duidelijk zijn, bij beide partijen. In praktijk worden er nogal eens opdrachten gegeven om een systeem met bepaalde eigenschappen te ontwikkelen. Wanneer de requirements onduidelijk blijven, biedt dit nieuwe systeem zelden de juiste oplossing. En dat is wel wat de opdrachtgever verwacht.

De requirements

Hoe dit werkt? Eerst starten we met het formuleren van de business requirements, zoals bovengenoemd, dus globaal op bedrijfsniveau. Dan volgt de operationele kant: de user requirements. Zij beschrijven welke taken de medewerkers moeten verrichten om de geformuleerde doelen binnen de organisatie te bereiken. In de functional requirements komen we op het niveau van de programmeur, waarbij de eisen van de gebruiker worden omgezet in computertaal. Zie het als een auto, als er gas wordt gegeven gaat deze vooruit. Zelf vind ik dat voldoende, hoe die motor onder de kap precies in elkaar zit, maakt mij niet uit. Zo is het ook niet nodig dat de gebruiker weet wat er allemaal onder de ‘motorkap’ van het ICT-systeem gebeurt. Dan volgen de kwalitatieve requirements, die antwoord geven op bijvoorbeeld deze eis: als ik een melding maak in de Verwijsindex Risicojongeren (VIR) dan wil ik binnen 10 seconden een bevestiging van succesvol registreren. Tot slot komt nog de transitie requirement, deze beschrijft de kern van de vraag: je wilt van A naar B en aan welke eisen moet het systeem nu exact voldoen om je daar te krijgen?

De kern

Kortom, als klanten hun probleem helder in beeld hebben, dan zijn ze al goed op weg. Het is niet altijd nodig om zelf de oplossing te bedenken. Want dat is nu juist waar kwalitatief hoogwaardige ICT-professionals belangrijke toegevoegde waarde willen én kunnen leveren.