What is a business rule?

Junior requirements analysts sometimes have difficulty with how to document business rules for information systems, or indeed, with recognising them in the first place. I hope this short article helps.

Some Definitions

“A rule under which an organization operates. A policy or decision that influences a process step.” (Data Warehousing Team, Georgetown University)

“A statement that defines or constrains an aspect of the business. It is intended to assert business structure, or to control or influence the behaviour of the business.” (Business Rules Group)

These two definitions say essentially the same thing. It is interesting to note that the second definition appears verbatim on several web sites.

Context

Of course, even businesses that operate without computers have rules; a market trader might have a rule that any customer who buys three items gets a fourth one free or that all employees wear an apron while tending the stall.

In the context of building software that enables businesses to automate decision making, we are not interested in the last example. We are only are only interested in rules that allow the business to make a decision.

• Do I give this customer a fourth item free?
• Do I approve this customer’s loan request?
• Do I approve this employee’s leave request?
• Is this customer old enough to avail of this offer?

Within companies that have IT systems, there are rules that do not affect how the IT system itself operates; for example, there may be a rule that when paper form ABC123 is received, the details are always entered into the computer. One might mistakenly argue that this does affect how the IT system (henceforth referred to as the System) operates since a computer is used. However, it is up to the user to decide whether or not to obey the rule; the System cannot invoke the rule, nor does the rule affect the behaviour of the System.

In documenting an overall business process (i.e., with both manual and automated steps), we would of course make note of all business rules. However, when documenting a set of user-system interactions (e.g., in a Software Use Case), we are only interested in rules that are invoked by the System in order to influence the System’s behaviour.

Rule or Process Step?

Even within that context there can be grey areas. One could say that every requirement is a business rule, since it has been defined by the business, and that is certainly one approach.

If your approach is to document a process, perhaps the flow of an identified piece of work, later broken down into software use cases for handling that work, then structure has to be imposed in order to help us understand the business requirement.

We need to understand what triggers the process, the pre-conditions that must be in place before starting, the primary flow through it, any alternate and exception flows, the post-conditions that result from the completion of each path and the business rules that allow the System to decide which path to take.

The analyst has to consider whether the stated requirement should be documented as a business rule or as a step in a path or as a pre-condition to the process.

The following guide should make it easier to decide:

• If the requirement states the conditions necessary for a particular use case to be invoked, then it should be documented as a Pre-condition (or Pre-requisite) to the use case.
• If the flow can proceed down one path only from this point, then the requirement should be documented as a process step.
• If the flow can proceed down more than one path from this point and the requirement provides information that enables the Actor (in a Business Use Case) or the System (in a System Use Case) to decide which path to choose, then the requirement should be documented as a business rule.

Simplified example

Imagine we have a System for a travel club. Members can contact the club and book holidays.

Suppose we understand the following basic process for taking a booking:

Trigger:

• Actor elects to take booking

Primary Flow

1. System requests holiday code
2. Actor provides holiday code
3. System requests Passenger details:
   • Name
   • Address
   • Age
   • E-mail Address
4. Actor provides Passenger details
5. System saves booking

Now imagine that at a later meeting the Business makes the following statements

• Bookings can only be taken once the Caller has been verified.
• Whenever a booking is saved, the System should send a confirmation e-mail to all passengers.
• Passengers under the age of 18 require the consent of one parent or guardian. This is simply to be recorded as given or not given.

Let us apply our guide to the first statement:
It is clear from this requirement that the Caller must be verified before the User can start taking a booking. We therefore document a pre-condition for the “Take Booking” use case as follows:

Pre-condition

• The Caller has been verified

Let us apply our guide to the second statement:
The word “whenever” makes it clear. This step always happens. The System can proceed down only one path. It is therefore a process step.

We amend our process as follows:

Pre- condition

• The Caller has been verified

Trigger:

• Actor elects to take booking

Primary Flow

1. System requests holiday code
2. Actor provides holiday code
3. System requests Passenger details:
   • Name
   • Address
   • Age
   • E-mail Address
4. Actor provides Passenger details
5. System saves booking
6. System sends confirmation e-mail

Let us apply our guide to the third statement:
It is clear that the request for a parent’s or guardian’s consent is only required in some cases. The System can proceed down more than one path. This means that we require an alternate flow and we need to document a business rule that tells the system which flow to follow.

We amend our process as follows:

Pre-condition

• The Caller has been verified

Trigger:

• Actor elects to take booking

Primary Flow

1. System requests holiday code
2. Actor provides holiday code
3. System requests Passenger details:
   • Name
   • Address
   • Age
   • E-mail Address
4. Actor provides Passenger details
5. System validates Passenger age (Passenger is of age – see Alternate Flow 1)
6. System saves booking
7. System sends confirmation e-mail

Alternate Flow 1

1. System validates Passenger age (Passenger is not of age – see Business Rules)
2. System requests whether consent is given
3. Actor indicates that consent is given

At this point the process returns to step 6 of the Primary Flow.

Business Rules

• Passengers aged 18 or older are considered to be of age.
• Passengers not of age require the consent of one parent or guardian.

Notice how we have split the requirement. The part about what should happen when a passenger is not of age is documented under Business Rules. The part about how the Actor needs to interact with the system under those circumstances is documented in steps 2 and 3 of the Alternate Flow.

As an aside about use cases, rather than about business rules, we do not document here what happens when the Caller is not verified. The “Take Booking” use case only cares about when a caller is verified. In the Alternate Flow, if consent was not given in the case of a minor, this would be modelled as an Exception Flow, but that is another story.

There is another situation where business rules are needed that does not involve alternate paths.

This is where the Actor needs the System to return something but the Actor does not specify what should be returned. Anyone who has used the Internet is already familiar with the concept of searching for something. In the case of a search, the Actor provides the System with the search parameters, so the System simply has to return whatever matches those parameters. In this case a business rule is not needed.

However, in workflow systems, the Actor will at some point say to the System: “I have nothing to do now, so give me the next piece of work.” In workflow systems there is the notion of “cherry picking”, where the Actor gets to decide which piece of work to perform, but this is generally regarded as a bad thing, because it allows workers to avoid difficult pieces of work. Instead, the System chooses the piece of work for the Actor. However, the System needs business rules which tell it which work item to choose. Such a business rule can be simple:

• The System will provide the Actor with any unassigned work item.

Or more layered:

• The System will provide the Actor with the oldest, highest priority, unassigned work item.

There is a lot more to the topic of business rules and whole books have been written on the subject, but I hope this gives some kind of basic understanding to junior analysts.

For a much more in-depth look at business rules, I recommend Defining Business Rules ~ What Are They Really?

Kind regards,

Declan Chellar

Related posts:

• Amongst our business rules are… I’ll come in again
• Pre-conditions