One area where many Business Consultants get tripped up is confusing Business Rules and Business Requirements. We looked at how to write Business Requirements last week, so let’s look at what Business Rules and Business Requirements have in common and where they differ.
Difference Between Business Rules and Business Requirements?
Why do we need to document Business Rules before starting to gather Business Requirements? Is there a connection between Business Requirements and Business Rules? One of the problems for Business Consultant is that they may focus so much on gathering Business Requirements, that they forget the underlying Business Rules which define how the business functions. Unless you’re clear on the difference between the two, you may end up gathering requirements which you may have to revise change later on if they contradict or break an existing business rule.
What is the difference between a business rule and a business requirement?
- Business Rules – these are statements (or conditions) that tell a person whether they can perform a specific action that relates to how the business operates. Business Rules also give you the criteria and conditions for making these decisions.
- Business Requirement – this may include what you need to do to enable the business rule to be implemented. In other words, a business requirement may not be valid if it contradicts or breaks an existing business rule.
Example of Business Rules
Let’s step back a minute. My Dad has three pet ducks at his home. One water duck and two land ducks. Yes, it gets very loud sometimes.
So, here are some rules regarding the ducks health and safety:
- Ducks cannot be given bread. It may choke them.
- Ducks cannot be left unattended when swimming. They are poor swimmers and may drown.
- Ducks must be given water with all meals. Helps them digest.
- Duck must have buddies. They’re very socialable and pine when alone.
- Ducks must be kept out of the kitchen. Yes, I see the irony
Ok, these are some of the rules we have for the ducks.
From Business Rules to Business Requirements
Now, imagine we were building a new apartment block for millionaire ducks. No doubt there will be many requirements about their lifestyle, feeding, entertainment and transport. While gathering and defining these requirements, we need to consider:
- The new apartment owners must not allow folks to give bread to the Ducks.
- If you’re building a swimming pool. They can have a pool if it’s a requirement, but they also need a life guard.
You get the idea, right?
Connection Between Business Rule and Business Requirements
Now that we’ve looked at how Business Rules work, let’s look at how and where they are connected:
- Do business rules exist even when you can’t implement a requirement? Yes. The Business Rules inn independent of the requirements gathering process. It can and must exist independently of other processes.
- Does implementing a business requirement mean complying with the business rule? Depends. In general, Yes, but there can be exceptions.
- Does implementing the business requirement make it easier to comply with the business rule? Yes. The connection will be stronger across all business process and allow greater understanding of how the Business Rules to Business Requirements function.
Sample Business Rule
This is an example of business rules for a bank taking credit card applications over the web.
Example: Taking Credit Card Applications Over The Web
- Business Rule: Customer has an Email Address.
- Business Requirement: Ability for bank staff to send and receive emails to the customer.
Now if we change the business rule:
- Revised Rule: Customer must have a valid Email Address.
Note: A second rule is required to define ‘valid email address’. An Email Address is considered Valid if does not return as ‘undeliverable’ within 60 minutes of being sent out.
Additional Business Requirement to support Business Rule:
System will immediately send email to customer once email address is received. The email is not batch processed but sent in response to each email received.
Note: The smallest change in the wording of the business rule can have significant impacts on other business processes. When testing business requirements make sure that you consider all possible scenarios where the revised business rule will impact other parts of the business.
- Business rules describe what you may or may not do in a specific business scenario. It also gives the criteria, conditions and exceptions for making these decisions.
- Business Requirements capture what a user must do to implement and/or comply with a Business Rule.
- You may need different sets of business requirements to implement different sets of business rules, for example, when dealing with complex business processes with complicated conditions and exceptions.
- Business rules are independent of business requirements and shouldn’t be changed to accommodate a requirement.
Be careful when changing a business rule in case it impacts how a business process functions.
There is one final point I want to share. Make sure that ownership of the business rules is properly assigned to someone – and make the person accountable.
One approach is to assign this activity to a business analyst with strong skills in document control and with the ability to push through new versions of revised Business Rules.
Try to find the most practical solution for managing your business rules. We used a networked Excel spreadsheet at a large European bank and it worked very well. All documents were version controlled and we followed a strict naming convention which made it easier to retrieve and update the rules when needed.
Don’t get tripped up on the technology. Once the team understand how the documents are structured, written and shared, then you should be fine. Also, remember to purge out-dated business rules. This means you’ll have fewer documents to manage and should speed up annual audits if/when the auditors want to check your document repository.
Final tip: in the Excel spreadsheet, cross-reference the business rule to the business requirements so you can quickly identify where one change impacts another.