Requirements Model 1 - The State Table

As Anthony C. said in an earlier blog post, requirements models are a great way to discover missing requirements in your software system. Without a good model, you have no way to be sure that you captured every requirement and seeing the missing requirements becomes nigh impossible. One of my personal favorite requirements models is the state table.

One of the reasons I like state tables so much is that they are very easy to create. The first step in the creation of a state table is the identification of a business object that you want to analyze. For example, in a loan approval system you might want to examine the loan application.

After you select a business object, you identify all of the states that your object can have. In our example, a loan application may be blank, ready for submission, submitted, approved, or rejected.

To construct the actual state table, you list all of the states along the X and Y axes of a table (letters A-E in the diagram above). The Y axis represents the initial state (e.g., submitted) and the X axis represents the final state (e.g., approved).

Now the fun begins. Every intersection of two different states represents a transition. These transitions, numbered 1-20 in the diagram above, tell you how your business object (the loan application) moves from the initial state (submitted) to the final state (approved). In our example, the transition between submitted and approved might lead to a whole set of requirements around the approval process, what must be present for an approval, and who gets to approve loan applications.

Why use a state table? Besides being incredibly fun to produce (okay, that may just be me :-)), they allow you to put a structure around your requirements that lets you discover holes. If there is no requirement related to one of the transitions in the table, there will be no way to transition from one state to the other in the final system.

In our example, imagine there were no requirements around the transition from rejected to approved. This may be an intentional aspect of the design, but chances are that this is not the case. If this were so, loan applications would get rejected and never be able to move out of that state by any means. The state table lets you quickly find these 'dead-end' scenarios and discuss them with the SMEs.

I love these so much because I used them very successfully on a project I worked on earlier this year. We were commissioned to create a financial system that managed millions of transactions a month. The system revolved around these transactions and their flow through the system. The SMEs had a very clear understanding of the different transaction states that they wanted to see but they didn't know all of the possible transitions. We constructed a state table and systematically moved through each possible transition to discover almost all of the requirements of the system.

These models may not work well when your SMEs don't already have states in mind. It can be difficult to impose that kind of structure on a problem where it doesn't already exist.

State tables have made complex system analysis problems much simpler and easier to digest for me and I hope that you will find some use for them on one of your projects.