3.5 Relationships Between Requirement Patterns

When you use a requirement pattern, it generally says everything you need to know to create a requirement of that type. But a pattern might refer to other patterns for several reasons. Two fundamental types of relationship between requirement patterns exist:

Refers to A requirement pattern can mention another pattern somewhere in its definition. There are several reasons why a requirement pattern might refer to another:
1. A requirement defines something that contains (has) something else defined by another requirement.
2. A requirement that's an instance of one pattern uses information defined in requirements that are instances of a second pattern. For example, a requirement that defines a data structure might use a value of a kind defined by a data type requirement.
3. A requirement might suggest the creation of an extra requirement of a type for which a pattern is available.
4. A divertive pattern might persuade you to create a requirement using a different pattern. (See the "Divertive Requirement Patterns" section later in this chapter.)
5. A requirement pattern could refer to another pattern that contains relevant discursive information on a particular topic.
Extends A requirement pattern builds upon (or is a specialization of) another pattern. In object-oriented terms, this is an inheritance relationship. Instead of extending another pattern, a requirement pattern can build upon (extend) a requirement pattern group. (In object-oriented terms, the group acts like an abstract base class for the pattern.) A requirement pattern is not allowed to extend more than one pattern or group.

We can draw a collection of patterns and infrastructures and the relationships between them in a diagram. Figure 3-3 is an example that shows two domains, with elements of the notation annotated. Inheritance is the most important type of relationship. For simplicity, every other type of relationship is shown as "Refers to," though its role can be indicated by a label on the link. When showing several domains on one diagram, it can become impractical to show all the relationships. In such a case, show all relationships within each domain and all extends relationships, but omit refers to relationships between domains as you see fit. For readers familiar with object-oriented concepts (or UML), this is akin to a class diagram showing relationships between classes.

image from book
Figure 3-3: Annotated sample requirement pattern diagram

In Figure 3-3, "Data entity" is not a pattern. It's a requirement pattern group: a place for describing the common features of the four patterns that build on it. Any descriptive information that applies to all patterns in a group should be given for the group, rather than repeated for each pattern. Also, by convention, labels for relationships between requirement patterns are placed nearer the subject of the relationship, rather than the object. So, it is a Data entity that has an ID (rather than vice versa). The hexagonal shape of "Information storage" denotes it as an infrastructure.

See the beginning of Part II of this book for a diagram of this sort for all the requirement patterns in this book. Each of the eight domain chapters contains a diagram of this sort in its introduction, with annotations giving a brief explanation of each pattern, pattern group, and infrastructure.

Requirement Pattern Classifications

Requirements can be classified in various ways (for example, by dividing them into functional and nonfunctional ones). Using requirement patterns has the advantage that if we classify the patterns, we automatically classify the requirements that use those patterns. Classifications tell us a little about the nature of the requirements that result from using each requirement pattern.

Other ways of using these classifications include finding requirements according to their classification and producing statistics. People like statistics (some people, at least, and they tend to be senior executives it's worth our while keeping happy). Statistics on the requirements for a system can be useful in a variety of ways. They can give a rough picture of the scale and complexity of the system. To do this, we need to tag each requirement with whatever values are needed for all the sorts of statistics we want. (Requirements management tools typically do this by letting you define extra requirement "attributes." Then you enter the value of each attribute for each requirement. It's a tedious business.) Using requirement patterns can save some of this effort, because all requirements created using a pattern have attributes in common. They need be defined only once, when the pattern is written. This information is recorded in the "Pattern classifications" section of each pattern.

Once requirements are tagged in this way, it's also possible to search on the classifications to find all the requirements that match your criteria. How you transport this classification information from the patterns to your requirements depends on how you store the requirements. (This is left as an exercise for the reader!) A straightforward way is to copy the requirements into a spreadsheet, add a column identifying the requirement pattern used by each requirement (if any), and add a column for each classification. (Sorting on the pattern name makes it easier to apply classification values many at a time.)

The requirement patterns in this book contain classifications according to a small number of basic classification schemes that are defined below. You can define extra classification schemes of your own and classify patterns according to them. If you do, write proper definitions in a similar manner to those below, and make them available in the same place as the requirement patterns that refer to them.

Classifications can be defined that assist anyone who uses requirements, including developers. As a result, it's not necessary for everyone to understand every classification. For this reason, each classification has its primary audience explicitly stated. If you're not part of this audience, don't worry if you can't follow what it's for or if you're not interested in it.

Requirement pattern classifications need to be properly and precisely defined, or else any statistics based on them can't be regarded as reliable. Each classification needs the following defined for it:

Name:	A self-explanatory, unique name for the classification.
Audience:	An explanation of who is likely to be most interested in this classification: who it's aimed at.
Purpose:	A description of what the classification is intended to be used for.
Allowed values:	A definition of the values that a pattern may have for this classification, and explanations of their meanings. The most common way is to define a list of individual values. Numeric or alphabetic or other kinds of values may be used, provided it's clear to the reader what each value means.
Default value:	This is the value assumed for this classification if it's not present (explicitly stated) in a pattern. This saves cluttering patterns with explicit mentions of classifications that are meaningful for relatively few patterns (that is, the few that have a significant value for it).

Open table as spreadsheet

There are three requirement pattern classifications used in this book, which we now describe using this format.

"Functional" Classification

Name:	Functional
Audience:	Anyone interested in picking out the functionality of the system, or the number of functions.
Purpose:	This indicates whether a requirement of this type defines a function that must be provided by the system.
Allowed values:	Yes	Every requirement of this type is a functional requirement.
	Maybe	Some requirements of this type are functional requirements; some are not. If you're writing a pattern, use this value with care. Ask yourself whether your pattern is well-defined; perhaps it ought to be split into two, one for the functional part and one for the nonfunctional.
	No	No requirement of this type is itself a functional requirement.
Default value:	No

Open table as spreadsheet

"Pervasive" Classification

Name:	Pervasive
Audience:	Software developers
Purpose:	This indicates whether a requirement of this type is pervasive (that is, applies systemwide). Its intent is to bring to the attention of developers requirements that may apply to them no matter which part of the system they're developing.
Allowed values:	Yes	Every requirement of this type is pervasive.
	Maybe	Some requirements of this type are pervasive; some are not.
	No	No requirement of this type is pervasive.
Default value:	No

Open table as spreadsheet

"Affects Database" Classification

Name:	Affects database
Audience:	Database administrator (and software developers, too)
Purpose:	This indicates whether a requirement of this type has an impact on the design of the system's database. Its intent is to highlight those requirements that are of most interest to whoever is responsible for designing the database.
Allowed values:	Yes	Every requirement of this type affects the database.
	Maybe	Some requirements of this type affect the database; some do not.
	No	No requirement of this type itself directly affects the database (though this doesn't necessarily mean a database administrator will have no interest in it).
Default value:	Maybe

Open table as spreadsheet

Refinement Requirements

It is good practice to keep the size of each requirement's definition within moderate bounds; one that runs to ten paragraphs is way too long. A requirement pattern may identify several pieces of information, although a typical requirement of its type might possess only one or two. From time to time you might have a requirement that possesses more and, as a result, is unreasonably large. In this situation, it makes sense to split the requirement into two or more requirements.

The way to do this is to retain the initial requirement but to cut out parts and make them into additional requirements, which are refinements of the main requirement. Each refinement requirement should specify one extra aspect. And each refinement should identify the requirement it builds on. For readability, the main requirement should be immediately followed in the specification by its refinements. This practice makes sense whether or not you're using a requirement pattern-but when you are, you can regard the pattern as applying to both the main requirement and the refinements. If a requirement pattern suggests that several pieces of information be present, this is satisfied if all are present in one of the requirements or another. A second reason for splitting a requirement is if different parts of it have different priorities.

Depending on the nature of the system you're specifying, up to a quarter of all requirements could be refinements of other requirements. If you use a very fine level of requirements granularity, you'll increase the number of requirements and with it the percentage of requirements that are refinements.

Divertive Requirement Patterns

Usually when you apply a requirement pattern, the result is a requirement that matches what you asked for. However, a pattern could be sneakier than this: it could try to lead you away from the obvious and towards an alternative, better way of formulating what you want. It explains the difficulties that the obvious way causes (usually for developers), and it provides advice on how to avoid these problems by using requirements that are stated in different terms but that aim to achieve the same underlying aim. A divertive requirement pattern can either explain the alternative itself or it can divert you to a different requirement pattern entirely-or both.

Requirement patterns can be much more valuable than just saying, "If you want to require X, this is what to write…." They can be like having an expert sitting at your shoulder saying, "Hang on! If you specify it like that, you're asking for trouble. Let me explain. Why don't you try this instead?" Several of the performance patterns are divertive, because the most obvious ways to specify performance are often a nightmare to satisfy. (For example, "The system shall be available 24×7" gives developers little idea of what they must do to achieve it.)

Requirement Patterns and Diversity of Approaches

There's no single right or best way of formulating or expressing requirements. For a given system, there's no single perfect set of requirements to define it. Different requirements approaches might break down a problem in different ways, resulting in requirements that vary in their level of granularity and the way they're expressed. The term "requirements approach" as used in this section simply means a way of going about the specifying of requirements in general or certain types of requirements in particular. Each approach could have its own set of requirement patterns. They might simply be the approach's own distinct manifestations of recognized standard patterns, or they might be patterns specific to the approach.

We can accommodate a diversity of requirements approaches-to let the proponents of each approach create whatever requirement patterns they wish, including their own manifestations of existing patterns. And by recognizing different approaches explicitly, we make the available choices clearer to analysts.

Nevertheless, the greater agreement there is on standard patterns (and the fewer different manifestations of patterns), the better. It's perhaps a testament to the excellence of the choices for design patterns made by Gamma et al. that there's been no apparent call for variants (although lots of extras have appeared), and thus accommodating diverse sets hasn't been necessary. In allowing for multiple requirements approaches, I'm heading off potential criticism of the requirement patterns given here. I can cite it as proof that there's no single "right" set of requirement patterns. If anyone doesn't like them, they can devise their own alternatives without demanding to replace the ones here. There's room for many schools of thought.

To avoid potential confusion, don't mix material for multiple requirements approaches in the same requirement pattern. It is clearer to have multiple manifestations of the pattern and to pick only one to use on your system.

When creating a new pattern (or manifestation of an existing pattern) for a particular requirements approach, state the approach it relates to in the "Manifestation" section of the pattern. Note that when a manifestation is created for a different approach, it takes on a life of its own and might go through a succession of versions independent of the manifestation for the original "standard" approach.

Where two sets of requirement patterns exist that cover the same ground, there are two ways they can be organized:

One domain specification can contain both sets of requirement patterns. (A "domain specification" is a document, or part of a document, that contains its requirement patterns and a section about each of its infrastructures. Each of the eight domain chapters that follows is a domain specification.)
There can be two manifestations of the domain specification, each containing one set of the requirement patterns.

The second way is easier and less confusing to use (and thus less liable to have an analyst apply the wrong manifestation of a pattern). The second way also allows each manifestation of the infrastructure specification to be tailored to the methodology its patterns use, which is useful if the infrastructure's own requirements use these patterns (which they might).

Use Cases for Requirement Patterns

It is perfectly possible to write use cases for some requirement patterns, those that result in requirements that demand the presence of a well-defined function (or, indeed, more than one function). For example, for the inquiry requirement pattern we could write a use case that shows the steps in a typical inquiry. Use cases for requirement patterns are always generalizations, an official UML concept that means they are written to apply in any circumstance that fits, using an "is-a-kind-of" relationship.

One requirement pattern might demand the presence of more than one function for each of the resulting requirement. For example, the configuration requirement pattern implies the presence of create, read (inquire), update, and delete functions (commonly called CRUD) for each item of configuration data. We can write a use case for each of these functions, and four use cases will suffice for all configuration, rather than attempting to write four for each type of configuration (or, more likely, writing use cases for a few but not the rest).

It makes sense to write requirement pattern use cases to suit your particular environment. To attempt to write universally applicable use cases risks them being so high-level as to be of no practical value. For example, a universal "create configuration data" use case has little to say-perhaps just an actor entering the data and the system storing it in a data store. But if we have a browser-based user interface with remote users and a Web server that is outside our system's scope, the use cases will look very different. Also, the use cases' preconditions might insist the actor be logged in and authorized to access this type of configuration data-to satisfy particular security requirements. (All this illustrates how hard it is to write detailed use cases without bringing in elements of the solution, even though use cases are meant to reflect only the problem to be solved.) No use cases have been written for the requirement patterns in this book.

Business Rules and Requirement Patterns

A business rule is a definition of one aspect of how a business operates. For example, a business rule could define how a particular business should act in a given situation (such as when a customer credit card payment is rejected) or a constraint (such as a policy of not selling to anyone under sixteen). A business rules approach to building systems recognizes the importance of business rules, with a view to making it easier to understand and change how the business works. In an ideal world, you'd be able to modify your business rules and all affected systems would instantly jump in line. It's a very attractive prospect. There exist business rules products to help you do this. They act a bit like a guru who knows your business inside-out and of whom you can ask questions, but there's a lot more to it than that. That's not to say you need a specialized product to adopt a business rules approach. Two places to go for more information are http://www.brcommunity.com and http://www.businessrulesgroup.org.

Quite a few types of requirements reflect business rules, including several covered by requirement patterns in this book. So why not say which ones they are? The trouble is that there isn't a single agreed-upon set of business rule types. There are many, and it would be arbitrary to pick one. (The same argument applies when you consider mentioning in an individual requirement how it maps to a business rule.) One could create a requirement pattern classification for a selected business rule scheme to indicate how each pattern relates to a business rule. My excuse for not doing so in this book is not wishing to offend any scheme I left out.

It's also worth pointing out that adopting a particular business rule classification scheme might not happen until after the requirements have been written. Consider the case where you invite tenders from three prospective suppliers. The first might use one business rules scheme. The second might use a different one. And the third might not think in business rules terms at all.

Nevertheless, if your organization has made a commitment to using a particular business rule scheme, you can write requirements in a way that's friendly to that scheme (and, if you wish, mention the type of business rule that each requirement reflects, where applicable). If you're committed to using a business rule product, you can treat it as an infrastructure that your system must interface to. Then, just like for any infrastructure, you can specify requirements for what you need from it, and use those requirements as your basis for choosing the most suitable product.