Thursday, 12 June 2008

Using the correct case

I think use cases are great, but unfortunately the term 'Use Case' has one meaning if you use them as a working tool, and more often than not, another meaning if used as a buzz-word in conversation.

It's a commonly used term by developers, but personally, I often cringe when someone in a management or marketing role uses it to identify a product feature or even just a single scenario - a clear case of use case misuse!

Use cases are a bit more technical than just an idea of how something may be used - the term was first coined by Iva in the 80's, and has since been expanded on greatly by the likes of Alistair Cockburn and his peers. They are a brilliant tool for gathering requirements and consist of nothing more than simple text descriptions.

However, even though a finished use case should be a shining beacon of simplicity and clarity, getting to that point can be devilishly complex and requires more than a little experience in writing use cases - the heuristic 'practice makes perfect' certainly holds true here. The trouble is, once you begin utilising use cases it quickly becomes apparent how useful they are in many more areas of software development than just requirements gathering.

A short list of areas where use cases can add value :
  • Requirements analysis - Is the use case describing what you want the system to do?
  • Requirement traceability - Justifying the inclusion of a particular piece of design or code.
  • Software design - Use cases can lead straight into the design phase, e.g. by using sequence diagrams for each important use case thread.
  • Planning and tracking - A set of use cases breaks the software system down into more manageable chunks, which can be planned and progress measured against.
  • Test design and writing - A use case is also a ready-made test case.
  • Release management - When deciding which features to include or wait for inclusion, use cases provide a mechanism for linking features to user goals.
  • Change management - Especially for iterative development, use cases can, for example, aid by scoping change requests to work estimates.

I won't go into more detail here, as plenty of insightful information is available elsewhere on these topics (See Alistair Cockburn's work, for example). Suffice to say that you can drive almost the whole software process using a use-case centric approach - not that you should, of course, and the circumstances to which you are fitting a process must always be considered carefully.

Once you realise the power of well-written use cases and understand the areas in which you will use them, it seems a good idea to spend more time considering their details and form - unfortunately there is no one-shoe-fits-all approach to this as the structure of a use case is very dependent on the domain and environment in which it is being used.

One example of this is for use cases geared towards embedded systems, where I have found the assumption of everything happening in 'zero time' to be very useful - you end a use case scenario whenever you have to wait for something. This approach would be unwieldy when writing a set of high-level use cases for a user interface, on the other hand.

One can spend many hours getting a relatively small use case or set of use cases together into a usable form that may appear to be a pedantic waste of time, but to an experienced use case author is time well spent. Many lessons are learnt and dead-ends reached when going through the process of writing and using use cases 'in anger', that time spent early on considering these lessons proves very beneficial in the long run.