RULE 5: Focus on goals, not behaviour
There is a subtle distinction between the functional behaviour of the system and the goals of the actors. This can cause confusion: after all, the functional behaviour of the system must surely be the goal of the actor?
It is very common, then, for engineers to write use cases that define, and then describe, all the functions of the system. It is very tempting to simply re-organise the software requirements into functional areas, each one becoming a ‘use case’. Paying lip-service to the ‘rules’ of use case modelling, these functions are organised by an actor that triggers the behaviour.
Use Cases based on functional requirements, rather than Actor goals.
I call these entities Design Cases to distinguish them from use cases; and they can be the first steps on the slippery slope of functional decomposition (see Rule 11 for more on this)
Identifying goals requires a change in mindset for the engineer. Instead of asking “What functions must the system perform?” and listing the resulting functionality, ask: “If the system provides this result, will this help the actor fulfil one (or more) of their responsibilities”. If the answer to this question is ‘yes’ you’ve probably got a viable use case; if the answer’s ‘no’, or you can’t answer the question then you probably haven’t fully understood your stakeholders or their responsibilities.
In other words, the focus should be on the post-conditions of the use case – the state the system will be in after the use case has completed. If the post-condition state of the system can provide measurable benefit to the Actor then it is a valid use case.
Let’s take a look at what I consider a better Use Case model:
Organising use cases by Actor Goal
The post-conditions of the use cases (above) relate to the goals of the Actor (in this case an Air-Traffic Control Officer). We can validate whether the post-conditions will be of value to the Actor.
The (main success) post-condition of Land Aircraft is that one of the ATCO’s list of aircraft (that he is responsible for) is on the ground (safely, we assume!). At this point the aircraft is no longer the responsibility of the ATCO – one less thing for them to worry about. I argue that this is a condition that is of benefit to the ATCO.
Similarly with Hand-off Aircraft. As aircraft reach the limit of the local Air Traffic Control (ATC) centre they are ‘handed-off’ to another ATC centre; often a major routing centre. The post-condition for the hand-off will be that the departing aircraft will be (safely!) under the control of the other ATC, and removed from the local ATCO’s set of aircraft he is responsible for.
Receive Aircraft is the opposite side of Hand-Off Aircraft. That is, what happens when the ATCO has an aircraft handed over to them from another ATC region. At the end of the use case, the ATCO must have complete details and control of the received aircraft.
When an aircraft takes off, the aircraft must be assigned to an ATCO, who is responsible for routing it safely out of the local ATC region. The post-condition of Take-Off Aircraft must be that the aircraft is assigned to an ATCO and that ATCO has all required details of the aircraft’s journey.
In the last two use cases, the ATCO actually gains work to do (another extra aircraft to monitor). The requirements of the system must ensure that when the new aircraft is received the transfer is performed as simply, or consistently, or straightforwardly, as possible. This is the benefit to the Actor.
While one could easily argue this is a simplistic model for Air Traffic Control it demonstrates basing use cases on goals rather than functional behaviours. Each use case is validated by its post-conditions, rather than its pre-conditions and behaviour.
He specialises in C++, UML, software modelling, Systems Engineering and process development.
- Practice makes perfect, part 3 – Idiomatic kata - February 27, 2020
- Practice makes perfect, part 2– foundation kata - February 13, 2020
- Practice makes perfect, part 1 – Code kata - January 30, 2020
Glennan is an embedded systems and software engineer with over 20 years experience, mostly in high-integrity systems for the defence and aerospace industry.
He specialises in C++, UML, software modelling, Systems Engineering and process development.
Pingback: Sticky Bits » Blog Archive » The Baker’s Dozen of Use Cases – Part 8