How to Build the Business Rules Component Report of a Business Analysis
Within the requirements section of your business analysis, you should be sure to include a subsection for business rules. These rules are key to the way the business runs, and you need to spend some time focusing on them.
Whether implemented in a technology solution or not, business rules define the way that a business works. They provide a model for how a business runs and manages its enterprise; describe the governance framework for the processes, data, and actors within the business; and define the business logic that ties together the data, processes, and agents/actors.
Business rules are the defined control or constraint conditions under which an actor may (or may not) perform or complete processes or actions and/or successfully view or transform data. Overall, business rules provide for different outcomes or results.
Positive business rules give permission or allow something to happen, such as “employee is given one additional vacation day credit after 2 years of employment,” while negative rules restrict actions or data values, as in “check number must be greater than 99 and less than 9,999,999.”
The solution should not allow business leaders, processes, policies, or data to be undermined or compromised by allowing actions or data changes contrary to business operating procedures, regulatory policies, state or federal laws, or any other relevant stakeholder rule.
The special challenges of discovering business rules
Writing excellent requirements gets most challenging when you’re defining business rules because business stakeholders frequently don’t realize the circumstances under which they make decisions or allowances. In fact, stakeholders may not even recognize that certainly policies exist if they haven’t consciously thought about them.
Identifying and isolating the decision factors in the business rules that govern the work or the data is considered a bit of an art. A whole segment of the business analysis industry — including many specialists and technology solutions — devotes itself solely to the art of identifying and managing business rules, decision models, and decision automation.
Barring those tools, you as a business analyst must be able to recognize cases where a business rule exists and at least write down its description or outcome at a high level. Then work with your stakeholders to figure out all the exceptions to that rule — because those exceptions usually turn out to be the primary business factors and decision criteria.
Work can be done or situations resolved in plenty of different ways, but in a business environment, the decision about whether or how something will be done depends on different decision criteria or factors. Evaluation factors such as data values, security rights, order of events, or timing of actions can all play a part in determining whether something should or will be allowed to occur within a system or solution.
For instance, a business rule may be “benefits enrollment is allowed only 90 days after hire date or during the open enrollment period.”
But to identify the outcomes and exceptions, you really need to dig beneath the surface and ask the stakeholders things like “What if the employee is a rehire working here for a second time? Which hire date gets used in the evaluation of this rule; does the rule mean 90 days after the latest hire date? What happens on day 91?”
Cardinality for business rules
Business rules also have cardinality. The business must decide whether rules are optional or mandatory.
Optional rules allow actors to perform the action or transform the data despite a suggestion to the contrary. They show themselves through warnings or ask-the-user-first prompts.
You’ve probably seen one of these while using your own software solutions — after requesting an action or trying to update information that goes against what the system is supposed to do, you may have been asked something along the lines of “Are you sure?” or “You’re not supposed to do that; do you want to do it anyway?”
If the actor is another system rather than a human who can immediately respond, warnings or optional rules will be suppressed and not seen or will be documented on a report or exception log that tracks the success or failure of the interface transactions. There, you see a list of messages raising concerns about the data transmissions or changes, and suggesting that the specific transactions be reviewed or issues resolved.
Mandatory rules create errors for the actor, who experiences a block or pause in the workflow such as a message or window that stops the activity until the actor responds to the error and resolves the issue. A familiar rules-based error is “wrong password, try again” (the accompanying mandatory rule may be “user must provide a valid username and password for access”).
In system interfaces or batch jobs (automated, unattended data transformations or information transfers), errors may result in data not being processed or transmitted at all. In that case, errors are commonly recorded and reported through the exception/error log for later review and resolution.