Home > Work > Setting Use Case Goal Levels

Setting Use Case Goal Levels

One area I have found my team repeatedly struggles with when defining use cases is: what is the scope, and what level of detail is required? To answer this question we need to ask ourselves what level of goal we are trying to describe.

Alastair Cockburn in Writing Effective Use Cases gives us an easy way to visualise the goal level by thinking in terms of the sea. He uses “sea level” to represent the user goal level, which he considers the most important. We can then raise our eyes upwards into the air for a summary (high) level, or dive beneath the surface for more detail of subfunctions. I find this is a very useful way to think about things.

To give us more than one way to remember this further Cockburn also gives each level a colour and a symbol:

Use Case goal levels

User goal level – sea level, blue

According to Cockburn, the question to ask here is “Can the primary actor go away happy after having done this?” One way to view this is something that a user will seek to complete in a single sitting. This equates to the Elementary Business Process, which Craig Larman defines as

A task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state (Applying UML and Patterns)

My view that Business Use Cases are written at this level; anything below this level is starting to stray into system design.

Summary level – cloud/kite, white

This shows the whole process in the context of the life-cycle. The timespan here can be days or even years. Each step is likely to be a separate user goal, defined further in a use case at sea level.

Cockburn gives two levels here, to show that some views are from a higher altitude than others – the normal summary view uses a kite symbol, but to show that some views are really way up in the sky, he uses a cloud. I would expect summary level use cases almost always to be at the kite level rather than up in the clouds.

Subfunctions – fish/clam, indigo/black

Beneath the waves lies the detail. Often this is of little interest to business users, and there may also be a lot of technical level detail that doesn’t really belong in a use case.

Again Cockburn provides two levels, just below the surface (fish, indigo), and right at the bottom of the sea where little light reaches (clam, black). His view is that there will often be value in writing use cases at the indigo level, but almost never at the black level.

My view is these are probably System Use Cases (if you are doing them). I would expect the use cases at this level broadly to represent steps in the user goal level use cases.

Do we need all these levels?

Almost certainly, No. It is useful conceptually to have these levels in mind, and use cases at each level may be valuable at different stages of a project.

Cockburn’s view is that use cases should only be written where there is a benefit in doing so – which means concentrating on the user goal level. In general there should be comprehensive coverage to a sufficient level of detail at this level to define the entire system. There may be value in providing summary use cases, particularly in providing a route map to the detail.

It will almost certainly not be necessary to provide a full set of use cases beneath the surface. It may be worthwhile to declare a full set of use case names, but often it won’t be worth going into the detail in use case format. Focus on the parts of the system with the most interaction or complexity.

See Also

From Goals to Use Cases (The Use Case Blog)

Categories: Work Tags: ,
  1. January 20, 2013 at 7:45 am

    It is very helpful to have a comprehensive view of a Use Case (which I prefer to call Servie Dialog SD). Typically UCs are complex and they have a TREE structure. That must be identified.

    Use Case Levels and Sub Use Cases:

    Alistair Cockburn has popularized about five levels of Use Cases but the usefulness of them is not certain. Many professionals get into “UC level” debates and do not have a basis for resolving them. The “Dialog Tree structure” provides a “holistic view” of a UC consisting of sub UCs in a tree structure. This provides a “basis” to determine the levels of every sub UCs. Note that a “sub-SD” is NOT a “Sub-Class” but is a part of UC.

    Every Use Case has a Unique Goal

    When an SD is divided and separated into sub UCs, it is “necessary to redefine their goals also”. Then they can be separated. Otherwise a complex UC gets fragmented without any clear indication of how to relate or connect them and navigate among them.

    Internal Processes are NOT UCs

    Some internal processes of the system are often mistaken as detailed UCs. They are NOT. If there is NO DIALOG with an external entity, it is NOT a UC. If there IS a DIALOG, then it “IS a UC.” The basis for this decision is the need for DIALOG.

    I would be glad to provide more details to those who may be interested.


  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: