After publishing the business rule model poster last week, we received a suggestion from Adriana Beal to provide an example that would illustrate the components of the model. Let’s consider a real life situation, purchasing a book from an online store (with an added constraint of no more than 10 items per customer). Here are the steps a customer would go through to make a purchase:


The business rules applied during the process are as follows:

  1. A book can be bought as either new or used by a customer from any location.
  2. Up to 10 items of the selected title can be shipped to the customer.
  3. The ordered item can be shipped through such delivery channels as either UPS or DHL or MAIL.
  4. The customer must provide a shipping address to place an order.
  5. The purchase can be paid for with credit cards (Visa, MasterCard, AmExpress) only.
  6. The accepted purchase order must be confirmed with a message sent to the customer’s email containing Greeting, Title name, Quantity, Price, Delivery channel, Expected delivery time.

    Please note that the model is meant to be applicable to any rules, and not every rule needs to include all the components from the model. The rules above only include a couple of components each. It’s a good idea to find a granularity level for the rules where they are simple and straightforward.

Step 1 identifies the object (a book) and scenarios (new or used books with different prices). The event that triggers Step 1 is the customer initiating the purchase of the book.
Step 2 deals with considerations (what title has been selected). It also considers conditions (no more than 10 items are allowed) and validates the contents of the shopping cart. This step allows the customer to change the number of ordered items. 

It also initiates a decision path which covers the (quantity – weight – shipping mode – shipping destination) decision on attributes to be applied to the selected object. The information required for the decision is gathered in steps 3 and 4. Step 4 uses a restriction on the outcome: the email address is a required attribute and no further move will be enabled without a valid email address. Step 5 is where the customer chooses a payment option. Rule V states that credit cards will be the only acceptable form of payment. If the buyer doesn't have any of the accepted cards, it's a situation that should fall into the exception trap as it can't be handled by the system. 

The reason for including the exception trap in the model is to encourage business analysts to consider situations which can't be handled within the system (this happens quite often in real life!) and to provide some alternative way forward for the users. In our example the store could provide a contact email address for the customer to ask about alternative payment options. Another great example from my experience is when I was buying something and my credit card wasn't accepted, the store manually arranged a way for me to pay using Paypal.

Going back to the purchase process, according to rules VI, the store will accept card details if the card type is right, save the parameters of the order and send the customer a confirmation of the order (actions and messages in the model) to the provided e-mail address (see rules IV and VI).
Hopefully this example gives you an idea of what each component of the business rule can be. The purpose of the model is twofold: to define the structure of the business rule, but also to serve as a reminder checklist when documenting business rules.

If you found this post useful, please share it with your colleagues!