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:

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)