Chapter 3: Requirement Pattern Concepts


3.1 Introduction to Requirement Patterns

In all but trivial systems you'll have requirements that are similar in nature to one another or that crop up in most systems-and probably lots of them. For example, you might have a number of inquiry functions, each with its own requirement. When specifying a business system, a significant proportion of the requirements fall into a relatively small number of types. It's worthwhile to make an effort to specify all the requirements of one type in a consistent manner. To do this, we introduce the notion of a requirement pattern, to allow us to describe how each requirement that uses it should be defined.

Requirement pattern: an approach to specifying a particular type of requirement.

A requirement pattern is applied at the level of an individual requirement, to guide the specifying of a single requirement at a time. For example, if you have a requirement for a certain report, you can engage the report requirement pattern to help you specify it. Once you've written the requirement (and any extra requirements it suggests), the pattern's job is done, and you can put it away and move on. But when a software designer or developer comes to decide how to implement the requirement, the pattern is available to give them some hints relevant to their job, if they wish. A tester can similarly use the pattern for ideas on how to test it.

What are the benefits of using requirement patterns? First, they provide guidance: suggesting the information to include, giving advice, warning of common pitfalls, and suggesting other matters you ought to consider. Second, they save time: you don't have to write each requirement from scratch, because the pattern gives you a suitable starting point, a foundation to build on. Third, patterns promote consistency across requirements of the same type. Of these, guidance is of the greatest value. Saving specification time and increasing consistency are nice, but sound guidance that leads to much better requirements can avoid immense trouble and work later on.

The guidance provided by a requirement pattern usually goes deeper than just "say this." It can give background insight into the problem at hand. It can raise questions you ought to ask yourself. In some cases it can lead you to write a requirement (or several) very different from the one you first envisaged. Answering a big question often raises a number of smaller questions. A requirement pattern is a response to a big question and aims to give both the big answer and the smaller questions.

Some requirement patterns either demand or invite the specification of extra requirements: both follow-on requirements that expand on the original requirement, and systemwide pervasive requirements to support the pattern itself (for instance, for an underlying feature needed by all requirements of this type). It is therefore useful to be aware of which patterns you have used (perhaps by keeping a simple list), so you can run through them asking yourself whether each one needs its own extra supporting requirements and whether you have defined them. This topic is explained in more detail in the "Extra Requirements" section later in this chapter.

Patterns can vary in their level of detail (their preciseness) and their value. Some types of requirements can be defined in great detail, and instances of them vary little. Others have something worthwhile in common but vary to such an extent that we can't prescribe what they ought to say. These variations are natural. To justify itself, a pattern simply needs to be of value; it doesn't have to do everything a pattern could possibly do. On the other hand, just because we encounter a particular type of requirement repeatedly does not mean a pattern for it would automatically have value. If it's hard to encapsulate what the requirements have in common, it's hard to provide guidance on how to specify requirements of this type.

Where do requirement patterns come from? This book defines patterns for a range of common types of requirements, which can be used as they stand. Other patterns may become publicly available in due course. Or you can write your own-see the "Writing New Requirement Patterns" section in Chapter 4, "Using and Producing Requirement Patterns," for guidance. You can also modify existing patterns to suit your own preferences and circumstances.

image from book
Pattern Ecosystems

"Each pattern describes a problem which occurs over and over again in our environment." So says Christopher Alexander, the godfather of the technical use of patterns (as quoted by Gamma, Helm, Johnson, and Vlissides, 1995). In a complex environment, there are many niches for patterns to fill, within which different species of patterns can live together harmoniously.

Individual requirements reside low down in the food chain. Designs live high up the food chain, feeding on the requirements (or, in their absence, on whatever unhealthy carrion they can find). In information technology, different species of patterns can coexist at various scales-big or small-and on both sides of the problem/solution divide. They all have their place: it just depends on what you seek guidance about.

Requirement-related patterns have been suggested at the large scale-for sets of requirements (by Robertson and Robertson, 2006) and requirements for a whole system (by Ferdinandi, 2002). Conceptually, both of these levels are valid.

Martin Fowler's analysis patterns are worth mentioning, too. They live on the other side of the fence from requirement patterns, in the design domain next door. Each one serves to guide the solution of a specific application problem. Analysis patterns are one step higher in the food chain than requirement patterns, and design patterns can feed upon them in turn. (Martin Fowler's analysis patterns can be found at http://www.martinfowler.com or in his book [1996].) Tony Morgan presents a few handy business rule patterns in his Business Rules and Information Systems (2002). (A reminder: see "References" at the back of this book for details on the publications mentioned.)

Patterns to apply at the level of individual requirements are especially useful because of the atomic nature of requirements. That is, requirements have a lot more in common with one another than aspects of design do. This is not to say that requirement patterns are in any way better than design patterns-certainly not. It merely means that they are easier to apply because we're always applying requirement patterns to requirement objects that are conveniently self-contained. Also, choosing a requirement pattern delivers a concrete requirement instance to use as our starting point.

Because various species of patterns coexist, this book uses the term "requirement pattern" throughout, rather than just "pattern." For the same reason, it's a good idea to always explicitly qualify the word "pattern" with the sort of pattern you're talking about.

image from book




Microsoft Press - Software Requirement Patterns
Software Requirement Patterns (Best Practices)
ISBN: 0735623988
EAN: 2147483647
Year: 2007
Pages: 110

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net