Types of Requirements | Project Performance International

1 di 4

http://www.ppi-int.com/systems-engineering/types-of-requirements.php

http://www.ppi-int.com/systems-engineering/types-of-requirements.php

A. Types of Requirements
by Robert Halligan
Managing Director, Consultant and Trainer
Project Performance International
Why Should We Care About Types of Requirements?
The Types of Requirements, e.g. functional, performance, external interface, etc., are important to three roles in engineering: the
Requirements Analyst role, the Specification Writer role, and the Designer role.
For the Requirements Analyst, a close relationship exists between the types of requirements, and specific analytical techniques.
Thus, the analyst benefits from an excellent understanding of the Types of Requirements to select the most appropriate
combination of analytical techniques to address a particular requirements problem. To even communicate about requirements and
their capture and validation, relies upon a good understanding of the distinctions between different types.
For the (requirements) Specification Writer, of all the influences on good requirements specification structure, the Types of
Requirements have the greatest influence. That is not to say that there is a 1:1 relationship between Types of Requirements and
elements of structure, e.g. sections. There is not. A sound schema and understanding of Types of Requirements enables the
Specification Writer to very efficiently place each (singular, not compound) requirement in its single correct place. This
transformation of a pile of requirements in a database into a well structured, no logical disconnects, easy to use requirements
specification may even be automated.
For the Designer, many of the Types of Requirements have corresponding design process issues. In some cases, e.g. external
interface requirements and other qualities requirements, there are also corresponding, specific design management issues.
In this paper, as soundly-based schema of Types of Requirements" is presented, and the significance of each type to each of the
three roles of Requirements Analyst, Specification Writer, and Designer is described.

View larger image

State/Mode Requirements
State/mode requirements state the required states and/or modes of the item, or the required transition between one state and
another state, one mode and another mode, made in one state to mode in another state, or the response required of the system as
a direct consequence of a transition having occurred. A "state" is a condition of something required or permitted. A "mode" in
this context is a related group of functionality for a purpose, i.e. "mode of operation".
Significance to the Requirements Analyst:
To the Requirements Analyst, a States & Modes Analysis is performed early, and can contribute considerably to the capture of
missing requirements and the validation of requirements that are already there. Because States & Modes Analysis deals with "big
picture" required and permitted dynamics of the system, a States & Modes Analysis is a high return on investment analysis. The
skilful use of States and Modes by the Requirements Analyst reduces word count and increases clarity of a requirements
specification.

12/03/2015 15:45

Types of Requirements | Project Performance International

2 di 4

http://www.ppi-int.com/systems-engineering/types-of-requirements.php

Significance to the Specification Writer:

How the Specification Writer deals with states and modes in structuring a requirements specification can have a huge influence on
the effectiveness of that requirements specification. Some of the older requirements specification standards have directed very
damaging practices regarding the states and modes aspects of requirements and their specification.
Significance to the Designer:
For the Designer, states and modes requirements have a soft influence, affecting, because of their "big picture" orientation, initial
conceptualisation of solution alternatives, and subsequently feeding directly (for a given concept) into the more abstract levels of
logical design.
Functional Requirements
Functional requirements state what the system is required to do.
Significance to the Requirements Analyst:
The Requirements Analyst captures and validates functional requirements in a Functional Analysis (e.g. development of Use
Cases). Whenever the Requirements Analyst discovers a functional requirement, the Analyst immediately goes looking for the
associated required measures and values of performance. Having done so, the Analyst then iterates to Rest-of-Scenario Analysis,
looking for requirements of other types.
Significance to the Specification Writer:
For the Specification Writer, functional requirements are placed in a Functional and Performance Requirements part of the
requirements specification.
Significance to the Designer:
Consistent with a given physical (structural) concept of solution, functional requirements represent a point of departure into logical
design corresponding to that concept.
Performance Requirements
Performance requirements state how well the system is to do what it is to do. That is, performance is an attribute of function.
Significance to the Requirements Analyst:
If the Requirements Analyst finds a performance requirement without corresponding function, the Analyst has found an incomplete
requirement. The Analyst finds the corresponding function, and brings the function and performance together into a complete
statement of the requirement, now a functional and performance requirement.
Significance to the Specification Writer:
The Specification Writer keeps function and performance together structurally. The Specification Writer does not place functional
requirements in one section of a requirements specification and performance requirements in another; to do so results in
duplication or ambiguity or both. The Specification Writer prefers to express function and associated required measures and values
of performance in the one expression of the requirement; it is not one requirement to fly, and another requirement to fly at a certain
speed!
Significance to the Designer:The Designer designs to achieve required function and associated required measures and values of
performance from the first acts of initial conceptualization of solution alternatives, through to completion of design in all detail
necessary for implementation. The Designer may subject required measures and values of performance to a Performance Thread
Analysis, an iterative analysis which is used to reduce any risk arising from any possibility of failing to achieve performance, and to
optimize the use of design margins.
External Interface Requirements
External Interface requirements state the required characteristics at a point or region of connection of the system to the outside
world (e.g. location, geometry, inputs and outputs by name and specification, allocation of signals to pins etc).
Significance to the Requirements Analyst:
The Requirements Analyst captures and validates external interface requirements in a Context Analysis, and complements this
capture and validation with Rest of Scenario Analysis, Parsing Analysis, Out-of-Range Analysis, and for data-oriented systems,
Entity-Relationship-Attribute (ERA) analysis.
Significance to the Specification Writer:
The Specification Writer places requirements to "have an external interface" in a particular place in the requirements specification,
and requirements on a given external interface in another place in the requirements specification. The Specification Writer decides

12/03/2015 15:45

Types of Requirements | Project Performance International

3 di 4

http://www.ppi-int.com/systems-engineering/types-of-requirements.php

whether to specify the latter set of requirements in an Interface Requirements Specification involved by reference, or to specify the
external interface requirements entirely within the subject System Requirements Specification or Software Requirements
Specification (as applicable). In each case, the Specification Writer decides whether to organize the requirements on the interface
alphabetically by parameter, or alternatively in accordance with some "level of abstraction" model, such as the OSI 7-Layer Model.
Note that requirements on an internal interface are design requirements, and that the Specification Writer treats them accordingly.
Significance to the Designer:
What is not in external interface requirements is discretionary for the Designer, and becomes the subject of external interface
design. External interface design must be consistent between the two ends of the interface. Furthermore, in most cases, external
interface design assumes the status of requirements, when the overall design to meet requirements is baselined prior to release
into production, construction and/or acquisition. This is a unique aspect relating to external interface requirements. The Design
Manager must manage this transformation such that, at any point in time, there is a complete and accurate answer to the question
"what are the characteristics required of this interface?".
Environmental Requirements
Environmental requirements limits the effect that external environment (natural or induced) is to have on the system, and/o the
effect that the system is to have on the external enveloping environment.
Significance to the Requirements Analyst:
The Requirements Analyst captures and validates environmental requirements in Context Analysis and in Rest-of-Scenario
Analysis, conducted iteratively with Functional Analysis.
Significance to the Specification Writer:
For the Specification Writer, environmental requirements are a unit of structure in the requirements specification, with three related
concerns for a physical system:
classes of environment, if any (e.g. Storage Environment and Operational Environment)
for each class of environment, the set of environmental parameters that apply to that class; and
for each class of environment, the applicable environmental envelope(s) - set envelope(s) of ranges of environmental
parameters that apply simultaneously.
Significance to the Designer:
With respect to environmental requirements, there are no unique, generic, design process issues.
Resource Requirements
Resource requirements limit the usage or consumption by the system of an externally provided resource.
Significance to the Requirements Analyst:
The Requirements Analyst captures resource requirements in Context Analysis and in Rest-of-Scenario Analysis.
Significance to the Specification Writer:
For the Specification Writer, resource requirements correspond to a section of the requirements specification.
Significance to the Designer:
Any impedance in the supply of an externally provided resource has affect the behaviour of a system. The Designer may conduct a
Resource Coupling Analysis with respect to each externally provided resource.
Physical Requirements
Physical requirements state the required physical characteristics (properties of matter) of the system as a whole (e.g. mass,
dimension, volume, centre of gravity, surface coefficient of friction, density, etc)).
Significance to the Requirements Analyst:
The Requirements Analyst captures resource requirements in several analyses incrementally.
Significance to the Specification Writer:
For the Specification Writer, physical requirements correspond to a section of the requirements specification.
Significance to the Designer:
With respect to physical requirements, there are no unique, generic, design process issues.

12/03/2015 15:45

Types of Requirements | Project Performance International

4 di 4

http://www.ppi-int.com/systems-engineering/types-of-requirements.php

"Other Quality" Requirements

Other quality requirements state any other required quality, that is not one of the above types, nor is a design requirement.
Significance to the Requirements Analyst:
Whilst a number of analyses contribute incrementally to the capture and validation of "other quality" requirements, the
Requirements Analyst relies primarily on a Stakeholder Value Analysis to capture and validate requirements of this type.
Significance to the Specification Writer:
For the Specification Writer, "other qualities" requirements correspond to a section of the requirements specification.
Significance to the Designer:
"Other qualities" requirements are often of profound significance to the designer. A whole body of knowledge often applies
regarding engineering to achieve the quality. For example, safety engineering, reliability engineering, producability engineering, are
each disciplines in their own right. In addition, the Design Manager must ensure that the body of knowledge associated with
engineering to achieve each required "other quality" is effectively integrated with the technology disciplines involved in designing to
meet requirements of other types. This necessity leads to the widely emphasized concept of Engineering Specialty Integration.
Design Requirements
Design requirements direct the design (internals of the system), by inclusion (build it this way), or exclusion (don't build it this way).
Significance to the Requirements Analyst:
Design requirements that already exist and are already specified are identified and validated in a Design Requirements Analysis.
This sometimes usually results in a substantial reduction in the number of design requirements, many to be replaced by valid
requirements of other types.
Significance to the Specification Writer:
How the Specification Writer deals with design requirements can have a profound effect on the quality of a requirements
specification, especially if design requirements are numerous. The Specification Writer must apply sound principles in organizing
the structure of the requirements specification to incorporate design requirements.
Significance to the Designer:
For the Designer, invalid design requirements (.. and as well the solution must be ..) can cause considerable grief, forcing the
Designer to do things that no reasonable person on earth would choose to do except under direction.
However, design requirements also move the pointer of share of responsibility for the design from the Designer to the requirer, and
can therefore be used to avoid responsibility for the success of a design.

12/03/2015 15:45