Een goede requirement analyse hoort zich te ontwikkelen als een boom. Je begint bij de stam: de implementatie. Vanuit daar vertak je naar de betrokken functionele domeinen—bijvoorbeeld Finance, Inkoop of Logistiek. Elk domein vormt een hoofdtak die zich verder opsplitst in processen. Elk proces kent varianten: standaard verwerking (happy flow), alternatieve verwerkingen, en verstoringen. En per variant benoem je uiteindelijk de onderliggende requirements.

Die vertakking hoort niet willekeurig te verlopen, maar gestructureerd en logisch. Een gezonde analyse groeit evenwichtig, met takken aan beide zijden, steeds verder vertakkend. Je ziet direct waar iets nog niet is uitgewerkt.

In de praktijk zien we echter vaak een andere boom ontstaan: één of twee takken zijn volledig uitgewerkt (vaak gelieerd aan goed gestructureerde afdelingen zoals de afdeling Finance), terwijl andere domeinen nauwelijks of zelfs helemaal niet zijn benoemd. Dit beeld(van een scheefgegroeide boom) is illustratief voor een analyse die ongestructureerd is gestart.

• Doel: Gebruik deze metafoor om te begrijpen hoe een requirement analyse zich idealiter opbouwt: vanuit de kern (verandertraject) via domeinen, processen, varianten naar requirements.

• Toepassing: Gebruik deze visual als denkraam. Vraag jezelf af: lijkt mijn analyse op een evenwichtig vertakte boom, of eerder op een scheve boom met een paar overontwikkelde takken?

• Belang: Requirement analyse is een vak. Het is begrijpelijk dat je deze vaardigheid niet vanzelfsprekend beheerst. Deze metafoor helpt je om zelfstandig te reflecteren op waar je staat. Het maakt zichtbaar welke delen ontbreken, welke zijn doorgeschoten, en waar nog structuur nodig is.

Concrete aanbeveling:
Of je nu het hele project overziet of verantwoordelijk bent voor één domein: werk vanuit een gelaagdheid. Begin niet met het opschrijven van individuele requirements, maar structureer je analyse van abstract (stam) naar detail (vertakkingen). Start bij het geheel, breng de relevante domeinen in kaart, werk die uit in processen, splits deze op in varianten, en ga dan pas naar de requirements.

Deze manier van denken helpt je om overzicht te houden, zeker als het complex wordt. Het maakt inzichtelijk waar iets ontbreekt of scheefgroeit—zoals een proces zonder varianten, of een domein dat nog helemaal leeg is.

Wie direct begint met het verzamelen van requirements, eindigt al snel met een lange lijst die compleet oogt—maar vaak geen zicht geeft op wat ontbreekt. Door gelaagd te werken dwing je jezelf op elk niveau stil te staan bij de inhoud: welke domeinen doen mee, welke processen spelen daarbinnen, welke varianten zijn relevant? Zo word je per laag uitgedaagd om bewuster na te denken en voorkom je blinde vlekken in je analyse.