Types, Levels, and Standards

The Taxonomy of Requirements

Not all requirements describe the same kind of constraint. Treating them as undifferentiated text — "here are 3,000 requirements, good luck" — is how organizations end up with gaps in coverage and redundancies they cannot find. Typing requirements is not bureaucratic overhead; it is the mechanism that ensures completeness across dimensions of concern.

Functional requirements define what the system does. Inputs, outputs, behaviors, state transitions. "The system shall transmit telemetry data at 1 Hz during nominal operations." This is a capability the system must exhibit.

Performance requirements define how well the system does it. Speed, accuracy, throughput, capacity. "The system shall process incoming telemetry packets with a latency of no more than 50 milliseconds from receipt to display update." Same function (process telemetry), but now constrained quantitatively.

Interface requirements define how the system connects to other systems, users, or environments. "The system shall accept MIL-STD-1553B data bus inputs at a word rate of 1 Mbit/s." These are contracts — both sides must conform, and a mismatch is an integration failure waiting to happen.

Environmental requirements define the conditions the system must survive. Temperature ranges, vibration profiles, humidity, altitude, electromagnetic interference. "The system shall operate without degradation in temperatures from minus 40 degrees C to plus 71 degrees C." These drive material selection, packaging, and qualification testing.

Constraint requirements define non-negotiable boundaries imposed by regulation, policy, physics, or existing infrastructure. "The system shall comply with DO-178C Level A software assurance." You do not trade constraints — you satisfy them or you redesign.

Quality requirements (also called non-functional or "-ilities") define characteristics like reliability, maintainability, availability, security, and usability. "The system shall achieve an operational availability of 0.995 or greater." These are often the hardest to verify and the most frequently written poorly.

The Hierarchy: From Stakeholder Need to Component Requirement

Requirements exist at multiple levels of abstraction, and the relationships between levels are not arbitrary — they are derivation chains that must be traceable in both directions.

Stakeholder needs are the top of the hierarchy. They express what the user, operator, buyer, or regulator requires in operational terms. "The vehicle shall protect occupants in a frontal collision at speeds up to 56 km/h." This is a need expressed in the language of the person who will use or regulate the system.

System requirements translate stakeholder needs into engineering language that constrains the whole system. "The vehicle restraint system shall limit peak chest deceleration to no more than 60g during a 56 km/h frontal barrier impact per FMVSS 208." Same need, now expressed as a measurable system-level obligation.

Subsystem requirements decompose system requirements into obligations for each architectural element. "The airbag subsystem shall deploy within 30 milliseconds of impact detection and achieve full inflation within 60 milliseconds." The restraint system requirement has been allocated to specific subsystems — airbag, seatbelt pretensioner, structural crush zone — each with its own derived requirements.

Component requirements specify what individual parts must do. "The airbag inflator shall generate between 40 and 50 liters of gas within 30 milliseconds of receiving the firing signal, at gas temperatures not exceeding 300 degrees C." This is what the component supplier builds to.

The derivation chain must work in both directions. Top-down: every stakeholder need should trace through system, subsystem, and component requirements — if it doesn't, there's a gap. Bottom-up: every component requirement should trace back to a stakeholder need — if it doesn't, either you're building something nobody asked for, or you've lost the rationale.

Expand each level of the hierarchy to follow how a single stakeholder need decomposes through system, subsystem, and component requirements. Notice that the decomposition is not just top-down splitting — it involves engineering analysis at each level to derive appropriate thresholds and allocations. The descriptions note which requirement types appear at each level and the derivation logic that connects them.

The Standards: What They Say and What Gets Ignored

Three standards form the backbone of requirements engineering practice. Understanding what they actually prescribe — and where organizations routinely fall short — separates practitioners from checkbox-fillers.

INCOSE Guide for Writing Requirements — The most practical of the three. Provides rules for individual requirement quality (shall language, testability, singular focus) and a set of requirement quality attributes with examples. What organizations ignore: the rules about rationale and the insistence that every requirement have a defined verification method at the time of writing. Most teams defer verification method to "later," which means "never until test planning, when it's too late to fix bad requirements."

ISO/IEC/IEEE 29148 — The international standard for requirements engineering processes. Defines the lifecycle activities: stakeholder needs definition, requirements analysis, requirements specification, and requirements management. It prescribes that requirements shall be traceable in both directions and that the requirements set shall be analyzed for completeness and consistency. What organizations ignore: the analysis steps. They write requirements and manage them, but skip systematic completeness and consistency analysis. The standard says to do it; most teams don't.

IEEE 830 (now superseded by 29148 but still widely referenced) — Originally defined the content and qualities of a Software Requirements Specification (SRS). Its taxonomy of requirement types and its quality attributes (correct, unambiguous, complete, consistent, ranked, verifiable, modifiable, traceable) remain useful vocabulary. What organizations ignore: the requirement that the SRS itself be verified against stakeholder needs — i.e., that someone systematically checks that every stakeholder need has corresponding system requirements.

The pattern across all three standards is the same: the writing rules are adopted, the analysis and verification rules are ignored. This creates requirements sets that look professional but contain gaps, conflicts, and untestable obligations that surface during integration and test — the most expensive phases to discover problems.

Assessment