3.3 Domains

There is much to be gained by organizing our requirement patterns rather than presenting a monolithic list of them. We do this by assigning every requirement pattern to a domain. Each domain has a theme, which all its patterns share, but the nature of the theme can vary greatly from one domain to another. The domains used in this book-each with its own chapter in Part II, "Requirement Pattern Catalog"-are Fundamental, for things that any kind of system might need; Information, for several aspects of the storage and manipulation of information (data); Data entity, on how to treat specific kinds of data; User function, for a couple of common types of functions, plus accessibility; Performance; Flexibility; Access control; and Commercial, for business-oriented matters. This shouldn't be regarded as a definitive list: new domains might be needed if further requirement patterns are written. For example, if requirement patterns were to be written for a particular industry, they would deserve their own domain (or possibly more than one). The applicability of a domain can range from very broad to very narrow: from nearly all systems, through systems in one industry, to just a couple of systems in a single company.

When you begin specifying a system, you can look through all the requirement pattern domains (in this book, plus any extras you have from elsewhere) and decide which ones are relevant to your system. If it's a noncommercial system, you might decide to drop the Commercial domain. The set of requirement patterns that are available for use in your system depends on the domains you decide are relevant. Regard only the patterns in your chosen domains as available. Conversely, if you want to use some other pattern, it can force you to add a domain you hadn't previously recognized, which can alert you to extra topics you need to address (such as an infrastructure it depends upon). Identifying the available patterns is more useful if you have patterns in specialized domains; the patterns in this book are too general for drawing up a list of relevant domains to make much of a difference.

Each domain needs an introduction to explain its theme. It can then describe features that are common to all its patterns. The size of an introduction could be anywhere from one short paragraph to many pages; it depends solely on how much there is to say. The domain also needs to describe any infrastructure(s) its patterns depend upon (or, more properly, the requirements produced by these patterns), as discussed in the next section.

Domains and Infrastructures

Some types of requirements depend upon infrastructures, as discussed in the "Infrastructures" section of Chapter 2, "The Contents of a Requirements Specification." A requirement pattern gives us the opportunity to identify any infrastructure(s) its type of requirement depends upon, which saves having to figure them out for individual requirements. We can go further and discuss each infrastructure-things to bear in mind when you specify requirements for the infrastructures your system needs. It's not possible to go into detail or specify actual requirements because they will vary considerably according to the demands of each organization and each system. They're called infrastructure overviews to make this clear.

Rather than expect that each requirement pattern describes any infrastructure it needs, we pass the burden of explanation up to the domain the pattern belongs to. This is because each infrastructure tends to be needed by more than one pattern in the domain. To avoid repetition, each type of infrastructure is described in only one domain. Each chapter of patterns in this book contains a subsection for each infrastructure in its domain. This book discusses three infrastructures: information storage (in Chapter 7, "Data Entity Requirement Patterns"), user interface, and reporting (both in Chapter 8, "User Interface Requirement Patterns"). The key concepts relate to each other as shown in Figure 3-2.

image from book
Figure 3-2: Relationships between domains, requirement patterns, and infrastructures

A requirement pattern is free to use infrastructures in other domains. It's always good practice to avoid mutual dependencies, so if anything in one domain depends on another domain, nothing in the latter domain should depend on the former-that is, if you can avoid it. An infrastructure can also depend upon another infrastructure.

What should such an infrastructure overview say? Its role is to give guidance and advice to someone who's going to specify requirements for an infrastructure of this kind for a particular system, to suggest topics for requirements to cover. At a minimum, it should state what a calling system expects from the infrastructure: what it's there for, and its main functions. For problems for which there are obvious alternative solutions, the overview should avoid making judgments.

Each infrastructure overview is divided into the following subsections:

Purpose An explanation of why the infrastructure exists, the role it plays.
Invocation requirements Suggestions for sorts of requirements that define how a system will interact with the infrastructure-for those functions that the infrastructure must make available to a system-plus any other capabilities systems might want from it (such as access control). The needed functions can be regarded collectively as the interface (or interfaces) the infrastructure needs to make available to callers.
Implementation requirements Some ideas on the other features the infrastructure needs in order to stand on its own feet (for example, inquiry, maintenance and configuration functions). These are brief and merely hint at the likely main areas of functionality to think about when defining the infrastructure itself.

For example, for a reporting infrastructure, our invocation requirements might be very simple: just a function that lets our system request the running of a chosen report. The implementation requirements, on the other hand, would be far more extensive, addressing the complexities of various ways of delivering a report to a user, other ways of requesting reports, designing reports, and so on. (These topics are discussed further in the "Reporting Infrastructure" section in Chapter 8.) To take the analogy of building a house, one of the infrastructures we'd want is an electricity supply. In this case, the invocation requirements would cover how many sockets we want in each room, and the implementation requirements would deal with the parts you can't see, such as the connection to the power grid and adherence to building quality regulations.