Previous Table of Contents Next


4.3. HOW TO DO IT

Start from the rich picture. You may have to return to some of your informants to check on details. Like the rich picture, the WOD should stand on its own and will only need minimal supportive text. You will need to create a WOD for each user role. The following instructions may be used. As with the rich picture you will probably need to prepare “before” and “after” WODs, though sometimes the objectives will remain the same even though the processes have changed.

A.  A work objective describes a state of the world the user would like to achieve. Examine the steps taken by the user and ask yourself why each step is carried out, i.e., what is the objective of that part of the work. Make a list of these “states of the world”.
B.  Next organize the list into objectives and subobjectives. The top level objectives will probably correspond to the processes identified in the rich picture. A subobjective is an objective that has to be achieved in order to achieve a top-level objective.
C.  Examine the hierarchy for objectives not in your original list. It may be useful to decompose some of the subobjectives into sub-subobjectives but avoid deep hierarchical structures. You will often only need to go to subobjectives, it should not be necessary to go further than sub-subobjectives. Also, you can be quite selective in how deeply a top-level objective is decomposed. Those that are to be supported by the computer system will be decomposed in some detail, while those that are not will not. Notice that the objectives given above are still fairly abstract and stop short of specifying how the system will work.
D.  Number the objectives for reference. Note this does not imply they have to be carried out in a specific order. There is no need to consider the order in which things are “normally” done or the logical constraints on the order in which objectives have to be achieved at this stage. Indeed we would advise against thinking about this at all at this stage as it may impede creative solutions at the design stage.

Some developers with a mathematical training may find the above process arbitrary and informal. It is. The WOD is not a formal notation and the method specified above will result in different representations when it is applied by different people. This is not a problem. Design is a creative craft and this analysis is a part of that creative process. The representations described here are better thought of as artists materials than engineering tools. The representations make it possible for the developer to create something new and useful by taking a new view on an old problem.

5. PROBLEMS AND INTERRUPTIONS — THE EXCEPTIONS LIST

5.1. WHAT IT IS FOR

The WOD is an idealized view of the task. It needs to be supplemented by what might go wrong, the exceptions list. Application exceptions are things that can go wrong for the system; user exceptions are things that can go wrong for the user. Engineers are used to anticipating application exceptions, such as power failure or the system being unable to recognize a password. They are less used to thinking about user exceptions.

User exceptions are usefully categorized as interruptions and problems/mistakes. An example of an interruption in the cup of tea example would be “being called away while the tea was mashing”. Interruptions imply the need to save work. If this problem were serious one might think of some way of automatically removing the tea bag and keeping the tea warm. Problems/mistakes imply the need to undo something. Adding sugar when it was not wanted would be an example of a mistake, though it is difficult to see how this could be undone.

5.2. WHAT IT LOOKS LIKE

Table 5.5 is the exceptions list for the warehouse case study. All the exceptions listed were mentioned as being disruptive to the flow of work by the operatives questioned. Most particularly, the current system did not allow the operator to save the work if interrupted while entering the details from a delivery note. This commonly happened when they were working on a delivery note of goods for the ambient storage and then a delivery for the cold storage arrived and began to defrost on the unloading bay. Naturally, the cold storage took precedence in such a situation and the former work was abandoned and hence lost.

Table 5.5 Exceptions List for the Warehouse Example
Application exceptions
          Queries from DMS in 2
          Invalid Gate House Record No., Supplier details or Product in 1.1
          Printer off-line at 1.1.5., 1.2.2, or 3
User exception — interruptions
          Interrupted in 1 to do 1.1 or 1.2 for more urgent new delivery
          Wait for warehouse man to return with new count in 1.2.1
User exceptions — problems/mistakes
          Allocation by hand in 2
          Notice error in data during 1.1.2 to 1.1.4
          Quantities changed during 1.2.1
          Repeat printing of Tally Cards at any point
          Repeat printing of COD at any point
          Repeat printing of Picking notes at any point


Previous Table of Contents Next