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.
(Click image to view full)
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.
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 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.
“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.
