One of the challenges faced by requirements analysts is the need to communicate the complex behavior of systems in an understandable yet rigorous and verifiable way. A significant amount of the effort in the requirements process is devoted to translating the users’ needs and goals from ‘the language of the user’ into an actionable and unambiguous specification suitable for use as input to the design and development process. This can be a special challenge for agile teams working through relatively rapid iterations where not a lot of time is devoted to model building before coding begins.
The state machine diagram is a UML artifact that works well for this purpose. Put simply, the state machine diagram captures information about the states an object can go through during its lifecycle. Some objects have relatively simple lifecycles and for these objects the state machine diagram may be overkill. However, be careful about dismissing any object from consideration. The lifecycles of many seemingly simple objects are more complex than they may at first appear. One of the benefits of using the state machine model is that it can help illuminate requirements related to events and state transitions that may otherwise be missed.
A state machine diagram can be drawn for any object but for the purpose of documenting requirements it is often useful to look at the product as a whole or at some component of the product or of the user interface as the object whose lifecycle we are modeling. A state machine diagram can be drawn for a use case along with, or instead of, an activity diagram.
The theory behind finite state machines says that an object has a finite set of possible states it can be in. An object in a particular state can respond to certain events by making a transition to another state. During the transition an action can take place. In state theory an action is an atomic (uninterruptible) operation. A state can have an entry action and an exit action so the sequence of events for a transition would be: 1) Exit Action (from the source state). 2) Transition Action. 3) Entry Action (for the target state). According to the theory, if we have a complete list of possible states and a complete list of possible events we can develop a complete model of the lifecycle of the object. In practice, some judgment may be required to determine the appropriate level of detail depending on the purpose of the model.
To get started, think about the initial and final states of the object. Keep in mind that an object may not have a relevant final state and may simply return to its initial state or to an idle state at the completion of a cycle. Identify the states an object will go through during its lifecycle, the transitions between states, and the entry, exit, and transition actions. For complex object lifecycles it may be necessary to model substates and composite states. A substate is simply a state that is nested within another state, the composite state. A composite state can contain any number of substates and substates can be nested to any level.
As you refine the model it may be helpful to create a state transition table. The table is typically created as a matrix and for each state, shows every other state and whether a valid transition exists. Check to make sure each state, other than the initial state and final state, has at least one transition into and one out of the state. For agile and iterative processes the state machine diagrams and state transition tables can be built up and refined over time and can provide a stable model across iterations.
At completion, the model should contain a full set of the relevant states an object can exist in during its lifecycle, the events the object will react to, the transitions the object will undergo, and the actions that will occur at each entry, exit, or transition. The state machine diagram can be used to validate and enhance the user stories and use cases and can also help communicate requirements in an unambiguous way to the development team.
