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?
- etc…
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.
Hey Emal,
In the past when I have used ERDs it was purely to explain how entities are related to each other for data modeling. This article has given a different perspective and enlightened me on how to explain business rules better. Can we add ERDS and State Machine diagrams to a use case or does it sit in the technical requirements specification ? What is the industry best practice? Or what should I take into picture when submitting ERD and state machines?
Hey Thomas,
Yes, you can absolutely use State Machine models with Use Cases. There will often be steps in the use case that will trigger a state change for one or more of your business entities. This step in the use case is where you would reference your state machine model in the use case (I’ll illustrate this in the next article using the ESM Framework).
ERD’s can also be referenced from use cases, but there are less opportunities for this to happen. This is because ERD’s describe the structure of the business data, and this structure does not change because of any steps in the use case.
I normally store all my state machines diagrams, and ERD’s in a single document that I call “Core Specification.docx”. I make sure that the DEV and QA teams have understood this document before they start looking at any of the other requirements I produce.
This document forms the “backbone” of the detailed requirements and specifications I produce, and I often reference it in all the other documents I produce.
Seems like I should write another article called “how to structure your requirements documents”. What do you think?
Thanks for the above article. It helped me to understand how and where to use ERDs and State Machine diagrams. Please go ahead with “how to structure your requirements documents”.
Thanks Mohsin, I’ll put that article on my list. Feel free to suggest other things you’d like to learn.
Hi Emal,
Thanks for the feedback. I am eagerly waiting for the next article on State Machine diagrams. It will be a great idea to get out an article on how to structure a requirements document. I have another question, what is the difference between requirements and specifications? The BAs I work with interchange the terms a lot. It seems like both terms means the same. Could you please enlighten?
Hey Angelo,
The difference between Requirements & Specifications is in the level of detail.
In some organizations, the Requirements are typically produced by the BA to get an idea of project scope and sizing which then feeds into the project funding decision (i.e. Business Case). Once the decision has been made by the company to go ahead with the project (i.e. someone in the company provides funding for the project), then the BA would elaborate the requirements into detailed requirements/specifications. The government and non-profit sector tend to operate in this way more than profit oriented companies.
Most companies will blend the requirements and specifications together because of the way they fund and execute their projects. They will do their project sizing without formal requirements (i.e. no BA involvement), approve the project, and then ask their BA to produce requirements/specs.
This 2nd scenario makes the job of a BA harder because now the BA has to scope the project and produce the requirements all in parallel.
I’m going to be covering this in the Core BA Skills section of the learning program, and I’ve also added this as a topic for the blog where I can give a more thorough answer with some clear guidance.
Keep these great questions coming.
Very well written. Great information in a small clear package.
Thank you Louie. Feel free to suggest topics you’d like me to cover in future articles.
I just found your website this morning. I have been a BSA now for 2 years and your site has flow, is not overwhelming with links, and has answered so many question in a few articles. I’m currently working on a project I feel is taking to long with my developer because I haven’t provided them an ERD and a state diagram. I can’t wait to produce these this week and see if this helps procure a better solution.
Thank you very much
Nat
Wow. I am humbled. Thank you for this comment Natalie. It motivates me so much when I see comments like this. It’s encouraging to know that my writing is having such a direct impact on how people do their work.
Thank You.
Hey Natalie, I also wanted to point out another very important theme in your comment: The theme of “taking responsibility for outcomes”.
Sometimes, it can be so easy/tempting to draw a clear line and say “I’ve done my part, now you do yours”. It might seem subtle to some, but to me, your comment demonstrates a mindset for success: “Things are not going well, what can I do to improve the overall outcome?”
Taking responsibilities for outcomes is a hallmark of a serious professional, and is very heavily valued by employers. I believe that this alone will bring you much success in your BA career.