Requirements Patterns

A pattern is a guide. It gives you a form to follow when you are trying to replicate, or make a close approximation of, some piece of work. For example, the stonecutters working on classical buildings used wooden patterns to help them to carve the column capitals to a uniform shape. The tailor uses patterns to cut the cloth so that each jacket is the same basic form, with minor adjustments made to compensate for an individual client's body shape.

But what about patterns in a requirements sense? Patterns imply a collection of requirements that make up some logical grouping of functions. For example, we can think of a requirements pattern for selling a book in a shop: Determine the price; compute the tax, if any; collect the money; wrap the book; thank the customer. If this is a successful pattern, then it pays you to use the pattern for any future bookselling activities, rather than reinvent how to sell a book.

Typically we use requirements patterns that capture the processing policy for a business use case. If we use the business use case as a unit of work, then each pattern is bounded by its own input, output, and stored data. As a consequence, we can treat it as a stand-alone mini-system.

Refer to Chapter 4, Event-Driven Use Cases, for more on the connection between business events and use cases.

Requirements patterns improve the accuracy and completeness of requirements specifications. You reduce the time needed to produce a specification because you reuse a functional grouping of requirements knowledge that has already been specified by other projects. To do so, look for patterns that may have some application in your project. Keep in mind that the pattern is usually an abstraction and you may have to do a little work to adapt it to your own needs. However, the time saved in completing the specification and the insights gained by using other people's patterns are significant.

Christopher Alexander's Patterns

The most significant collection of patternsand one that inspired the pattern movement in software designwas published in A Pattern Language, written by a group of architects headed by Christopher Alexander. The book identifies and describes patterns that contribute to functionality and convenience for everyday human life within buildings, living spaces, and communities. The book presents these patterns to architects and builders for use as guides for new building projects.

Alexander, Christopher, et al. A Pattern Language: Towns, Buildings, Construction. Oxford University Press, 1977.

The Waist High Shelf (illustrated in Figure 13.3) is the name of one of the patterns defined by Alexander and his colleagues. In this case they looked at many people, such as the authors and readers of this book, and observed what happens when we enter and leave our houses. Suppose it is time to leave for work, and you are in a hurry. You need your keys, your sunglasses, your building pass, and the book you have to return to a colleague. If these things are difficult to find, you become irritated, probably forget something, and have a bad start to the day. The Waist High Shelf pattern is based on the observation that we need somewhere to put our keys and whatever other bits and pieces we have when we arrive, so that we can easily find them again when we leave.

Figure 13.3.

Alexander defined the Waist High Shelf pattern because, as he observed, "In every house and workplace there is a daily 'traffic' of the objects which are handled most. Unless such things are immediately at hand, the flow of life is awkward, full of mistakes: things are forgotten, misplaced."

The pattern specifies there should be a horizontal surface at waist height (a convenient height to reach), located just inside the front door (you do not have to carry objects farther than necessary), and big enough for you to deposit items that are commonly transported in and out of the house. In your authors' house, the Waist High Shelf pattern implemented itself without us realizing it. We noticed that we naturally put our keys on one of the steps of the staircase that is on your right as you come through our front door. We also noticed that, without being told, our visitors also leave their keys on the "waist high step."

Note the role of the pattern. It is a guide, not a rigid set of instructions or an implementation. It can be reusedthere is no need to experiment and reinvent the pattern. It is a collection of knowledge or experience that can be adapted or used as is.

Now let us look at patterns as they apply to requirements.