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.
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:
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:
Catalog of requirement patterns
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. |
