As a Business Analyst creating your software requirement models, do you ever wonder, when would you use a State Table as compared to a State Diagram? Now, I’m not going to get into the nitty gritty details about what each model is and how to create it, but I am going to talk about when you would use one versus the other.

Here are examples from State Tables and State Diagrams that are for the same order object.

So let’s look at how they compare. State Tables and State Diagrams are very similar in how you decide that you need one for a business object. They are also very similar in discovering the states for your object.

Score: State Tables 2, State Diagrams 2

Let’s say you’ve identified your object and your object states, now it’s time to identify all of your transitions. The best approach to identifying them is to use a State Table and consider literally every cell in the table for whether it is a valid transition. For our example State Table, you would methodically ask questions such as these:

• Can an order move from drafted to drafted?
• Can an order move from drafted to finalized?
• Can an order move from drafted to priced?
• Can an order move from drafted to completed?
• etc.

Then, can an order move from finalized to drafted? Finalized to Finalized? Finalized to Priced? And so on…

The table makes it easy for you to consider 100% of the possible transitions. You just have to make smart decisions about which of those is valid.

However, if you try to do this in a State Diagram, it’s a bit harder. You can look at each circle on the diagram and ask the same question, but because they are not usually cleanly organized and because you don’t indicate ones that are not valid transitions, it’s just harder to track that you have looked at them all. There is no “checklist” as you consider them all.

Clearly our score is now: State Tables 3, State Diagrams 2

But alas, let’s say you have your state and valid transitions identified and it’s time to really use your state model to visually look at how an object flows between states sequentially. You can essentially get this information in a State Table, but it’s very hard to just see it easily. A State Diagram though makes it really obvious. For our example above, we can see how our order object moves through the states from Drafted to Finalized to Priced, etc. In fact, once the order is confirmed, it can only go back to the beginning if there is a factory issue on it, otherwise it flows through the states to completion. Simply put, a State Diagram is easier to read to understand how the states relate and are sequenced.

I think it’s fair to say now our score is: State Tables 3, State Diagrams 3

So there you have it – let’s call it a draw! Or better yet, both are winners! The point is this, almost always, as a Business Analyst you should begin with a State Table to identify your transitions and you should also create a State Diagram from your State Table because it is far easier for someone like your business or developers to read.