One of my consulting clients asked me to review a large requirements specification for a complex machine they were designing. This specification included a long table that described various states the machine could be in at any given time and the behaviors it should exhibit under certain conditions. I could understand the large quantity of text in this table, but it was hard to tell if the summary of system state behavior was complete and accurate.
To test that, I tried an alternative analysis approach. I drew a state-transition diagram — just boxes and arrows — based on the information in the table to show the various states and the allowed changes between them. In this way, I discovered two missing requirements, specific combinations of states and actions that did not have a defined outcome. It was difficult to find those errors by reviewing this bulky textual table, but the picture revealed them immediately.
Software systems involve a combination of functional behavior, data manipulation, and state changes. Real-time systems can exist in one of a limited number of states at any given time. A state change can take place only when specific criteria are satisfied, such as receiving a specific input stimulus under certain conditions.
A common example of a state-driven system is a highway intersection that incorporates vehicle sensors, cameras, turn lanes, pedestrian crosswalk buttons, timers, and signal lights. In addition, many information systems deal with business objects — sales orders, invoices, inventory items, and the like — with life cycles that involve a series of possible statuses, or states.
You can describe a set of complex state changes in natural language, but there’s a good chance of overlooking a permitted state change or including a disallowed change. Functionality pertaining to the state-driven behavior might be sprinkled throughout a requirements document. This makes it hard to fully understand the system’s functionality and to feel confident the requirements set describes it accurately and completely.
State-transition diagrams and state tables are two analysis models that provide a concise, complete, and unambiguous representation of an object’s or system’s states and the associated behavior. Let’s see how they work.
The state-transition diagram or STD shows the possible transitions between states visually. A similar technique is the state machine diagram from the Unified Modeling Language (UML). Same idea, different notations.
The STD contains just three types of elements:
- Possible system states, shown as rectangles. Some notations use circles to represent the state. Either is fine; just be consistent.
- Allowed state changes or transitions, shown as arrows between pairs of states.
- Events or conditions that cause each transition to take place, shown as text labels on each transition arrow.
The STD for an object that passes through a defined life cycle will have one or more terminal states, which represent the final status value that an object can have. Terminal states have transition arrows coming in but none going out.
As an illustration, let’s consider a chemical tracking system I worked on once. This system manages the inventories of chemicals in a large company’s research labs. It allows scientists to request new chemicals, tracks the location and status of individual chemical containers, provides health and safety information, and so forth.
When a user places a request for a new chemical, the system can fulfill the request either from the chemical stockroom’s inventory or by placing an order to a commercial chemical vendor. Each such request will pass through a series of states between the time it’s created and the time it’s either fulfilled or canceled — the two termination states.
Figure 1 shows an STD that models this life cycle of a chemical request. STDs for complex systems can be extensive, but you just have to trace through the arrows to see what’s going on.
This STD shows that an individual request can be in one of seven possible states:
- In Preparation. The requester is creating a new request, having initiated that function from some other part of the system.
- Postponed. The requester saved a partial request for future completion without either submitting the request to the system or canceling the request operation.
- Accepted. The requester submitted a completed, valid chemical request and the system accepted it for processing.
- Placed. The request must be satisfied by an outside vendor and a buyer has placed an order with the vendor.
- Fulfilled. The request has been satisfied either by the chemical stockroom or a vendor (one terminal state).
- Back-ordered. The vendor didn’t have the chemical available and notified the buyer that it was back-ordered for future delivery.
- Canceled. Either the requester canceled an accepted request before it was fulfilled or the buyer canceled a vendor order before it was fulfilled (the other terminal state).
When our user representatives reviewed my first draft of this diagram, they identified one state that wasn’t needed, noticed that another essential state was missing, and pointed out two incorrect transitions. No one had seen those errors when they reviewed the corresponding textual requirements.
This underscores the value of representing requirements information in multiple views or levels of abstraction. You do still need to write the detailed requirements for each state transition’s behavior, as the STD doesn’t include all those specifics. The system’s functional processing details are hidden behind the terse labels on the transition arrows and the state boxes.
A state table shows all the possible transitions between states in the form of a matrix. A business analyst can use state tables to ensure that all transitions are identified by analyzing each cell in the matrix. All possible states appear in both the leftmost column and the top row of the table. The cells indicate whether the transition from a state on the left to a state at the top is valid and identifies the transition event to move between states.
Figure 2 shows a state table that matches the state-transition diagram in Figure 1. The diagram format helps stakeholders visualize the possible sequences of transitions, and the table format helps ensure that no transitions are missed. You might not need to create both models.
The two rows in Figure 2 in which the values are all “no” are both terminal states. If the chemical request is either fulfilled or canceled, that’s the end of the process. You can’t change the request’s state at that point.
The state-transition diagram and state table provide high-level perspectives that span multiple use cases or user stories, each of which might describe a transition from one particular state to another. The state models don’t show the details of the processing the system performs; they show only the outcomes — state changes — that result from that processing.
These models provide numerous benefits. They help developers understand the intended behavior of the system. They facilitate early testing because testers can derive test cases from the STD that cover all allowed transition paths and verify that disallowed paths can’t happen. They let customers review the requirements documentation without getting bogged down in the details. Both help ensure all the required states and transitions are identified and understood.
The state-transition diagram and state table are among my favorite requirements tools. Every business analysis should know how and when to use them.
This article is adapted from Software Requirements, 3rd Edition by Karl Wiegers and Joy Beatty. If you’re interested in software requirements, business analysis, project management, software quality, or consulting, Process Impact provides numerous useful publications, downloads, and other resources.