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.

businessruleRule 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:

6 comments to What is a business rule?

  • Paraic Hegarty

    Declan, thanks for this great explanation. Which I already knew all of, obviously. Im sure other people will find it very useful.

    It just struck me while reading that this approach is quite similar to the modular approach in programming – the business rule for age checking being implemented as a separate function call, the age of majority being a constant, and so on. While these are obviously implementation issues, they are aimed at making the code readable, maintainable and flexible.

  • I know what you mean, Paraic. I have enough experience of programming to say I would take a similar approach to code.

    However, the focus of the analyst is to represent the customer’s needs and rules in such a way that allows maximum flexibility in their design – description rather than prescription, I like to say. Crucially, in BPM, the analyst has to make sure the customer is allowed maximum flexibility in maintaining their rules.

    I’ll address this in more detail in a later post.

  • Just came to read about this, and I ended up spending 20 minutes reading your other stuff too, good stuff man

  • Radha

    Hi,

    This is similar to the concept of modular use case – the more it is broken into sections, the more simple it is.

    I have a silly q – does this documentation cover any details of fields to be defined by line of business
    eg. Name – Should not be more than 20 char on screen
    Age – as defined in business rules
    Email add – standard validation apply
    Address – should not be international
    Phone number – should be in this format xyz – qwe – tyui

    Basically my question is how much depth should go in documentation and how much should be kept generic?

    Thank you
    Radha

    • Hello, Radha.

      I treat field validation rules as different to business rules. Again, this is to do with the Logical versus Physical distinction that I carry in my head all the time. Business rules crop up when you are investigating Business Use Cases and System Use Cases, whereas field validation rules only crop up when you are looking at screen design. I also label them differently: Business rules start with BR- and field validation rules start with VR.

      I don’t treat field formats as business rules. Rather, it is information I document when I am compiling my data dictionary (DD).

      To address each of the examples you give above:

      Name length: DD
      Age: BR
      Email: VR
      Address: VR
      Phone: DD

      Does this help?

      Regards,

      Declan

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>