Types of Requirements in Engineering: A Complete Guide

Between June 1985 and January 1987, six known accidents involved massive radiation overdoses from the Therac-25, a computer-controlled radiation therapy machine. Its predecessor, the Therac-20, carried independent protective circuits and mechanical interlocks, and the Therac-25 relied more on software for those same functions. The March 1983 safety analysis stated that residual software errors were not included in it, as Nancy Leveson and Clark Turner record in their 1993 investigation of the accidents.

When the safety function moved from hardware into software, the requirement behind it became a software safety requirement, and the analysis still set software aside. Requirement type is the field that decides what evidence a requirement owes. A functional requirement owes a test, a constraint owes a verification method of its own, and a safety requirement owes an integrity level it inherits from the hazard behind it. Leave the type implicit in a folder name and none of that can be assigned, inherited, or checked.

This guide covers how ISO/IEC/IEEE 29148 organises requirement levels, what separates functional, non-functional, interface and derived requirements in practice, and how each type maps to a verification method. Classifying a requirement by where it sits and what it constrains is the move every scheme below has in common, and the labels still vary by program.

How Standards Organize the Types of Requirements

Requirements sort first by level of abstraction, then by category. Standard ISO/IEC/IEEE 29148:2018 draws those abstraction levels as business needs, user needs, system requirements, and software requirements. The standard is issued jointly by the International Organization for Standardization (ISO), the International Electrotechnical Commission (IEC), and the Institute of Electrical and Electronics Engineers (IEEE). The Business Requirements Specification (BRS) contains the program’s purpose and scope, including its mission goals. The user requirements specification (StRS) covers intended interaction with the operational environment. Developers use the System Requirements Specification (SyRS) for the technical view, and the Software Requirements Specification (SRS) covers software behavior allocated from system requirements.

High-level requirements break into functional and performance requirements, get allocated, and are decomposed again. The SyRS outline runs to fifteen requirement sub-clauses, and five of them appear nowhere else in the standard, namely system modes and states, physical characteristics, environmental conditions, information management, and policy and regulation. Allocation and decomposition continue down the system, subsystem, and component hierarchy, and teams validate each derived set against its parent before the next level starts. The types of requirements a program recognises are fixed at this point, because every later label hangs off the level it was written at.

Functional, Performance, and Constraint Requirements

Three categories divide most of what a program writes down. Functional requirements hold system behavior, performance requirements hold the measurable conditions on that behavior, and constraints establish bounds that can’t be traded against cost, schedule, or performance. NASA’s Thrust Vector Controller (TVC) example combines a functional requirement to provide vehicle control about the pitch and yaw axes with a performance requirement to gimbal the engine a maximum of 9 degrees, +/- 0.1 degree. A constraint on the same component would cap its mass, and the cap is not tradeable against the other two.

Performance requirements can be especially prone to authoring defects. They have to state how well, and under what conditions, a function is performed, and each has to be quantitative and verifiable on its own, wording from ISO/IEC/IEEE 29148. “The system shall respond quickly” fails that test. An automatic emergency braking requirement reading “the system shall initiate full braking force within 200 milliseconds of detecting a pedestrian in the vehicle’s forward path” passes, because a test engineer can derive a threshold from it.

Cost, schedule, technical, legal, ethical and safety constraints are the entity constraints the International Council on Systems Engineering (INCOSE) Guide to Writing Requirements names. A mass cap of that kind is a binding design constraint, and marking it as one tells reviewers to reject a design that exceeds it, and bars trading the cap away for cost or schedule.

A reader weighing only the first two of those families against each other will find the side-by-side treatment on the functional vs non-functional requirements page. Both belong in the longer list of types a program has to record, because what each type owes in verification evidence is what the rest of the taxonomy turns on.

Non-Functional Requirements and the Quality Attributes Behind Them

Non-functional requirements hold the qualities a system has to have, and engineers also call them quality attributes or “-ilities.” Common non-functional requirement categories include availability, reliability, maintainability, safety, and security. Software quality characteristics have their own standard, ISO/IEC 25010, and its 2023 revision adds safety as an explicit characteristic, with subcharacteristics for operational constraint, risk identification, fail safe, hazard warning and safe integration. Each attribute needs a measurable form before anyone can verify it. “The device must have an uptime of 99.9% over a one-year period, with no more than 5 minutes of downtime per month” can be demonstrated. “The interface should be intuitive” cannot, and the fix is a threshold such as new users performing basic operations within 30 minutes of training.

Interface, Environmental, and Operational Requirements

Conditions around a function belong in interface, environmental, and operational requirements, and each pins down a different kind of condition. Interface errors are a recurring integration problem:

• Interface requirements: Define the requirements and constraints at a common boundary between two or more systems or elements. The correct form names your own system as the subject, as in “My system shall receive a 28-volt electrical supply from the xyz system per Interface Control Document (ICD) 1234 table 2.”
• Environmental requirements: Specify the allowable range of conditions such as temperature and humidity across development, transport, storage, and operations. Ariane 5 Flight 501 was lost to what the inquiry board called specification and design errors in the inertial reference software, reused from Ariane 4. A conversion was left unprotected because the analysis behind it assumed Ariane 4’s flight profile, on a launcher that built horizontal velocity roughly five times faster.
• Operational and support requirements: Cover safety, reliability, human factors, logistics, maintainability, operability, and supportability. A maintainability requirement typically reads “The mean time to restore system (MTTRS) following a system failure shall not be greater than [X].”

Out-of-date or incomplete interface documentation is how two teams end up building to different versions of the same boundary, and integration testing is where that surfaces. Engineers therefore establish an ICD early in the life cycle to control the detailed interface.

Derived and Allocated Requirements Across the Hierarchy

A derived requirement is one nobody wrote down at the level above, arising from a constraint, from something implied but not stated in higher-level direction, or from an architecture or design choice. Allocation is the other half of the move, assigning a requirement at one level of the physical architecture to the entities at the next lower level that implement it. DO-178C treats the category as a certification concern. A derived requirement there is one that is not directly traceable to a higher-level source, and it goes to the safety assessment process to be assessed. The safety process treats high-level requirements originating in safety assessment as derived, assigns the safety attribute, and reviews them independently.

When a parent changes, the derived child and the test built to it keep their old wording until somebody notices at integration. Nothing in the requirement text carries that dependency, so the parent-child relationship has to be recorded as data rather than inferred from where the requirement sits in a folder.

Safety and Cybersecurity Requirements by Industry

Derived requirements are where the generic taxonomy runs out, because a safety-critical program has to know how much rigor a derived requirement inherits and from what. Regulated industries add safety requirement types on top of the generic taxonomy, and each ties the requirement to a hazard analysis and an integrity level. The hierarchy and rigor classification vary by standard, as the table shows.

Standard	Requirement hierarchy	Rigor classification
ISO 26262 (automotive functional safety)	Safety goals from Hazard Analysis and Risk Assessment (HARA), then functional, technical, and software safety requirements	Automotive Safety Integrity Level (ASIL) A through D from severity, exposure, and controllability, with Quality Management (QM) below A
DO-178C (airborne software) and DO-254 (airborne electronic hardware)	System requirements, then High-Level Requirements (HLRs), then Low-Level Requirements (LLRs) under DO-178C, with derived requirements possible at each level, and DO-254 carrying its own definition for hardware	Development assurance levels A through E from the system safety assessment in ARP4754A, which ARP4754B superseded on 20 December 2023 though most active civil programs still work to the A revision. The function carries a functional development assurance level and the hardware or software item carries an item development assurance level
IEC 62304 (medical device software)	System requirements, then software requirements, then architecture and detailed design, each linked to risk control measures	Software safety class A, B, or C, set by the severity of the possible injury and by whether risk controls outside the software already bring the risk to an acceptable level

Integrity levels flow down the requirement chain from the hazard that produced them. ISO 26262 assigns the ASIL determined for a hazardous event to the corresponding safety goal, and the technical safety requirements refined from a functional safety requirement carry its level.

A software safety class can be lowered only by risk control measures external to the software system, and IEC 62304 names those in its own note as hardware, an independent software system, or health care procedures. Cybersecurity requirements inherit the same way, and ISO/SAE 21434 derives cybersecurity goals from a Threat Analysis and Risk Assessment (TARA), then carries those goals into cybersecurity specifications that are implemented and verified during product development. The U.S. Food and Drug Administration (FDA) issued medical device cybersecurity guidance on June 27, 2025, and Section 524B of the Federal Food, Drug, and Cosmetic Act (FD&C Act) requires a postmarket cybersecurity monitoring plan in the same submission.

Matching Verification Methods to Requirement Types

Requirement type is what decides the verification method, and the mapping between types of requirements and methods holds fairly steady across the major standards. Verification itself is proof of compliance with requirements, determined by test, analysis, demonstration, inspection or a combination, the definition NASA carries in NPR 7123.1D. A verification method is a requirement attribute, and NASA’s handbook says it should be determined as the requirements are developed. The requirements-validation step then asks whether every requirement is verifiable before the baseline is set, which is the test the Systems Engineering Body of Knowledge (SEBoK) also applies at authoring time. The pairings below are the ones the major standards converge on:

• Functional requirements: Requirements-based testing, the primary strategy in DO-178C, with unit tests derived from requirements under ISO 26262.
• Performance and interface requirements: Performance tests and interface tests, both in the software test methods ISO 26262 recommends.
• Safety requirements: Model-, software-, and hardware-in-the-loop simulation plus fault injection, with rigor scaling to the integrity level, up to Modified Condition/Decision Coverage at DO-178C Level A.
• Non-functional requirements: Analysis, such as NASA’s thermal, stress, fracture control, and materials analyses, and constraints typically take the same route.

Verification assignments live in the Verification Cross-Reference Matrix (VCRM), a table of the verification method for each requirement. Completing every verification event recorded in the VCRM verifies the requirement.

How Jama Connect Supports Types of Requirements

In Jama Connect®, a Traceability Information Model (TIM) defines which downstream items each requirement type has to carry, and the software flags the ones that are missing, so a business-level need and the low-level requirement derived from it sit on one path. Recording the type is what makes that check possible, because a constraint and a functional requirement owe different evidence, and the model can only enforce a difference it can see. Impact analysis then shows which downstream items a parent change affects before the change is made. Integrity-level inheritance stays a process decision, and Jama Connect contributes the trace path from hazard analysis to verification result.

Jama Connect Advisor™ scores each requirement against INCOSE rules and Easy Approach to Requirements Syntax (EARS) notation and catches the “respond quickly” defect. It also drafts test cases for an engineer to review, regenerate, and accept instead of applying them automatically. Jama Connect Advisor runs on Jama Connect Cloud, and is unavailable on self-hosted installations and on GovCloud.

Recording Requirement Type as Data Before the Next Program Starts

If your team is still inferring a requirement’s type from the folder it was filed in, make it an explicit field before the next program starts. The work moves earlier, to the point where a mislabeled requirement costs five minutes to correct, long before it becomes a verification event nobody scheduled.

Jama Connect supports this workflow by storing requirement type as structured data, so verification methods, integrity levels, and trace links attach to a field the system can act on, and Arteris IP reports that the platform cut its requirements review cycle time by 30% and audit-preparation cycle time by 75%. If your team rebuilds that structure by hand for every program, you can start a free 30-day trial using your own requirement set.

Frequently Asked Questions About Types of Requirements

How many types of requirements are there?

One widely used scheme has three top-level types, functional requirements, quality requirements, and constraints, with everything else a subcategory, which is where the functional and non-functional split sits. The International Requirements Engineering Board (IREB) syllabus uses that scheme. NASA technical requirement types run to functional, performance, interface, environmental, safety, human interface, standards, and the “-ilities.” Teams are better served picking one scheme per program and using the same labels everywhere, since the quality guidance during writing does not change with the scheme and consistent labels are what let a Traceability Information Model check the set automatically.

Is a constraint a type of requirement?

Constraints are requirements, and IREB defines a constraint as a requirement that limits the design options available beyond what functional and quality requirements demand. Systems Modeling Language (SysML) models it as a named requirement subclass, “design constraint.” Constraints should still be mapped to a verification method like any other requirement, and treating them as background assumptions is how a mass budget gets exceeded without a failed verification on record.

How do user stories relate to formal requirements in regulated programs?

A requirement is a formal description of need, while a user story is an informal description of a feature. “As a train passenger, I want to be informed of delays in real-time so that I can plan my trip accordingly” is the story, and “Display the estimated delay times of each train” is the requirement it becomes. ISO 13485, IEC 62304, DO-178C, ISO 26262, and Automotive SPICE (ASPICE) impose traceability obligations however the need was captured. A story has to be formalized as a requirement with explicit acceptance criteria and verification evidence before it counts, which is the discipline agile work in a regulated program carries.

This article was authored by Mario Maldari and published on October 1, 2026.