Understanding Business Rules and Data Requirements

Last week I was thinking about how to capture and analyse business rules and data requirements for a current project. I’ve worked on a number of projects where the focus can often be on either rules or data, however focusing on one while leaving the other out can cause issues further on in the project life cycle. I’ve learnt this on previous Business Intelligence/Data Warehousing projects where over analysis of the data can lead analysts to start to ask more questions of the data then the end-users or owners ever wanted to ask, while key rules are not enforced.

While doing some reading around the subject I came across Mary Gorman’s IIBA Spotlight Webinar on Business Rules and Data Requirements.

But firstly, what is a rule?

A declaration of policy or conditions that must be satisfied…. In order to define, stream or enable our system or process behaviour. (Gottesdiener 2005)

Mary discusses 4 types of rules that can aid a BA in categorising rules and their corresponding data dependencies. These 4 rules are:

  • Term Rules
  • Fact Rules
  • Constraint Rules
  • Derived or Calculated Rules

I am listing them below more for my own reference benefit, but hopefully others will find them useful.

Term Rules
Defining nouns such as “Customer” or “Gift Card” is important. This task is not just for your glossary but for giving context to your system or process. We’re able to identify actors (Customer) from terms based rules and this helps us define the scope or boundary of the work to be undertaken.

Fact Rules
Fact rules are a two way relationship between terms rules. For example:

  • A purchase is paid for by a gift card
  • A gift card pays for purchases

These can be extended to use cardinalities

  • A purchase may be paid for by one or more gift cards
  • A gift card may be paid for by one or more purchases

As we identify fact rules we can determine data attributes. For example:

  • A customer has an address. An address is made up of address lines, city and location.

Defining these data types allows us to define the scope of the rule. For example we don’t want a second address line.

Constraint Rules
Constrain rules can be used to constrain the action of a rule. In this example an expiration date is added to the gift card.

  • gift card expiration date must be equal to or greater than purchase date.

Derived or Calculated Rule
A calculated rule allows us to derive new attributes from existing ones. For example:

  • A gift card date is calculated from the date of activation plus 365 days.

Gottesdiener, Ellen, The Software Requirements Memory Jogger: A Pocket Guide to Help Software and Business Teams Develop and Manage Requirements. Goal/QPC, 2005

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.