Indescribable Qualities
The inclusion of the word "pattern" in the phrase is a purposeful reference to Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1995) by Erich Gamma et al., the ible of the design patterns movement in software development. The purpose of design patterns is to capture software design know-how and make it reusable. Design patterns provide a powerful way to describe useful architectural configurations, building on the collective experience of skilled designers and software engineers. Patterns capture these solutions in an approachable form that describes problems, contexts and examples to which they apply. Although there are stylistic variations, the most popular pattern format (practically canonized by use in the Design Patterns book) describes the structure of a pattern in terms of its intent, synonymous names ("also known as"), motivation, applicability, consequences and example implementations.
Design patterns are rooted in architect Christopher Alexander's work, especially his book, A Timeless Way of Building, (Oxford University Press, 1979.) A Timeless Way of Building eloquently reveals that, in architecture, timeless structures exist that have fundamentally indescribable qualities. These qualities work to draw people in for reasons they can't explain. As these qualities are indescribable, the best we can do is extract formational patterns found in these structures and describe them in some meaningful way in the hope that we can reproduce the qualities.
The requirement patterns presented here are derived from this spirit. The quality, in this instance, is not necessarily the ability to draw people in (though that would be a nice side effect). Rather, it's the ability to restrict ambiguity in the problem space while simultaneously introducing latitude into the solution.
The following subset of requirement patterns represents the most prevalent and well-defined requirement patterns. I have successfully used each of the patterns on at least four separate requirement specifications. Each of the specifications addressed different problem domains, yet the requirement patterns helped to speed the specification process in all four instances.
Capturing the Spirit
I have successfully used each of these patterns on at least four separate requirement specifications. Each specification addressed different problem domains, yet the requirement patterns helped to speed the specification process in all four instances. After I delivered each specification, I interviewed each of the consumers of my specification. Usually, these interviews are painful for requirement engineers. More often than not, the consumers of a specification miss the intent of a passage, misunderstand a passage or, worst of all, never read a passage. In this case, the consumers were the first to comment that the requirement patterns eased their consumption of my specifications. Furthermore, the subsequent design documents generated from my specifications captured the spirit of the user's need without my intervention. In other words, my specification made me obsolete.
