Pattern 3: Establish the use cases
AKA: ESTABLISH THE USE CASE AND OBJECT MODELS; UNDERSTAND USERS’ TASKS FIRST;
TASK-CENTRED INFORMATION ARCHITECTURE.

You have constructed a BUSINESS PROCESS MODEL (2) consisting of agents and conversations. This was linked to the prioritized business objectives established earlier in the workshop: ESTABLISH THE BUSINESS OBJECTIVES (1).

The site must serve at least one significant business purpose. For this reason we must look at all the use cases that we can predict users will want to execute.

Therefore

Extract the use cases from the conversations in the BUSINESS PROCESS MODEL (2). Record their correspondences to the business objectives. Write post-conditions for each use case. Compare the vocabulary of the post-conditions to the type model. Write use cases in stimulus–response form. Convert the use cases into the user training manual and the test plan. Develop CONTEXT-SENSITIVE HELP (17) from them. One stimulus/response pair from the use case should correspond to one step in the workflow if the site deals with workflows. If not, do not constrain the user’s ability to perform steps in any particular sequence. Ensure that you extract and document a business object type model from the use case goals.

You must now CLASSIFY YOUR SITE (11). One reason is to establish whether it must enforce workflows. Use a SITE MAP (12) and for workflow sites CONTEXT-SENSITIVE HELP (17) to help the user complete use cases accordingly to the constraints set by the organization and the needs of the user. Use the use cases as the basis to AUTOMATE TESTING (6).

This is another process pattern of sweeping generality often ignored by web developers.

It is widely believed that establishing users’ tasks and responsibilities is a prerequisite for building any useful computer system. The vulgar term for this is use case analysis. Other people talk of task analysis or usage-centred design. Sometimes we need to organize these tasks into a workflow ... BUT ... task-centric interfaces constrain the freedom of users and inhibit their creative use of sites. How do we balance these forces?

During the construction of the business process model, we got people to tell stories and produce storyboards. Now we focus on the stories that concern people interacting directly with the site: users, maintenance staff, content managers, and so on.
How will users for example, react to our forcing them to complete MANDATORY FIELDS (71); will they regard them as intrusive attacks on their privacy or an unnecessary waste of their valuable time and phone bill? How will they cope with a disabled BACK BUTTON (35) should we decide to disable it? More generally, how do we assure the user of a successful completion to her tasks in terms of navigating to required content or completing a workflow transaction?

An answer to these questions is only possible if you really understand who your users are and how they might interact with the site. The most common way to gain such understanding is to identify the actors (users adopting a rôle) that use the sites and the tasks they wish to carry out: the use cases. This is not a tutorial on UML or object-oriented analysis but we will pause to give a brief description of the technique. For a fuller tutorial see any of (Graham, 2001; Cockburn, 2000; Fowler, 1997) there is an extensive tutorial based on Graham’s work at www.trireme.com.

Use case modelling
The technique starts with the ‘business use cases’ discovered using BUSINESS PROCESS MODEL (2). We now focus on the system boundary and the actors that will use the site. For each of these we enumerate and document the use cases. There are several possible styles of doing this.

Many people fill in templates, often based on those of Cockburn. Richard Dué (private communication) recommends using a stimulus–response format. We think that a use case is best specified by writing pre- and post-conditions using a minimalist template having roughly the following form.

1. Name and description
2. Actor(s)
3. Component use cases (if any)
4. Pre-conditions
5. Post-condition (goal)
6. Recoverable exception use cases
7. Fatal exception use cases
8. Comments

Note that we include non-functional requirements in the goal, so that it is possible to state: ‘the user has submitted a valid order and received confirmation in less than n seconds’. As an example consider a web-based postal lending library.

There will be a use case named Borrow whose goal might be written:
The MEMBER has been identified and a loan recorded for a BOOK.
The same book has been dispatched to the member within 8 hours and the book is no longer in stock.

This example shows that the use case goals provide the vocabulary for discussing the problem domain. Nouns (caps) suggest object types and verbs (in italics) suggest associations and operations. Nothing is said about how the goal is accomplished at this stage. We must now go on to specify an object model that provides and ontology for the site .

Object modelling
This is not the place for an exegesis on object modelling even though it is an essential prerequisite to using the further patterns in this language. The technique summarized above has its origins in Catalysis (D’Souza and Wills, 1999) and is summarized in (Graham, 2001). For a tutorial on building use case and object models specifically in the context of web design see (Cato, 2001).

Cato seems to regard building the use cases and building the object model as separate patterns. We think these activities are too inextricably linked to do this. Thus the first alternative name given above for this pattern.

Establishing as many use cases as possible lets you think rationally about subsequent design decisions that you will make. If the priorities are carried over from the business process model, they will turn into a valuable tool for managing projects using TIMEBOXES (4). They also form a sound and invaluable basis for the testing patterns that we will meet later.

Known uses
Use case modelling is a well-established technique for systems development and is part of most mainstream methods for object-oriented and component based development. This applies equally to object modelling using UML as a notation.

Browse the language	What is Wu?	Look at an example pattern sequence	Structure of the patterns
Comment on Wu	Contributors	Return to TriReme home page	Links to related sites