ND8 DEVELOPMENT
Best Practice Software Development
© ND8
Thursday, July 23, 2009
Use Cases - Alive and kicking in 2009
Use Cases were introduced to the IS industry by Ivar Jacobson when, in 1992, he published one of the most influential books on software development, OOSE a Use Case Driven Approach. In that book Jacobson took just 18 pages to explain the concept and techniques, but despite the thousands of pages that have been written since, Use Cases still seem to generate a huge amount of debate and disagreement at the start of a project.
More recently, new techniques have started to challenge the use cases pre-eminence in the world of requirements analysis. Stories, scenarios and features have all emerged, most notably from the agile movement, while some people stick doggedly to good old functional decomposition.
So does the Use Case still have a role to play in modern software development? To answer this question lets take a look at the basic concepts. A Use Case Model is made up of Actors, people or other computer systems that interact with the system, and Use Cases, that represent the a goal of the actor when using the system. Withdraw Cash is therefore a valid Use Case where-as Enter PIN is not; as this is simply a step the user must make in order to meet their goal.
The concept of both Actors and Use Cases seem to be pretty universal and difficult to argue with. Determining the Actors dictates a user-centric approach to the development as we can define the solution by understanding their goals in using it. Documenting the functionality in the form of Use Cases ensures that all the processing steps required to meet that goal can be designed in a technically and functionally coherent manner.
Use Cases are also an extremely versatile vehicle. There a many different variations and styles that can be used to record the contents of a Use Case. Though I’ve developed my own, old school, style, the only rule that should be applied here is to remember that a Use Case is simply a form of communication and therefore, as long as the content is clearly understandable by both the users and developers, it is fit for purpose. Use Cases can also differ in the level of
detail they contain, the general rule here is only do the minimum necessary to move to the next phase of development, and this will depend on specific project circumstances.
So if the concepts are so simple, why the debate, and why the introduction of alternative techniques? The three main criticisms of Use Cases I’ve come across are (a) for complex functionally, they can become too large (10-15 pages) and therefore not read, (b) they can become bloated with detail, and therefore difficult to understand and (c) they can become standards led, taking away the focus on communication. These are all real issues that in my experience can lead to the development of use cases taking far too long, and worst the results being ignored.
The answer is to think of a Use Case as the shell and skeleton, providing the structure from which the detail can hang, and to use other, more appropriate techniques and models, to capture the specifics. When defining Use Case I rarely use the technique in isolation. The results of a JAD workshop usually will consist of a basic Use Cases model, Use Case descriptions recording their purpose and main features, a domain model, a screen flow diagrams, some page mock ups, perhaps a state transition diagram of a key entity, and whatever else was the best vehicle for capturing and demonstrating back the understanding gained.
The idea of a Use Case as a shell works well when applied to Agile developments where Use Cases do need to need to be broken up, as only the simplest can be developed in a weekly or fortnightly iteration. In this case the Use Case should be decomposed into stories – a scenario through a use case – which are perfect for setting a goal for the iteration. Features, a particular aspect of the scenario, are perfect for dividing the story into individual tasks to be developed by the team.
So in conclusion, for me Actors and Use Cases are still powerful concepts that help drive software development and keep it focused on satisfying user needs, no matter what the project or overall approach. And we’ve not touched upon a whole host of powerful, Use Case related techniques, from software design patterns to Use Case based estimating
techniques, that make the case for its continued use even more compelling.
The Use Case Feature List
A few years back I got caught unprepared running a JAD workshop with a bunch of business people and Java techies. We had an afternoon to determine the contents of the next release and needed to suck as much out of the session as we possibly could. What emerged – The Use Case Feature List - has become a trusty weapon in my armoury ever since.
In that workshop we didn’t have time to think about the normal course, or the alternates, never mind pre and post conditions. Instead we focused on identifying major use case, understanding their purpose, and exploring their main features, until we felt confident in our understanding. Where it helped we drew some screen flows, jotted down snippets of domain models, and sketched the odd state diagram. By the end of the session we knew that we’d a good basic handle on what was needed. Of course there was lots of detail to come, but we’d cope with that iteratively
The main output was a simple Excel spreadsheet containing a list of Use Cases and features. This list became the single source of all estimating, prioritisation, scope agreement and planning.
The list had emerged at a natural granularity, ideal for review, ideal for estimating, ideal for prioritisation, ideal for communication, ideal for release assignment and ideal for identifying services. It became the de-facto control document.
I’ve re-used this technique now on many occasions and with many different teams. Users seem to like it, techies seem to like it and managers seem to like it.
It’s simpler and faster than producing outline use cases and is a better vehicle for estimating and prioritising. It my opinion it improves both Use Cases and User Stories by combining the best bits of both techniques, and whether you intend to go Agile, or take a more traditional starting point, it’s proved to be a great starting point.
Richard Walls has been developing software solutions for 20 years and in line with the industry is
Use Cases