State & Transition Diagram (abbreviated as S&T) is a diagram of transition and state, a special technique for the transition of requirements specification from one status to another. With its help, the user can visualize the transition of the product from one stage to another.

It is a perfect option for long-term projects, where requirements specification is divided into large sprints, where control and verification of any action are required.

A vivid example of use. There is a state of object A. A certain action happened to it, and it got into state B. Then something happens again and it is already in stage C, etc. The principle of operation of the State & Transition Diagram is as simple and clear as possible.

State & Transition Diagram Visualization

Schematically, a similar technique is shown practically in the form of circles and arrows, where:

1. The circles are the current state of the object;
2. Arrows are a situation, event, or process due to which an object can move from stage A to stage B. This is a kind of action that can be performed by both the user and the system. For example, the process of downloading the program automatically began at 10 p.m.

The use of such schemes allows you to visually evaluate what transitions the software can perform and what needs to be tested first. The arrows, in this case, are already formed test cases that need to be checked!

How to Create a Diagram Correctly?

It is important to remember that State & Transition Diagram is created for one object! Ideally, this object should have an analog inside the product database.

Main steps:

1. Object selection.
2. Analysis of its states. It’s important to realize that one object can have only one state (it cannot be in two states at the same time).
3. Displaying states on a layout (graphic board, sheet of paper, or paint document).
4. Connecting objects with arrows, where arrows are actions that you need to perform.
5. Analysis of the received data. If you still have questions, return to step #2.

To start examining the states of an object, you need to answer just a couple of questions, namely:

• What kind of object did you select? What is its designation?
• What conditions are specific to this object?

The basic definition of the state is the sum of all available and unavailable manipulations with an object. The product you are testing should always “realize” the state of its objects.

When Will the Visualization of the Requirements Specification Not Bring the Proper Profit?

There are situations when visualization cannot make your requirements specification clear. And then it is necessary to decide what needs to be done instead:

• If your visualization map is too busy, you should divide it into several small ones;
• In case of some support difficulties, you need to think about the relevance of its use in the first place.

If your test diagram contains a lot of data – that’s too bad, because any diagram, first of all, should be easy to understand. If the user looks at it and gets lost, then such a scheme is not practical at all. This suggests that if the scheme contains too much data, you need to break it down into small parts that can refer to each other.

Conclusion

Drawing in any form is the most powerful and efficient visualization tool. It is strongly recommended to create state diagrams and transition plans. Even if it is a non-recurrent situation, you still need to use it to smooth out all possible vulnerabilities of your requirements specification as soon as possible.