What would be the better unit to draw state machine diagrams in SRS?

Question

Recently I am working on a SRS documentation for my university project. When I draw the state machine diagrams I'm confused for what parts should I draw it. Is that for the components? or for the classes?

Clearly the inherent state of the object shows in the state diagrams. But, my question is how do we find for what we should draw states. Is that get from the components or classes?

Answer 1

An SRS is a System Requirement Specification: you document the requirements and not the solution. So the state diagram in the SRS should be related to the requirements, whatever they are.

In UML, state-machines are defined for classifiers. They can define event driven behaviors (behavioral state-machine) or the valid set of interactions with the classifier (protocol state-machine). A classifier is typically a class or a component: both are possible.

But in your SRS you don't care: you don't need to provide an SM for every class or every component; you need to provide an SM only if there are state-related requirements.

Dummy examples:

1. The user may create a shopping basket, and add items from the catalog to the cart. Items may also be removed. The user may view the shopping cart and continue the purchases. The user can check-out the shopping cart, and once the payment is completed, no changes shall be possible anymore to the cart.
2. The controller ignites the rocket booster. Once the booster fuel level is detected to be empty, the controller activate the decoupling of the booster, and ignites the main engine. Once the booster is succesfully decoupled, the controller shall monitor any variation in altitude.

You'd certainly model 1 with classes, and the constraints about the validity of operations on shopping cart are easily expressed in a state-machine. This is, by the way, typical for any object that has a life-cycle that is to be tracked. The other classes seem not to have any interesting state to model.

You'd certainly model 2 with a controller component, and the event-driven set of behaviors are easily and clearly expressed with a state-machine.

So ultimately, you do not care if it is a class or a component. The only thing that should drive your modelling in the SRS, is if there are behavior or constraints that CAN be expressed more precisely/easily/clearly with a state machine. Many SRS don't even show any state-machine, because the states emerge only in the design of the solution.