Alex returns with his blog post series on understanding use cases...
Wow, its 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 far more scenarios that 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.
