Skip to main content

Author: Dan Tasker

Business Rules – Seriously?

Written by Dan Tasker on . Posted in Articles. 1 Comment on Business Rules – Seriously?

As a consultant I see a variety of templates at different client sites for documenting requirements or use cases. Many of these include a section for recording business rules. Like many BAs I have a basic intuitive understanding of what a business rule is, but as I ‘know a guy’ I decided to catch up with the latest and greatest thinking in the business rules domain. I’m a firm believer in “it’s not what you know, it’s who you know.”

My ‘guy’ (a woman actually) is Keri Anderson Healy. She is the Executive Editor of the Business Rules Journal. She kindly shared with me her slides from a presentation she gave last November. While I can’t share the slides themselves, I can share what I consider the take-away points.

Point #1 – Under business jurisdiction”

Business rules are rules that the business enacts, and has the power to revise or discontinue. A business may be constrained by external factors such as the laws of nature or government regulations. These are considered rules, but not business rules (unless of course your business is governing (or you are Mother Nature)).

Point #2 – Detailed enough to produce a consistent result

A well-defined business rule should be sufficiently detailed and precise that any person expected to conform to the rule can apply it effectively and consistently in relevant circumstances.

In contrast to the level of detail needed for a well-defined business rule there is the related concept of Policy. Where a business has policies defined these can be sources of business rules. Keri’s example of a policy was “Safety is our first concern.” This policy acted as the basis for the example business rule “A hardhat must be worn on a construction site.”

The level of specificity between policy and business rule strikes me as somewhat similar to the relationship between high level requirements and detailed requirements.

Point #3 – Behaviour-related business rules

Business rules fall into one of two categories – behavioural and definitional. Behavioural business rules are intended to affect people’s conduct or actions. The idea is either to get a person to do something or prevent him/her from doing something. The hardhat example above is an example of a behavioural business rule worded to get people to do something (i.e. put on a hardhat).  Funnily enough the same rule could be worded from a preventing perspective – “No admittance to this site without a hardhat.” 

Advice is another concept in the world of business rules. Rather than restricting, advices are the business expressing explicitly what is permitted or not restricted. “No smoking, except in designated areas” is a behavioural business rule restricting people from smoking in undesignated areas belonging to the business. “Smoking permitted in this area” advises that people who want to smoke, can within the posted area.

Point #4 – Definitional business rules

Behavioural business rules are established by a business to get people to act in specific ways. Those rules ideally will be followed, but may not be by everyone, all of the time. Definitional business rules establish what is ‘true’ within the context of that business and remains true for the business as long as the rule stands.

The following examples are definitional business rules within the context of a car rental company:

Example 1 – A Driver is a person that has proof of a valid driver’s licence.

This rule ‘defines’ the concept driver within the context of this business. If this were a golfing business the term would likely have a very different definition. The trick with defining one term is that the other words/terms used in the definition need to be ones that are understandable to business people.

Example 2 – A rental agreement is not complete without identifying at least one driver.

This rule is about one specific status value of a rental agreement. Similarly to how behavioural business rules can be about preventing rather than doing, there can be definitional business rules about what is not true. That is the case here. The rule is stating that the status cannot have the value ‘complete’ under conditions defined in the rule.

Example 3 – A rental spanning seven or more days qualifies for weekly rates.

The third rule defines the conditions under which it is valid to utilise a particular set of rates. The specific rate value from within the set that applies cannot be determined from this one rule. There must be other rules defined that would work in conjunction with this one for identifying one specific rate that is applicable under those combined conditions.

As stated above, definitional business rules state what is or should be true within the context of this business (or what is not true within the context of the business). As the business operates there can be cases where what the rule states is not as it should be. For example, a person renting a car using a forged driver’s licence. While this violates the rule it does not change the definition of what a driver is for that business. Similarly, a rental agent might let a customer have a weekly rate on a rental of less than seven days, but that does not change the rule / definition of what it takes to qualify for that rate. Definitional business rules are what the business intends to be ‘always true’.

Point #5 – Context is everything (and language is a bitch)

We saw above that the term driver had one meaning in the context of car rental and another one in the context of golf. The good news is that the context of business rules is always the business or organisation managing its rules. The bad news is that one term does not equal one business rule. As seen in the examples ‘stating’ a business rule involves one or more sentences, those sentences containing a number of nouns and verbs in whatever language is being used (e.g. English). But that’s not all. Sentences, in addition to nouns and verbs utilise a number of qualifier words such as must, greater than, not and many more.

The objective of business rules is to get consistent behaviour or results. That involves consistent understanding of the terms used to express the rules, with sentences constructed in a way that the combination of terms is understandable to all involved.

Business rules – seriously?

Show of hands – who thought the three example business rules presented in Point #4 were ‘well-defined’ business rules? Prior to undertaking this article my hand would have been raised. But having ‘looked under the hood’ at what serious business rule people do, I know a lot more about how much I don’t know. Ideally the take away points from Keri’s presentation will have raised your awareness about business rules and the complexities of defining them well. For those of you that seek more on this subject there is a document Keri was involved with titled Semantics of Business Vocabulary and Business Rules (SBVR). It includes a meta-model of rule-related concepts and a case study showing many good examples of well-defined behavioural and definitional business rules. The document is downloadable at http://www.omg.org/spec/SBVR/1.0/PDF.

Where to from here? Personally I do most of my business analysis at the IT Project level. Serious business rule analysis is supposed to take place at the business level, independent of any IT projects or solutions. When necessary I will use those existing templates and do my best to represent business rules within the context of the project, incorporating what I learnt from Keri’s slides and numerous emails exchanged with her while drafting this article – thanks again Keri!

Don’t forget to leave your comments below.

Six Things Every Business Analyst Should Know About Data

Written by Dan Tasker on . Posted in Articles.

1) Just because data is less popular than process doesn’t mean it’s less important

Business users are happy to discuss workflow diagrams representing their processes but few if any appreciate a data model representing the information managed by those workflows. In spite of this lack of appreciation of the role of data in information systems, the reality is that the primary purpose of most business processes is the creating, updating and/or referencing of data. An Accounting system supports the creation of Accounting Transactions related to maintaining Accounts. An Inventory Management system supports maintaining Inventory Items as stock is manufactured or received and orders are fulfilled.

The trick is to talk process throughout requirements analysis, but at the same time think (and record) details about the data involved. When a data issue arises that needs understanding I’ve learned to use screen mockups rather than a data model. For example, a quick sketch of an Order Entry screen with fields containing a few Customer details, Order details and Line Item details. Users easily relate to this and for the duration of the discussion data is the focus, not process.

2) Users operate in the real world and don’t have time to theorise about data

Business requirements are supposed to be implementation independent, whereas a data model is supposed to be logical or conceptual. Those terms may be meaningful to a Business Analyst but to a user they are theoretical, not real.

When data modelling was first proposed, new terms were used to distinguish logical from physical. The terms Entity, Attribute and Relationship were introduced. Process modelling has never required special ‘logical’ terms for Function, Process or Activity. So why can’t we use the original business friendly data terms when doing logical data modelling? For example, saying to a group of business users, “Here is the Customer record.

It contains Name and Contact Detail fields and there is a link so you can find the Order records for that Customer.”

Business users don’t care about data models and don’t want ‘theory’. So speak their language using the data terms they are comfortable with.

NOTE: Because the primary audience of this blog post are Business Analysts I will continue to use the terms Entity, Attribute and Relationship in this article.

3) The majority of entities belong only in detailed requirements.

I like to divide entities into three categories:

  • Big “E” Entities – the primary data concepts within an organisation. One or more databases containing records will exist and those records will have an ‘identifier’ assigned. Examples include Customer, Invoice, Account, Purchase Order, Inventory Item and Asset. NOTE: Big E Entities should be used when defining scope or high level business needs. Specifying their Attributes and Relationships should be left to detailed requirements.
  • Small “e” entities – containers for attributes that support Big E Entities. For example, if a Customer has multiple delivery addresses then Delivery Address can be treated as a Small e entity containing address details with a relationship back to the Customer. Identifying Small e entities, their attributes and relationships should be part of detailed requirements.
  • Micro Entities – simple sets of values, very often applying to a single attribute. Examples include Industry Type and Credit Status. Enumerating value sets is definitely a part of detailed requirements.

NOTE: One organisation’s Small e entity can be another organisation’s Big E Entity. In the example above, Delivery Address would contain a simple set of address details related to a single customer. There is no business advantage ‘reusing’ a given address if two customers live at the same location. However, in organisations that provide services to addresses (e.g. utility companies) Service Address is a Big E Entity. It is reused as customers move in and out and it has associations to other entities (e.g. plant or equipment installed at that location).

4) Relationships and attributes are both detail level

It is easy to believe that a data model that only involves relationships is ‘higher level’ than one that includes attributes. This may be true if by relationship you mean just a simple line connecting two entities, indicating that there is some relationship between the entities (to be defined in detail later on).

Just like attributes are not fully defined by just their name, relationships have properties that must be defined as part of detailed requirements. Attributes need a data type specified and depending on the type, other details. Relationships need cardinality defined (e.g. how many of entity A can or must relate to entity B and vice versa).

Including relationships between entities (even Big E Entities) can be a slippery slope prior to detailed requirements analysis. You need to be aware that the data model is not ‘high level’ it contains some, but not all of the detail. And getting business users to sign off incomplete work is never an easy task.

5) Real keys are meaningless numbers, facts help users identify instances

As mentioned in point #3, many Big E Entities will exist currently along with an identifier that the business has grown accustomed to (rightly or wrongly). Often they want any new system that will be replacing the current system to carry on using those ‘keys’ (i.e. newly created instances getting assigned keys that preserve whatever scheme the old system was using).

What those users really want is to be able to identify instances using something they know. If the old keys are a composite of one or more facts (like an Employee ID being made up of the first four characters of a person’s surname plus their year of hire plus a couple of digits thrown in for uniqueness) then the users are saying they want to be able to identify an employee by knowing a surname. If that isn’t enough, the system better present some additional details so it’s possible to distinguish between two people with similar surnames.

NOTE: Users will usually accept an improved (meaningless) key if their current key values are migrated and available as an alternate identifier for locating the instances they know and love.

6) Truly mandatory data or nice to have mandatory?

Truly mandatory data relates to the very definition of the entity involved. For example, an Order is only truly an order if it has at least one item being requested. Another example is a Car Rental requiring a value for Drop-off Location, but only in cases where the customer is not returning the car to the same location (i.e. a one-way rental).

Business users will often ask for something to be considered mandatory because the information has added business value. An example is the business wanting every cancelled Customer Order to include a Cancellation Reason (possibly selected from a value list or else free-form text).

The first two examples involve data that is critical to correct functioning of any system that maintains those entities. Such attributes or relationships should be identified as mandatory as part of documenting detailed requirements. With the third example, Cancellation Reason data will require extra effort on the part of the business to ensure data quality. Otherwise busy users will be able to pick any reason or enter enough text to satisfy the system and move on.

Users appreciate being reminded that they have neglected to provide truly necessary information. Conversely they get annoyed when not allowed to proceed until they have ‘completed the form’. When business users want ‘nice to have’ data made mandatory they need to understand there is a risk regarding the quality of the results.

In conclusion, to be effective as a Business Analyst eliciting business requirements, you should recognise the importance of data but at the same time understand that users want to talk about processes. When you do speak about data, use screen mockups rather than data models and stick to business-friendly terms such as Record, Field and Link. Recognise the most critical [Big E] Entities at the start and use them for scoping, while leaving [Small e] entities and Micro Entities for detailed requirements. Avoid dealing with Relationship details until detailed requirements. Analyse what facts users want to use to identify instances but don’t string those facts together in an attempt to define a key. And when it comes time to identify mandatory attributes and relationships, ensure that users understand the impact of ‘nice to have’ mandatory fields on the system users and the quality of the data.

What are your thoughts and personal experience? 

Don’t forget to leave your comments below.