Archive

Archive for May, 2010

Setting Use Case Goal Levels

May 28, 2010 1 comment

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: ,

Gardening and Project Management

May 18, 2010 1 comment

My garden

My house was built in 1874. Space was not a premium in what was then a small market town, so it has a long garden. (I could live without at least half of it!) Each year I face a constant battle to keep it under control. It has struck me how much overlap there is between the routines of gardening and project management.

Keeping on top of the garden – especially at this time of year – requires endless weeding, pruning and tidying. They are all small jobs individually but if left for any length of time at all the garden rapidly becomes overgrown and each one becomes a big job in its own right.

As a Project Manager, I face a similar range of tasks needing constant attention – reports, plans, issues list, defect queue, documents to review. As with my garden, these are all small jobs individually but if they are left for any length of time each one becomes a big job in its own right.

In fact I think the garden in springtime is worse – if left alone the amount of work grows exponentially.

Both garden and project need to be kept under constant review; a repeated quick survey of both is needed to see if any single task is becoming urgent.

Another similarity is the need for good planning. As well as all the background tasks, each year I have to find time for a number of significant jobs, with a large enough block of time to get the job done. They also have deadlines, e.g. certain trees must be pruned in a particular month, but still everything else has to be done as well. This is similar to planning a new development cycle, with its own set of tasks and deadlines, while continuing to produce all weekly or monthly reports and such like on time.

Finally, contingency planning is important for both, as the best plans can be derailed by events outside my control. Particularly at this time of year when everything grows like mad, it only takes one or two weekends when other things come along to divert my attention (a wedding one weekend, continuous rain the next), and suddenly everything’s out of control again. Likewise in project management – a big crisis arises, causing new requirements to emerge suddenly and lots of meetings, and my spare day to do all the paperwork has suddenly been used up. A flexible approach is essential, not just to make sure there is some spare capacity in the plan, but also to take advantage of opportunities when they arise.

Both gardening and project management require constant vigilance, keeping a step ahead to provide some spare capacity to cope with the unexpected. Both assume a degree of planning to make sure everything gets done at the right time. A similar strategy is needed for both, for example making good use of spare half hours (cut the grass, update the plan). Finally both need flexibility to respond to changing events at no notice.

And, of course, neither job is ever finished…

Categories: Work Tags: ,

Business and System Use Cases – what’s the difference?

May 8, 2010 9 comments

On my last project, the team was confused at first by the difference between Business and System Use Cases, and their purpose.

This issue appears in an article Vague and Ambiguous use cases by Matt Stephens in The Register, where he gives two examples of use cases covering the same subject. The first example, which he knocks as too vague to be any use, is actually a Business Use Case, whereas the second one is a more detailed System Use Case developed from it. Oddly he doesn’t use either term. This reflects the problem – people don’t understand the difference!

The most succinct definition I have found is Alistair Cockburn’s (in Writing Effective Use Cases), in the reminders section rather than the main part of the book.

A Business Use Case is one in which the design scope is business operations. It is about an actor outside the organisation achieving a goal with respect to the organisation. The business use case often contains no mention of technology, since it is concerned with how the business operates.

A System Use Case is one in which the design scope is the computer system to be designed. It is about an actor achieving a goal with the computer system; it is about technology. (Reminder 13, p216)

In fact Cockburn tends not to use the term Business Use Case, sometime preferring ‘enterprise use case’. The difference between the two is scope; for a Business Use Case it is the enterprise, whereas for a System Use Case it is a computer system.

By ‘enterprise’ we may also mean a department, especially in a large organisation. So for as well as the obviously external actors like Customers, we can also consider other departments such as Finance as being outside the organisation in question.

Business Use Cases form part of the user requirements specification, and define the scope of User Acceptance Testing. It should theoretically be possible to implement Business Use Cases with a paper-based system. It should also be possible to draw out a Business Process Model containing the same information (often a Business Use Case might cover one or more of the activities in the model) but to do both is probably overkill.

System Use Cases should focus on the part of the process to be implemented by the system in question. They should normally be written at a level of detail equivalent to a detailed functional specification. In fact some of our later use cases were detailed enough for developers to work from directly, and were able to serve as technical documentation in their own right.

It may be worth defining a set of high level System Use Cases to help identify the process flow, and then decompose them into a set of more detailed ones reflecting system design. In my current project we currently have nearly 200 use cases; without the higher level we wouldn’t be able to see the wood for the trees.

Our client’s standard was to model business processes using BPMN, rendering Business Use Cases superfluous, but they defined “Business” Use Cases for the part of the business process to be implemented – confusingly – by the system. So in fact at our cllient the “Business Use Cases” were actually (very) high level System Use Cases, even if they don’t call them that. So it’s not surprising that people become confused, as confusion is common.

Some questions

Do we need both? Possibly, but it’s not essential to define System Use Cases if Business Use Cases exist, nor should the absence of Business Use Cases prevent designers from writing System Use Cases.

Should coverage be comprehensive? If Business Use Cases are used, they should define the full scope of the system, at least at the highest level. There are almost certainly parts of the system, however, where System Use Cases add little value, e.g. around reporting, and needn’t be modelled.

Should both sets of use cases join up? Trying to get a fully comprehensive match between both use case models is futile, as the different perspectives of each set will provide instances where System Use Cases cut across multiple Business Use Cases, or vice versa. However, all System Use Cases should trace back to a requirement in one or more Business Use Cases

Above all, don’t worry too much about the distinction, just remember that they may be written at different levels and for different purposes. Just keep scope in mind, and you will find your level.

Categories: Work Tags: ,