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.