Niet schuiven!

In tegenstelling tot voorgaande artikelen, waar de inhoud van de requirements centraal stond, wordt nu ingegegaan op de wijze waarop die requirements worden opsteld. Daarbij wordt gesuggereerd dat er twee aparte werelden bestaan: de wereld van de business-professional en de wereld van de ict-mens. Tevens wordt de veronderstelling gemaakt dat systemen door ict-mensen worden gedefinieerd en gebouwd. Ik kan mij levendig voorstellen dat het voor een business professional zeer onplezierig is dat hij te pas en te onpas met systemen wordt geconfronteerd waar hij niet om heeft gevraagd, waar hij niet bij is betrokken en waar hij ook niet goed mee om kan gaan. Vanuit die optiek kan ik de reactie van Abraham de Kruijf wel begrijpen.
Voordat ik op de inhoud in ga, is er echter nog een andere wereld die ik graag zou willen introduceren: de wereld van de ict-professional. Als ict-professional wordt je geconfronteerd met de systeem-behoefte van de klant (ik zou hier prikkelend business-mens kunnen gebruiken, maar dat zou flauw zijn). Een groot probleem voor de ict-professional is dat deze behoefte zelden goed is geformuleerd. Het gebeurt zelfs dat het feitelijk totaal onduidelijk is wat een klant wil. Helaas wordt de ict-professional wel gevraagd een oplossing te bieden en daar ook nog een fixed-price en dito date voor af te geven. Zeker bij Europese trajecten is communicatie met de klant tot aan de contractfase niet of moeizaam mogelijk, met als gevolg dat een deel van de aanbiedingen noodzakelijkerwijs een gok is. Ook voor de ict-professional blijken requirements een hoop kopzorgen te geven.
 
In zijn artikel maakt De Kruijf onderscheid tussen 'systeemeisen' en 'requirements'. Ten eerste krijg ik de indruk dat 'requirements' voor business-professionals zijn en 'systeemeisen' voor ict-professionals. Ten tweede krijg ik de indruk dat 'requirements' zich op een hoger abstractie niveau bevinden dan 'systeemeisen'. Mijn ervaring is dat deze 'requirements' relatief tamelijk globaal zijn. Dit is wellicht voldoende om op business-niveau van gedachten te kunnen wisselen, maar voor het binnen het kostenplaatje blijven, op tijd ontwikkelen en implementeren van een systeem levert het gebruik daarvan op zijn minst de nodige risico's op. 'Systeemeisen' daarentegen beschrijven in principe goed wat een systeem moet kunnen doen. De vraag is natuurlijk of dat als het systeem doet wat in de 'systeemeisen' staat, het ook doet wat in de 'businessrequirements' staat. Met andere woorden: kloppen de 'requirements' met de 'systeemeisen' De cruciale vraag is dan ook: hoe kom je van 'requirements' naar 'systeemeisen' op een dusdanige wijze dat je uiteindelijk 'krijgt wat je wilt'? Mijn ervaring is dat dit scheidsvlak de hoofdoorzaak is van veel dan de hiervoor aangegeven problemen.
De Kruijf geeft in zijn reactie aan dat het probleem kan worden aangepakt door de focus te verschuiven naar het business-level en het probleem 'samen' aan te pakken. Als het doel van deze verschuiving is om tot betere (systeem) requirements te komen, ben ik het hier fundamenteel mee oneens. Samenwerking vind ik een minimum voorwaarde, maar samenwerken kan op vele manieren. Door samen te werken kun je een deel van de problematiek oplossen, namelijk: wat valt er succesvol te automatiseren. Wat niet zonder meer zal lukken, is het opstellen van de 'systeemeisen'. De valkuil waar velen instappen is dat, zodra de discussie op business niveau afgerond is en duidelijk is wat er geautomatiseerd kan worden, de klant vervolgens de ict-professional vraagt om het voor wat betreft de systeem ontwikkeling vanaf dat moment alleen te doen, 'want dat is uw vak'. Op deze wijze levert verschuiving van de focus naar het business niveau het ideale startpunt op voor de door De Kruijf genoemde en wellicht ook gevreesde 'systeemeisen' die door en voor ict-mensen zijn opgesteld.
 
Doelstelling van mijn vorige reactie was en is om precies deze problematiek aan te pakken. Heel in het kort: het voorstel is om (systeem)requirements op te stellen, waarbij gebruik wordt gemaakt van een aantal basisregels. Het eerste belangrijke punt daarbij is dat de requirements heel concreet het te ontwikkelen systeem beschrijven (door gebruik te maken van zinnen die beginnen met 'het systeem zal ...'). Het tweede wezenlijke punt is dat de requirements in (business) taal van de gebruiker dienen te worden opgesteld. Op deze wijze kunnen (systeem) requirements worden opgesteld die leesbaar zijn voor zowel de ict-professional als de business-professional. Dit is de crux van deze methode. De business-professional kan blijvend beoordelen (en uiteindelijk ook testen) of aan zijn (hoger niveau) wensen wordt voldaan en de ict-professional kan goed beoordelen of het systeem binnen tijd en budget te realiseren valt.

 
Ignas van Megen, Senior system engineer