A requirement is defined as "a condition or capability to which a system must conform".
There are many different kinds of requirements. One way of categorizing them is described as the FURPS+ model [GRA92], using the acronym FURPS to describe the major categories of requirements
with subcategories as shown below.
The "+" in FURPS+ reminds you to include such requirements as:
(See also [IEEE Std 610.12.1990].)
Such categories and examples of nonfunctional requirements can be used like a checklist, to ask yourself if you have a
requirement in a particular category. But how do you come up with a complete set of candidate
non-functional requirements? Some other sources include:
-
For a description of a systematic approach to capturing requirements according using FURPS+, see the
The Rational Edge article 'Capturing Architectural Requirements' by Peter
Eeles (http://www.ibm.com/developerworks/rational/library/4706.html).
It provides a questionnaire that lists a large number of nonfunctional requirements, along with questions for
determining their applicability
-
The Software Engineering Institute has also created a catalog of 'general scenarios' - expressions of quality
attribute requirements – which can be reused across many different kinds of systems to define quality
requirements. For more information, see http://www.sei.cmu.edu/publications/documents/01.reports/01tr014.html or Software
Architecture in Practice, 2nd Ed., by Len
Bass, Paul Clements, and Rick Kazman (Addison-Wesley, 2003).
Functional requirements specify actions that a system must be able to perform, without taking physical
constraints into consideration. These are often best described in a Use-Case Model and in use
cases. Functional requirements thus specify the input and output behavior of a system.
Requirements that are not functional, such as the ones listed below, are sometimes called non-functional
requirements. Many requirements are non-functional, and describe only attributes of the system or attributes of the
system environment. Nonfunctional requirements are those that address issues such as those described
below.
Functional requirements may include:
-
feature sets
-
capabilities
-
security
Usability requirements may include such subcategories as:
-
human factors
-
aesthetics
-
consistency in the user interface
-
online and context-sensitive help
-
wizards and agents
-
user documentation
-
training materials
Reliability requirements to be considered are:
-
frequency and severity of failure
-
recoverability
-
predictability
-
accuracy
-
mean time between failure (MTBF)
A performance requirement imposes conditions on functional requirements. For example, for a given action, it may
specify performance parameters for the following:
-
speed
-
efficiency
-
availability
-
accuracy
-
throughput
-
response time
-
recovery time
-
resource usage
Supportability requirements may include:
-
testability
-
extensibility
-
adaptability
-
maintainability
-
compatibility
-
configurability
-
serviceability
-
installability
-
localizability (internationalization)
A design requirement, often called a design constraint, specifies or constrains the design of a system.
An implementation requirement specifies or constrains the coding or construction of a system. Examples are:
-
required standards
-
implementation languages
-
policies for database integrity
-
resource limits
-
operation environments
An interface requirement specifies:
-
an external item with which a system must interact
-
constraints on formats, timings, or other factors used by such an interaction
A physical requirement specifies a physical characteristic that a system must possess; for example,
-
material
-
shape
-
size
-
weight
This type of requirement can be used to represent hardware requirements, such as the physical network configurations
required.
|