When eliciting software requirements, there are a few major models that I primarily fall back on to help visualize the process, the system and the requirements: cross-functional process flows, use cases, system context diagrams and data-diagrams.   I have recently been using more models that I am less familiar with, such as the State Diagram and State Table.   

The State Table and State Diagram can be used in concert together, and essentially show the same information in table format or an illustration.   They are useful for vetting out requirements and business rules related to transitions between statuses or information states that aren’t readily illustrated in a process flow or use case.   First, I try to identify the possible states of an object, and then I look at the possible transitions between each one: 

1. Can I move from State 1 to State 2?
2. What would trigger this transition?
3. What are the effects of this transition?
4. What business rules or criteria need to be met in order for this to happen? 

For example, a mortgage may move through statuses such as 1) Application Submitted, 2) Credit Review, 3) Documentation, 4) Closed.  From here we create a table or diagram to indicate the possible transitions from one state to the next.   For example, I can move from Credit Review to Documentation (if I pass the credit review criteria), but I cannot move directly from Application Submitted to Documentation without first going through a Credit Review.   However, it turns out that during the Documentation process the loan may go back to Credit Review…the state table/diagram would identify that transition and allow me to discover what conditions would cause it to go back to that state.  

 Reasons to use a State Table and/or State Diagram: 

1. You need to understand the lifecycle of an object and the possible transitions from one stage of the lifecycle to the next.   
2. State tables/diagrams help to identify transitions that you may have missed.  Sometimes in process flows, we can get caught up in the “happy flow”, where everything goes as planned.   Since state tables/diagrams force you to examine each possible transition between states, it helps to drive out which transitions are even allowed and what requirements may be associated with them. 
3. You have a limited number of state transitions.  State tables/diagrams are useful for examining relationships between 3-5 states, but can be difficult if you have more than that.   If you are dealing with a complex system with several states, it may be useful to break them down into meaningful chunks of 4 or 5 states per table/diagram.