When you hire a professional, you expect them to know how to use the tools of their profession. Your accountant knows how to use accounting software.

Your building contractor knows how to use a hammer. When an employer hires a business analyst, they have the same expectations. They expect their BA to be well versed in the tools of the BA profession.

Expressing requirements using business rules is one of these fundamental BA tools of the BA trade.

Table of Contents

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 that can change based on some business or system events
  • One of the statuses that an 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 a 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:

  1. The business needs to store data about an Order and an Item
  2. An Order must have at least one Item
  3. An Order can have many Items
  4. An Item can exist without belonging to any Orders
  5. 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.