Overview of Requirement Patterns

First a word on requirements in general. The requirements for a software system define what it must do, but not how. Requirements define the problem; the design and implementation of the system represent the solution. The process of identifying what a system does is always undertaken one way or another, regardless of whether you recognize it—which means that requirement patterns can be usefully employed even if you don't actually write formal requirements. Nevertheless, I believe that differentiating the problem from the solution is good discipline, and that stating the problem explicitly is the only way of creating a benchmark against which to gauge the quality (and suitability) of the solution, or to compare the merits of alternative solutions.

Many types of requirements crop up again and again, no matter what a particular new system is for. The idea of requirement patterns is to provide guidance on how to specify common types of requirements, to make it quicker and easier to write them, and to improve the quality of those requirements. A requirement pattern is applied at the level of an individual requirement: to explain how to write a requirement of that type. The anatomy of a requirement pattern contains various kinds of information to help both the writer of a requirement and developers and testers. A requirement pattern can also suggest additional topics for which to write requirements. You can download a sample requirement pattern, for scalability, from here.

The "Software Requirement Patterns" book contains 37 requirements patterns, which together can account for well over half of all requirements for typical commercial systems. These patterns are shown in the diagram below, organized into eight domains:

Pattern catalog diagram
Catalog of requirement patterns

A Polish translation of this diagram can be viewed here.

The following table describes the circumstances in which to apply each of the 37 requirement patterns (their "applicability"):

Requirement pattern name Use this requirement pattern ...
Fundamental

Inter-system interface
to specify basic details for an interface between the system being specified and any external system or component with which it needs to interact.
Inter-system interaction
to specify a particular type of interaction across an inter-system interface.
Technology
to specify technology that must (or must not) be used to build or run the system, or with which the system must be capable of interacting or otherwise compatible.
Comply-with-standard
to specify that the system must comply with a particular standard.
Refer-to-requirements
to specify that some or all requirements in an external requirements specification must be satisfied as if those requirements were present in the current specification.
Documentation
to specify that a particular type of documentation needs to be produced.
Information

Data type
to define how a particular atomic item of information (a single field) for a particular business purpose is to be represented and/or displayed, or specify how a standard data type is always to be displayed (for example, all dates).
Data structure
to define a compound data item (one that comprises multiple individual pieces of information) that occurs in more than one place or that contains too much to define neatly in one requirement.
ID
to define a scheme for assigning unique identifiers for some type of entity or to indicate that a data item (or combination of data items) can be used as a unique identifier.
Calculation formula
to specify how to calculate a particular kind of value, or how to determine a value via a process of logical steps.
Data longevity
to specify for how long a certain type of information must be retained or for how long it must be available with a given degree of ease.
Data archiving
to specify the moving or copying of data from one place of permanent storage to another.
Data entity

Living entity
to define a type of entity for which information is stored and which has a lifespan (that is, is created, can be modified any number of times, and eventually terminated).
Transaction
to define a type of event in the life of a living entity, and/or a function for entering such a transaction.
Configuration
to define parameter values that control how the system behaves.
Chronicle
to specify that a certain type or range of types of event (occurrence) in the life of the system must be recorded.
User function

Inquiry
to define a screen display function that shows specified information to the user.
Report
to define a report that shows specified information to the user.
Accessibility
to specify the extent to which the system (or part of it) must be accessible by people with a certain kind of disability or other specific need—that is, how convenient it must be for them to use.
Performance

Response time
to specify how much time the system may take to respond to a request.
Throughput
to specify a rate at which the system—or a particular inter-system interface—must be able to perform some type of input or output processing.
Dynamic capacity
to specify the quantity of a particular type of entity for which the system must be able to perform processing at the same time.
Static capacity
to specify the quantity of a particular type of entity that the system must be able to store permanently (typically in a database).
Availability
to define when the system is available to users: the system’s “normal opening times” (which could be “open all hours”) plus how dependably the system (or a part of the system) is available when it should be.
Flexibility

Scalability
to specify a way in which a system must be able to expand without undue pain, typically to accommodate growth in business volume.
Extendability
to mandate that a specific aspect of the system be built to make it easy to extend by “plugging in” extra software.
Unparochialness
specify a particular way in which the system must not be limited to one business environment.
Multiness
to specify that the system must accommodate multiple something-or-others at the same time, each of which has its own fundamentally distinct user interface or whose data must be kept rigorously apart from that of the others.
Multi-lingual
to specify that the system is capable of displaying its user interface in more than one alternative natural language (for at least one class of user, though not necessarily all).
Installability
to specify how easy it must be to install or upgrade the system (or a part of the system).
Access control

User registration
to specify how new users are registered (set up in the system), with emphasis on capturing those details by which a user can later be authenticated (log in).
User authentication
to specify that a person must make their identity known to the system before they can access anything non-public or anything for which they cannot remain anonymous (in short, anything for which they must log in).
User authorization

Specific authorization
to specify that a set of users is authorized (or is not authorized) to do or see certain things.
Configurable authorization
to specify that the definition of which users can do what is to be configurable (that is, can be changed dynamically).
Approval
to specify that a particular action (or set of actions) must be approved (or, in some circumstances approved) by a second person before it takes place.
Commercial

Multi-organization unit
to specify a type of organizational construct that the system must be able to support, whether that be units of a specific type or a more complex structure (such as a hierarchy).
Fee/tax
to specify any fee or tax the system must calculate, report on, or levy.