Antwoord.

Bedrijfsregels zijn formele of informele normen die door een bedrijf zijn vastgesteld en die de manier van werken, besluitvorming, berekeningen, communicatie en informatieverwerking bepalen.

Een businessanalist identificeert, analyseert en documenteert deze regels om ervoor te zorgen dat het toekomstige systeem of proces aan de vereisten van het bedrijf en de wet voldoet. De regels kunnen eenvoudig zijn (bijvoorbeeld “korting wordt alleen gegeven aan vaste klanten”) of complex (“automatische bonustoekenning vindt alleen plaats indien aan een reeks voorwaarden is voldaan”).

Een correcte beschrijving van de bedrijfsregels garandeert:

• Overeenstemming van de bedrijfslogica van het systeem met de werkelijke processen.
• Consistentie van de vereisten tussen verschillende systemen en afdelingen.
• Vereenvoudiging van de modernisering, testing en ondersteuning van software.

Kernpunten:

• Niet alle vereisten zijn bedrijfsregels. Sommige zijn beperkingen voor implementatie of integratie.
• Bedrijfsregels veranderen vaak, daarom is het belangrijk ze uit de code te halen en in de documentatie te onderhouden.
• De taal van de formuleringen moet eenduidig en begrijpelijk zijn voor zowel het bedrijf als technische specialisten.

Misleidende vragen.

Zijn bedrijfsregels altijd hetzelfde als bedrijfsvereisten?

Nee, bedrijfsvereisten definiëren het doel dat moet worden bereikt, terwijl bedrijfsregels beperkingen of manieren zijn om dit doel te bereiken. Bijvoorbeeld, een vereiste kan zijn “verkoop met 10% verhogen”, terwijl een bedrijfsregel kan zijn “geef niet meer dan 5% korting aan nieuwe klanten”.

Kan bedrijfslogica worden geïmplementeerd zonder analyse en formalisatie van bedrijfsregels?

Nee, omdat niet-geformaliseerde regels leiden tot ambiguïteiten, fouten in de automatisering van processen en schending van de bedrijfsregels.

Waar moet de beschrijving van bedrijfsregels worden opgeslagen: alleen in de TS of ook in de systeemcode?

De beschrijving van bedrijfsregels moet opgenomen zijn in zowel de projectdocumentatie (bijvoorbeeld in de vereisten of een afzonderlijk register van regels) als weerspiegeld zijn in de bedrijfslogica van het systeem, maar de hoofdbron is het document, niet de code.

Typische fouten en anti-patronen

• Formulering van bedrijfsregels in te algemene of vage termen
• Verdubbeling van bedrijfsregels in verschillende secties van de documentatie
• Onvoldoende detaillering, waarbij één regel onbedoeld meerdere gevallen bestrijkt
• Het laten bestaan van bedrijfsregels “standaard” zonder duidelijke beschrijving (stille kennis)

Voorbeeld uit het leven

Negatief geval:

• In een project voor de automatisering van een kredietaanvraag hebben de managers de bedrijfsregels alleen mondeling herhaald, zonder ze in de specificaties vast te leggen, en verschillende ontwikkelaars hebben het mondeling verklaard - dit resulteerde in 3 verschillende uitvoeringen van één scenario. Voordelen: Snelle lancering van MVP; minimalisering van tijd voor afstemming. Nadelen: Ongecoördineerde logica bij verschillende scenario's, problemen bij automatisering, conflicten tussen afdelingen.

Positief geval:

• Voor de taak van kredietgoedkeuring heeft de businessanalist een register van bedrijfsregels opgesteld voor alle types aanvragen, goedgekeurd door de jurist en IT. De implementatie kostte iets meer tijd, maar de regels waren voor iedereen duidelijk. Voordelen: Eenduidigheid van de bedrijfslogica, minimalisering van fouten in de automatisering. Nadelen: Meer tijd besteed aan het voorbereiden van de initiële documentatie.