It's many years now since I first encountered the wide variety of ice cream flavours available from Baskin Robbins. As their website states "From the initial concept (in 1945) of 31 flavours - one for every day of the month, over 1,000 different ice cream flavours have been created and enjoyed by ice cream lovers everywhere. "

"Has the alchemist suffered brain freeze?" and "what on earth do ice cream flavours have to do with use cases?", I hear you ask.

During my encounters with many organisations I sometimes feel that I've seen almost as many flavours of use cases as there have been Baskin Robbins ice cream flavours - sometimes several on the same project. But why is this and what's wrong with lots of flavours anyway?

Use cases have been evolving since Ivar Jacobson created 'traffic cases' to help him model interactions between system elements at Ericsson back in the 1960s. They have developed to the current situation where they are specified in the Unified Modeling Language (UML) and are also widely used in other approaches (with and without other UML models).

However, while the UML specifications have defined and standardised the use case diagram, this does not hold true for the use case description; UML only indicates that a use case needs to be described in some detail and this may be done either diagrammatically or in text form. Into this void have stepped many individuals who between them have, almost accidentally, defined a de-facto standard template for a use case description. Of these people, the most widely-used is probably Alastair Cockburn primarily through his popular book "Writing Effective Use Cases".

Please don't misunderstand me, I like this book a lot and have referred to it extensively; however I tend not to recommend it to beginners, here's why.

In his book Cockburn effectively defines 27 potential flavours of use case. In fact he suggests there may be more but that they wouldn't be appropriate or useful. 27 is obtained through 3 goal levels within 3 scope types at 3 levels of completeness (3x3x3). Let's ignore the 3 levels of completeness and focus on the nine flavours (3x3). My problem with the book is that in the first few pages (and the rest of the book is similar) he presents several examples, each showing a different flavour and making it hard for many to pin down just what a use case description is meant to be.

A safer approach is to start with one, basic flavour (Baskin Robbins might call this 'vanilla') and gain experience in using this flavour, becoming comfortable and consistent along the way. Having achieved a level of expertise, you can become more adventurous by sampling (and hopefully, mastering) alternative flavours. The basic 'vanilla' flavour of use case is otherwise referred to as a 'system use case' and is what many people understand a use case to be.

There are however many variations on even the system use case, this is why it is important that any organisation, department, team or collaboration using them should agree and define various aspects:

• What - the template (set of headings) to be completed consists of (over time and through appropriate degrees of completeness). This is the first step to standardising a consistent approach.
• How - the use case is to be completed in terms of an agreed style and syntax (there are many in common use). A template is not enough to get consistency; style guides with exemplars and on-going reviews are also necessary.
• When - it is appropriate within any process to expect the use cases templates to be completed and the level required. Expecting all use cases to be analysed and 100% complete as soon as possible without intermediate checkpoints risks causing issues leading to lots of rewrites with ensuing delays and costs.
• Who - is expected to create these use cases and more importantly, who is the audience for the use cases at these points in the process. These audiences between them will clarify, validate, own and sign off the use cases; or design, implement, deliver, test, document and develop other products based upon the use cases.
• Why - it is appropriate to utilise use cases rather than an alternative technique and vice versa. Despite them being one of the most useful tools the alchemist has encountered it should be understood that there are circumstances and projects where they are simply not useful. Any analyst, designer or architect should have a range of tools at their fingertips that they can employ in various combinations for different situations.

Without the above it is unlikely that an organisation will obtain the full benefits of use cases, or indeed any similar tool or technique.

Baskin Robbins has their Vanilla flavour ice-cream (other producers will have their own close variant) which I'm sure they can churn out consistently though application of a specific recipe and quality control. I'm also sure that the recipe has evolved over time to keep it current and relevant to their customers.

Once you get your use of vanilla flavour system use cases right then you can get adventurous. It is always important to remember that, sometimes, a jelly, yoghurt or even an old fashioned pudding is a valid alternative choice!