Bedrijfsregels – vaak vergeten reqirements

Tijdens de bouw van de software komen wij er steeds weer achter, dat wij bepaalde
requirements gemist hebben. Hetzij tijdens het testen van de software, maar zelfs ook nog na
in productie name. Is er iets mis met de manier waarop wij requirements verzamelen en in de
ontwerpen verwerken? En welke requirements missen wij het vaakst?

In veel projecten wordt aan de gebruikers gevraagd om de requirements aan te leveren. Wat
wij dan krijgen is meestal een lijst, een mengsel van:

 klachten over het huidige systeem;

 wensen over de architectuur of de implementatie van het nieuwe systeem;
 eisen ten aanzien van interfaces aan andere systemen.
 vaag omschreven bedrijfsregels en functionele beperkingen;

Wat wij op deze manier niet krijgen zijn:

 definities van belangrijke gegevensonderdelen;

 verklaringen van werkstromen;
 geformuleerde bedrijfsregels (Business Rules).

Nu weten wij dat het niet verstandig is om het verzamelen en afstemmen van requirements
alleen over te laten aan de toekomstige gebruikers van het systeem. Daarom worden veelal
Requirement Engineers aangetrokken om de requirements volledig en consistent te krijgen.

Toch gaat ook dan nog het een en ander mis. Wat blijkt in de praktijk? De meest gemiste
requirements blijken in veel gevallen bedrijfsregels te zijn. En dit terwijl juist deze zo na aan
het art van de business gebruikers zouden moeten liggen! Immers juist deze bedrijfsregels
zijn het middel waarmee het gedrag en de besluitvorming van bedrijven wordt bestuurd
(http://brpn.org/index.php/1042388 ). 

Waarom worden juist de bedrijfsregels vergeten?

Een reden is dat functioneel ontwerpers zich doorgaans concentreren op de gewenste

functionaliteiten en omdat database architecten vooral aandacht hebben voor de modellering
van gegevens. Bedrijfsregels zitten bij de meeste ontwerpers (nog) niet zo op het netvlies.

Verklaarbaar omdat de meeste klassieke manieren om een IT systeem te ontwerpen

nauwelijks (of geen) aandacht schenken aan bedrijfsregels. Dat is tevens de reden dat ook
hedendaagse modellering hulpmiddelen (nog) geen adequate manier bieden om bedrijfsregels
op te slaan, laat staan daadwerkelijk te beheren. Daarom zijn ontwerpers gedwongen om
bedrijfsregels als commentaren te documenteren; bij voorbeeld als OCL toevoegingen in
UML modellen. De inhoud van deze commentaarvelden wordt vaak vergeten of gaat zelfs
verloren in het software design- en ontwikkelproces.
Mede dankzij deze tekortkomingen in ondersteunende functionaliteit van hun methodes en
tools, hebben analisten en modelleurs bedrijfsregels gezien als gewoon een bepaalde soort
requirements, die dienovereenkomstig behandeld moest worden. 

De kern van het probleem is het onvermogen van onze huidige standaard IT
modelleringtechnieken en de bijbehorende toolondersteuning om zaken zoals bij voorbeeld
beperking en afleiding van bedrijfsregels goed uit te drukken. Bij het beheren van
bedrijfsregels spelen nu eenmaal andere zaken een rol dan bij ‘gewone' requirements. Dat
vraagt om een andere benadering en om op Business Rules Management (BRM) toegespitste
tooling.

Andere vragen

De ervaring toont aan dat business experts meer dan bereid zijn om hun kennis en
deskundigheid te delen, vooral als zij zien dat het tot een beter systeem zal leiden. Het vereist
echter een ander soort vragen te stellen om de volledige set bedrijfsregels en hun
bijbehorende informatie te onthullen. Het is dan ook noodzakelijk dat de vragensteller goed is
ingevoerd bij de zaken, die bij bedrijfsregels een rol spelen. Alleen dan kan hij/zij de juiste
vragen stellen en zo de business experts adequaat faciliteren bij het opstellen van de
bedrijfsregels.

Beheer daar waar het hoort - en met geschikte tooling.

Daarom pleit ik ook voor het beleggen het beheer van bedrijfsregels binnen de business zelf.
En om dat te ondersteunen door middel van aparte en op de business gebruikers toegesneden
tooling, die beschikt over de functionaliteiten, die nodig zijn om juist de speciale zaken, die
bij het beheren van bedrijfsregels spelen te ondersteunen. Een goed in de Business Rules
thematiek opgeleide Requirements Engineer kan de business zeer goed faciliteren en
ondersteunen bij het beheren van de bedrijfsregels.

Gepubliceerd op: http://adi.atosoriginblog.nl/2009/02/17/bedrijfsregels-vaak-vergeten-

requirements/