4.2 Tailoring Requirement Patterns

The phrasing of individual requirements is to a large extent a matter of personal preference-their author's own writing style-which we don't want to suppress unduly because it can help to enliven otherwise turgid technical documents. Phrasing also needs to suit the organization's culture, such as the appropriate degree of formality in speech. And, as always, speaking the customer's language is of overriding importance in a requirements specification. For all these reasons, the language used in the templates in requirement patterns should accord with the language used in the rest of any requirements specification that use those patterns. Sudden changes in style will strike readers as odd and make them feel uncomfortable. At worst it can be obvious that some of the specification's language comes from outside the organization, which can damage the author's credibility.

In a non-English-speaking country, a software designer who speaks English can perfectly well use a design pattern expressed in English. In the same environment, however, a requirement pattern wholly in English is acceptable only if requirements specifications are being written in English. If this isn't the case, at least the templates in the requirement patterns should be translated into the local language.

You can also refine requirement patterns based on your experience with them in your organization. Some insightful organizations take a little time to reflect on how well a just-finished project ran, to find ways of doing better in future. (This is usually called a postmortem, but I prefer to call it a "postnatal," because it's more hopeful to imply it happens after the birth of the system, rather than its death.) If any problems arose as a result of badly written requirements, you could refine any patterns that were used by adding advice to guard against that problem. If no pattern was associated with a troublesome requirement, you could consider writing one, even if it's just as a vehicle for a small piece of advice. If a pattern itself was a cause of trouble, correct it so that it won't be again.

For these reasons there's a greater need to tailor requirement patterns than design patterns. So be prepared to (and don't be scared to) do this tailoring. The fundamentals of the pattern remain the same; tailoring merely tweaks the bits that appear in requirements created using the pattern. Sometimes only the requirement definition templates need to be changed (because they're the only part that ends up in actual requirements), but then modify the examples too to reflect the changes to the templates. Also check the rest of the pattern for consistency with the modified templates, and adjust it as necessary.

Each time we tailor a requirement pattern we create a new manifestation of it. In this context we can take the term "manifestation" to mean one instance of a pattern tailored to suit a particular environment and approach. (We can't use the term "version" because each manifestation could have its own history and thus go through several versions.) In some organizations, this means that multiple manifestations of requirement patterns might be needed. If so, make sure the right ones are used for each project. Add an explanation to each one indicating which manifestation it is and when it should be used. In practice, this should be a straightforward matter if done from the moment a second manifestation of any pattern is created.