I remember when I was still green in my business analysis world and I was trying to boost my skills and knowledge while I was still working on building up my experience. One of the first things I came across was business rules and at the time, I didn’t really understand what to do with them.

What confused me was that a lot of what I read said requirements should be written as “system must do this” and “system shall do that”. So when I came across business rules for the first time, they had a similar structure, so I thought business rules were just another way to write requirements, which isn’t entirely true.

Business rules are not quite requirements

Business rules are meant to convey a state of affairs, much like a process diagram does. They describe how the business works (or how it should work in the future). They are NOT system/solutions requirements. For example, a business rule might be “Customers must be 21 to make a purchase”. This is a rule set by the business outside of any system. 

Now if this was a new rule the business wants to implement, then as a BA your goal is to write solutions requirements against this rule. For example, “the system must be able to validate the age of a customer”. 

Business rules should be kept to represent how the business operates, and in most cases where companies don’t specifically document business rules, you can actually find them embedded within process diagrams. For example:

So just to bring back to what you are supposed to do with them, business rules help you document the current or future state and are meant to represent how a business operates, and the system or application should work to make the business rule happen.