Use-cases – why successful and popular?

 

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.

  • 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.
  • A user is represented by a stick figure and a use-case is represented by an oval.  Their interconnection by a simple line.
  • The relationship between a use-case and its scenarios are likewise very easy to represent.
  • 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.
  • 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.

Use-cases – why successful and popular?
Ivar Jacobson
Mon, 07 Mar 2011 20:40:51 GMT

Categories: Requirements Tags: ,
  1. No comments yet.
  1. No trackbacks yet.