Chapter 4: Using and Producing Requirement Patterns

The previous chapter gave us a tour of the machinery of requirement patterns; now let's bring them to life. The first section in this chapter invites you to sit in the driver's seat and see how patterns can help you reach your destination. In the second section we start to get our hands dirty, to let you tune patterns so that you can get the most out of them in your environment. The third section dives into the heavy engineering of building entirely new patterns.

4.1 When and How to Use Requirement Patterns

Whatever gets you to the light 'salright, 'salright
Out the blue or out of sight 'salright, 'salright
-John Lennon

This section concentrates more on when to use requirement patterns than how, because each pattern should be its own guide on how to use it. Familiarize yourself with the patterns available to you, and then exploit them as you see fit.

Requirement patterns are first and foremost to help define what a new system needs to do. They can be used even if you're an agilist who's not writing formal requirements-in which case a requirement pattern can act directly on your thinking rather than through an intermediate step, the requirement. There are two occasions during the specifying of a system in which requirement patterns can be used:

1. When defining a requirement, see if a pattern for it exists to guide the specifying of that requirement. The pattern can then provide detailed suggestions on what to say, and how, what else to worry about, and extra topics to consider. Once you've decided to engage a pattern, read through the whole of it (or become familiar with everything it says, so that you don't need to read it all for every requirement of this type). That is, have the pattern in front of you and do what it tells you to.

   Pay close attention to what the "Extra Requirements" section says, because it might have a profound impact on the nature or quality of the system that's needed. Even if you recognize the merit of the extra requirements the pattern suggests, you may not want to be sidetracked by tackling them immediately. That's fine: just make a note that it remains to be done. You also need to take on board each infrastructure on which the patterns you use depends: add it to the "Infrastructures" section of your requirements specification, and then make sure it is itself properly specified.

2. When considering the completeness of requirements, scan the set of patterns for topics to cover-to see if you've missed something, or to suggest something to add.

Secondarily, requirement patterns can also be used after the fact-that is, after the requirements have been written. The ease of doing this, and the effect, depends on whether patterns were used when specifying the requirements and, if so, how closely they were followed. The main ways of using patterns after the requirements have been written are

3. When reviewing a requirements specification, a pattern can help you to check the quality of specific requirements, to identify topics that have not been specified, and to understand the meaning and implications of particular requirements.

4. When estimating the scale of a system and the effort needed to build it, based on its requirements, you can use patterns to get a better feel for the implementation complexity.

   If you have records from which you can tell how long particular features took to implement in previous projects, you can calculate the effort needed to implement an average requirement of a particular type-that is, metrics you can attach to each pattern, which would allow quick estimation of the effort for all requirements for which patterns were used. Effort figures are not available for the patterns in this book, and even if they were, they would need recalibrating to suit each organization's environment.

5. When implementing a requirement, a pattern can give you a deeper understanding of its intent. The "Considerations for Development" section of the pattern is aimed squarely at the designers and developers of the software. It contains hints on how to approach implementation and suggests things to bear in mind.

6. When testing a requirement, the "Considerations for Testing" section, which is written specifically for software testers, serves to suggest approaches to testing this kind of requirement.

If we look at a requirement, how can we tell if a pattern was used when it was written? In one sense we don't need to: after a pattern has been applied, the requirement stands on its own feet. But it's useful to know, because it lets readers know that the pattern is there to assist after the fact (points 3–6 above). There are three ways to indicate use of a pattern. First, the requirement summary can reveal it, if the summary matches a form for a particular pattern. Second, you could add a little note at the end of the requirement definition, something like "(This requirement uses the «Pattern name» pattern.)" Third, if you're using a requirements management tool, you could store the name of the pattern as an attribute behind the scenes.

Using requirement patterns has several benefits:

• Requirements are easier to read-because a lot more thought can be put into producing a pattern than you can afford to spend on any single requirement.

• Requirements are easier to compare with others of the same type-because they are similarly structured.

• You can tell if something is missing-because comparison of the requirement against the pattern indicates if something in the pattern is missing in the requirement.

• Requirements are easier to write-because you have a checklist of topics to think about. This is of greatest help to inexperienced analysts.

• Readers can be referred to the written pattern for more information-about why the requirement is formulated as it is and for explanations of what each part of the requirement means.

• You can refer to a list of patterns when writing your requirements specification-to check whether there are any types of requirements you should specify but that you've forgotten about.

The benefits of requirement patterns greatly outweigh the reasons for not using them-but be aware that there are a few potential drawbacks. There's a simple mantra that lets you sidestep them all: don't be lazy. Beware of the following:

• You might be lulled into not thinking enough-because if you apply a pattern mechanically, especially if you copy in text from a template and fill in the blanks, you might not put your mind fully into gear.

• You might misapply a pattern-if you use it in inappropriate circumstances. To guard against this, make sure you properly understand each pattern you use (especially the situations in which it's suitable), and make sure that any requirement you apply a pattern to fits the circumstances.

• Lots of requirements might be worded similarly-your readers will get bored more quickly and might have less faith in what you are saying, both because they fear a lot has been copied in and may not have been properly tailored in all cases, and because you have obviously not written everything from scratch. Introduce a bit of variety into your requirements, to make reading them a little more interesting and to let your readers know you put some thought into them-and that they're not a big copy-and-paste exercise.

You won't find a pattern for every requirement. A high proportion of requirements (perhaps a majority) don't have a neat pattern that can be applied to them. Our intent in using patterns is to reduce the amount of work and do a better job wherever we can, not to apply them to everything. The proportion of requirements covered by the patterns described in this book varies considerably from system to system and could be anywhere from 15 to 65 percent. (A self-contained business system would be at the high end of that range. The less a system fits that stereotype, the lower the percentage of the requirements for which these patterns apply.) These figures come from study of real-world requirements specifications. We could write more and more patterns to cover more types of requirements, but we'd quickly reach the point where diminishing returns render it not worthwhile. A substantial system will always have many requirements that will need to be written from scratch.

For certain types of requirements, it's tempting to group them together in their own section in the requirements specification (for instance, a section for all of a system's reports). This has some advantages, such as reducing the chances of duplication (for example, specifying the same report twice in different sections), but on the whole it's preferable to keep all requirements for each functional area together. A functional area often has a constituency of users, and it's easier for these users to read the specification if every function they need is described in their section. If necessary, one section can refer to a requirement for a function that is defined in another section.