I am pleased, honored and gratified that use cases are still a popular way of working with requirements. Googling “use case” yields 6 times more hits than Googling “user story”, but software development should not be driven by popularity. Instead we should use the most practical way of working. And, of course we have learnt something from other techniques. For instance, as I will discuss in my next blog, user stories and aspect-orientation have inspired us to make use cases even better while maintaining their core values.
The popularity of use cases has led to some misunderstandings and some distortions of the original technique. This is natural, and while it is encouraging to see authors take the original concept and adapt it to solve new problems, some of the misconceptions and distortions have clouded the original vision.
Common misunderstandings
Before further discussing the improved use cases, let’s first discuss common misunderstandings about what we have had since their inception (1986-1992). Many people believe that:
1) Use cases are for requirements only, which is not true. In fact, from the very beginning, they have also been used to analyze behavior, design software, and drive test identification, just to name a few uses.
2) Use cases are heavyweight; that you need to write fat specifications of each use case, which is also not true. In fact, use cases can be exceptionally lightweight (a brief description only), to lightweight (just an outline of the flows), to comprehensive (full descriptions of all behavior), and every variation in between. For most systems an outline can be very valuable and yet still be very lightweight. Today, we express this in a better way: when describing use cases, focus on the essentials, what can serve as placeholders for conversations.
3) Use cases are a technique for decomposing the behavior of a system, which is also not true. Some authors have introduced levels of decomposition, and others try to show use cases “calling” other use cases as if they were subroutines. Neither of these is right. A use case shows how a system delivers something of value to a stakeholder. Use cases that need to be “composed” in order to provide value are not real use cases.
4) Use cases are complicated. In fact, using use cases, if done right, makes a system easier to understand.
o It is impossible to understand what a system does from looking at many hundreds of user stories; the equivalent use-case model might express the system’s behavior in a few handfuls of use cases.
o A user is represented by a stick figure and a use case is represented by an oval. Their interconnection by a simple line.
o The relationship between a use case and its scenarios are likewise very easy to represent.
o To solve this problem with user stories, people have started to invent concepts such as themes and epics, making a case that the user story by itself is an incomplete concept.
o The use-case approach can accommodate a wide range of levels of detail without introducing new and potentially confusing concepts.
5. Use cases are only seen as being good for green field development, which of course is not true. They are great to explain large legacy systems as with such systems there is often little or no documentation left. Use case modeling is a technique that is cheap and easy to get started with to capture the usages of the system.
What people like about use cases
The reason use cases have become so widely accepted is that since their introduction they are useful in so many ways in software development.
1) A use-case model (a picture) already mentioned, which thus allows you to describe even a complex system in an easy to understand way, and which tells in simple terms what the system is going to do for its users.
2) Use cases give value to a particular user, not to an unidentifiable user community.
3) Use cases are test cases, so when you have specified your use cases, you have also after complementing with test data, specified your test scenarios,
4) Use cases are the starting point to design effective user experiences, for instance for a web site.
5) Use cases ‘drive’ the development through design and code. Each use case is a number of scenarios; each scenario is implemented and tested separately.
Moving forward
As we refine and improve use cases we are careful to make sure that we don't impact any of these things that are key to their popularity and success. In my next blog I will describe how we adapted use cases to backlog driven development and managing cross-cutting concerns.
-- Ivar
