Observing Structures and Patterns

Structures and patterns are useful when you find a situation where the work is complex, with a probability of overlapping and similar tasks being done. This trawling technique aims to simplify the work, so it has less relevance for smaller projects. The benefits of structure/pattern observation are long term, so don't attempt it if your deadline is very tight.

Now is when you observe and interpret. By seeing the users at work over a period of time, you can determine an abstract structure or a pattern to the work.

The structure is a framework for the user to do his task for the normal cases, although it also supports improvisation to handle the exceptions. The structure is most likely invisible to the userpeople usually do not consciously note the necessary abstraction and think in terms of work structure.

You are also looking for which skills people use and how they see themselves when they do the work. Which conceptualizations and metaphors do they use?

Once you have observed the structure, look for patterns. Does this structure match, or almost match, another structure? Is there a pattern to the work that recurs elsewhere in the enterprise? The objective is to find similarities that can yield common requirements.

Look for similarities, not differences.

For example, one of our clients, the international section of a bank in London, had 20 different products. The products ranged from letters of credit, to guaranteed foreign bank loans, to guaranteed funds, among others. At first glance, the users appeared to handle each of these products differently. However, a common pattern emerged as we studied the structure of the workwe were looking for similarities, not differences. We observed that each product was, in fact, a different way of guaranteeing that exporters got paid for their goods in foreign countries. The end result: We found a common set of requirements and were able to make a single core implementation, which we could then dress differently for each of the products. In some cases, this different window dressing involved little more than changing a few words and icons on screens.

We suggest building abstract models of the work structurethat is, models that are abstract in the sense that they do not give specific technological names to things or use distinctive terminology that belongs to one part of the organization. Abstract models should not name any particular user or use terminology identified with a particular user. These models are made remote from their sourcethey use categorizations rather than specifics. Instead of modeling the work the way any single user sees it, they model the class of work as all users could see it.

This kind of abstraction enables you to discover whether the same pattern exists in another part of the organization. It has been our experience that although the names and the artifacts may vary, the same work pattern occurs several times in an organization. We have used the recurrence of patterns first to understand the requirements more quickly, and then to deploy the implementation of one part of the work to suit another part.

See Chapter 13, Reusing Requirements, for more on patterns.