OVERVIEW OF THE ACTIVITY MAPPING TECHNIQUE

We initially devised and applied activity mapping as a method for analysing triggers for activities. Triggers are basically events that cause activities to happen when they happen. The main function of triggers is to remind us that something needs to happen. Triggers are important as they not only help us understand the temporal behaviour of activities but they also tell us about the potential failure modes. Further details on triggers analysis can be found in Alan Dix's HCI book.

For the purpose of vulnerability analysis, our focus is not so much on the triggers as we will assume that the activities actually happen. We are more interested in the placeholders, which tell us what do next and where we are in the process, thus acting as a prompt for the completion of the process and a potential recovery mechanism in case of failures.

Placeholders: knowing what happens next

Placeholders are crucial for ensuring that tasks are carried out effectively and in full. Placeholders may be stored in different ways:

- in peoples’ heads (remembering what to do next)

- explicitly in the environment (to-do lists, planning charts, flight strips, letter sitting on the desk)

- implicitly in the environment (is the letter open yet?)

The physical presence of placeholders denotes secure processes. If placeholders are unique, we can analyse the vulnerability of the process by asking questions such as:

• what happens to the process when an activity is done incorrectly or omitted?

• what are the potential failures?

• can the system recover from those failures?

Processes and activities

We will use the same notations for representing processes and activities as we did when analysing triggers. So processes are recorded as a series of circles or bubbles, one for each activity and each bubble names the activity and the person or persons who perform it (see figure 1). However, since our focus is no longer on triggers, we have omitted them from the representation.

Figure 1: Recording processes

We do not attempt to record all the complexities of real processes in a single diagram. Instead we use many separate diagrams, often concentrating on specific scenarios. We place activity boundaries where there is a likelihood of a delay or gap.

When we initially applied activity mapping for recording processes we found an emerging pattern of activities which we called the 4Rs: Request, Receipt, Response and Release. A typical example of a 4Rs pattern of activity is:

Request: someone sends a message (or implicitly passes an object) requiring your action

Receipt: you receive it via a communication channel

Response: you perform some necessary action

Release: you file or dispose of the things used during the process

Although we will not be specifically looking for the 4Rs,