Alex returns with his blog post series on understanding use cases...
Wow, it’s
been four months since I wrote my piece on primary scenarios so this is
severely overdue. I choose to blame this on the fact that one of our account
managers, Ajay, appears to be offended by the idea that my calendar can have
days in it that have no entries at all and does everything in his power,
successfully I might add, to account for every minute of every day of my life.
This has actually become something of a joke with many of our customers who,
when asking me if I’m available to do something, “understand” that I must first
get permission for Ajay before replying. Enough about my scheduling situation,
were here to talk use cases.
Our
previously defined primary scenario details the required behaviour of the
system under “ideal” conditions and is useful in the understanding of customer
requirements. The thing about customer requirements is that, even the most
thoroughly defined, requirements are likely to only specify the nominal
behavioural flow. Most of the customer requirements that I have read are
significantly lacking in detail when things don’t go according to plan.
The use
case primary scenario provides us with a clearer understanding of what it is
that our customer requires but what about the things that they didn’t take into
account? It is here that the alternate scenario provides answers or, in the
case of most requirements, questions that need answering.
The identification of alternate scenarios is a three step process:
- Run through each step in the primary scenario and ask yourself; “what could happen differently?” to produce a list of potential alternate conditions
- Rationalise the list by removing those that the system cannot or does not need to handle and merging the ones that will be handled in the same way
- Write the scenario for each condition in the rationalised list.
During
the identification of alternate conditions you should be looking for things
such as:
- Incorrect behaviour on the part of either the primary or supporting actors
- Timeouts; one of the actors failing to provide a required interaction
When
writing an alternate scenario the alternate condition becomes the trigger and
then all we have to do is write what happens next until one of two things
happen; either the primary scenario is re-joined or the use case ends because
the goal cannot be achieved.
Typically the documenting
of alternate scenarios is where use cases provide the most benefit in
highlighting the inconsistency and incompleteness of the customer requirement.
Finally
one should repeat the process on each of the alternate scenarios to identify
possible alternates upon the alternates. Obviously this could be applied
recursively through many levels however I tend to find that if you need more
than two layers of alternates you should reconsider the scope of the use case
as it is highly likely that you have attempted to include multiple capabilities
that should each have their own use case.
Even with
only two layers of alternates it is possible to develop far more scenarios than are
actually needed, so, be sure to always question if what you are writing is adding
to the required understanding of the system under development.
Next time
I’ll look at how we model common and specialised behaviour in our use cases.
