Requirements

Bij het bestuderen van het handboek dat hoort bij de nieuwe IREB CPRE Foundation (Certified Professional in Requirements Engineering) training stuit ik op het begrip "requirements development". Het begrip komt maar één keer voor in het 140 pagina's tellende document, was niet vetgedrukt of op een andere manier benadrukt, maar toch bleef het door mijn hoofd spoken. Moeten requirements "ontwikkeld" worden? In feite is "ontwikkelen" een vrij letterlijke vertaling van "to develop". Beide begrippen zeggen zoiets als "de wikkel er af halen". Requirements moeten dus blijkbaar uitgepakt worden.

Maar eerst moeten ze worden ontdekt. Want ze bestaan, of je ze nu ontdekt of niet. Ze zijn er, bewust, onderbewust of onbewust, tussen de oren van je klanten of de toekomstige gebruikers van je nieuwe product.

Dus requirements moeten eerst ontdekt worden en daarna ontwikkeld. Is dat nu requirements engineering? Het is in ieder geval een deel daarvan. Als we ze eenmaal hebben, ontdekt en ontwikkeld, willen we ze gaan gebruiken als leidraad om een product te maken dat aan die requirements voldoet. Maar, dan moeten we het wel eens zijn over die requirements en ze moeten niet verouderd zijn, want de wereld om ons heen is dynamisch en verandert snel. Dus dat hoort er ook bij: overeenstemming bereiken over de requirements en ze up-to-date houden.

Een veelzijdig vak dus, requirements engineering: je moet die psycholoog zijn die de onuitgesproken wensen kan achterhalen, de lingu?st die ze kan omzetten in voor iedereen begrijpelijke taal, de boekhouder die ze in een database kan zetten en ze kan onderhouden, en nog veel meer. Te veel om in één kort artikel op LinkedIn te beschrijven. Dus dat gaan we anders doen. Samen met een paar collega's van Improve Quality Services wil ik de komende maanden elke week een onderwerp uit dit veelzijdige vak beschrijven. Een kwartaal biedt dan de ruimte voor 13 onderwerpen, dus lang niet alles zal aan bod komen.

Elk artikel zal herkenbaar zijn aan de brug, de verbinding tussen twee oevers, die symbool zal staan voor ons vak: de verbinding tussen twee partijen die goed willen samenwerken, door goed te communiceren en die wij daar graag in willen helpen.

Dit artikel was slechts het startschot. Volgende week zal Kaspar van Dam het spits afbijten met een blik op Shared Understanding.