Hi Bruce,
I have had this question on my mind for a while and now I actually had to put it to the test in a real project.
The problem
I have a system where there are explicit requirements for power consumption. There are three so called power states that the system must have:
- Operational state
- Max 45 mA
- Standby state
- Max 5 mA
- Sleep state
- Max 0,6 mA
The transitions between these states will be controllable by external signals. I therefore created a separate use case for this called StartUp_Shutdown (SU_SD), see below:
I also added the Unpowered and Powered states.
The system also contains a control function. The modes of this function according to the requirement will be:
- Off
- Control
- Error
I created a separate use case for this and called it Shift Gear (SG):
When the control function is Off, it is supposed to enter a lower power consumption state and here is where my brain starts to hurt. Apparently the SG uc needs to communicate with the SU_SD uc, since when the SG uc is Off, it is supposed to enter sleep or standby in the other uc in order to satisfy the requirement. But then I hear the echo of your words on p 152 in Agile Systems Engineering that good use cases are independent and that only in an extremely rare case do you (< 1%) do you need to have an association between use cases in order to co-simulate them.
I don't understand this. For me there is typically always an association with the power states of a system and the different modes of the different main functions of the system. Even in your own Harmony aMBSE Deskbook you have the stm for the Uc_ControlAirSurfaces that contains the same states as in the Start Up use case proving that the use cases are dependent!
So I am now thinking on how to solve this, should I have create an execution context for both use cases simultaneously? Or should I merge the two use cases to one? I am thinking about about having a Composited block owning a stm as you suggests in State Machine Corner Episode 6: Return of the AND-States which would then contain the two use case blocks.
Thanks!
All right thanks for the feedback.
To be honest, this sounds like one use case to me, not two. If you always control power together with the control function, then they are tightly coupled and should be in the same use case.
Remember, the purpose of the use case analysis is not design but rather to ensure that you have a complete, accurate and consistent set of requirements. It also sounds to me like you're trying to use use cases to do design work.