My uncle once hired a plumber to unclog the sink, only to find out that this plumber had never used a plunger before.
Imagine my uncle’s surprise.*
This is the same surprise that an employer might experience after finding out that the BA they just hired has never written a business rule before. Sure, this fictional BA has had plenty of experience writing requirements in the past, but the employer knows that they have not written the requirements in the most effective way possible.
Expressing requirements using business rules is a fundamental BA skill.
Business Rules Should be Mastered by Every BA
The simplest way to express a business rule is to write it out as a complete sentence. For example, we might have a business rule related to Orders (from our last example) which could be:
- BR12.4 – An Order is completed once the final item on the order has been shipped by the fulfillment department.
The developer you’re working with will learn many things from just this one sentence. They’ll learn that:
- The Order has a status which can change based on some business or system events
- One of the statuses that an can Order can be in is called completed
- The Order has some relation to an Item
- The fulfillment department is an actor whose actions can affect the Order
The developer will also have many follow-up questions that they’ll be looking to you to answer.
- What exactly is the nature of the relationship between the Order and the Item?
- Is the Order related to anything else? If so, in what way?
- What other statuses can the Order be in beside the completed status?
- How, and when does the Order move through those different statuses?
- Are there any other rules related to the changing of an Order’s status?
At this point, the BA has a decision to make:
“Should I continue writing more sentences, or is there some better way to express these business rules?”
There’s a Better Way. Entity Modeling
There are two different entity models that the BA can rely on to document, analyze, and communicate a large volume of business rules, using the least amount of words. These models provide much higher level of precision than words can express (developers love precision).
#1 Entity Relation Diagram (ERD)
The ERD helps the BA capture the business rules related to the relationships between different business entities (e.g the Order entity and the Item entity).
The developer sees many business rules in this ERD:
- The business needs to store data about an Order and an Item
- An Order must have at least one Item
- An Order can have many Items
- An Item can exist without belonging to any Orders
- An Item can belong to many Orders
The ERD leaves no room for misinterpretation. All developers are trained to read these pictures the same way. All BA’s should also train themselves to produce these pictures the same way.
#2 State Machine Model (a.k.a State chart diagram in UML)
The state machine model captures the life cycle of a single entity.
I’ll explain State Machine Models in more detail in the next article.
* This story I told you about the plumber is a fictional one, but the point it’s meant to illustrate is very real.
Would anyone else find this useful?
Please share this article with one person who you know is interested.