Functional requirements define what a space system must do, while non-functional requirements define how well it must do it and the constraints within which it must operate. A spacecraft needs both. A command to enter safe mode is functional; the response time, power limit, radiation environment and reliability attached to that behaviour are non-functional constraints.
The distinction is useful because it helps teams find missing intent, assign ownership and choose verification methods. It is not a rigid law of nature. Aerospace organisations and standards use overlapping categories, and one statement can accidentally contain several kinds of obligation. The engineering goal is not perfect labelling. It is a complete, unambiguous and verifiable description of the system.
What is a functional requirement?
A functional requirement states a capability, behaviour, response or transformation required from the system. It answers a question such as: what must happen when an event occurs, what information must be produced, or what service must one element provide to another?
Examples include a flight computer accepting a valid command, a propulsion system delivering an impulse, a payload acquiring an observation and a spacecraft entering a safe configuration after detecting a fault. Good functional requirements include enough context to make the behaviour testable. The triggering condition, relevant inputs, required output and applicable operating mode may all matter.
Consider the statement, “The spacecraft shall enter safe mode following loss of attitude knowledge.” It identifies a behaviour, but it still needs careful engineering. The programme must define loss of attitude knowledge, the configuration that constitutes safe mode, exceptions during critical operations and the evidence that will demonstrate the transition.
What is a non-functional requirement?
A non-functional requirement describes a quality, performance level or constraint on a function or product. Software teams often use the term for availability, latency, security and usability. Hardware and space programmes extend the category to mass, power, geometry, environmental survival, reliability, maintainability, materials, workmanship and operational constraints.
For the safe-mode function, non-functional requirements might limit the time to begin the transition, cap power consumption in the resulting mode, require survival across a temperature range and set the probability of successful entry. These statements determine whether the function is useful in the real mission environment.
Some organisations avoid the label “non-functional” because every legitimate requirement has a function in the engineering process. They may instead classify performance, interface, environmental, physical and quality requirements separately. That approach is compatible with the same core distinction: behaviour is one part of the specification, and the conditions and constraints that make the behaviour acceptable are another.
Functional vs non-functional requirements at a glance
| Question | Functional requirement | Non-functional requirement |
|---|---|---|
| Primary concern | What the system does | How well it performs or what constrains it |
| Typical language | Detect, command, acquire, regulate, transmit | Accuracy, duration, mass, environment, availability |
| Common trigger | Event, input, state or operator action | Operating condition, limit, quality target or policy |
| Likely verification | Test, demonstration or end-to-end analysis | Test, analysis, inspection or review of design |
| Common failure | Behaviour is vague or missing a condition | Target is subjective, incomplete or unmeasurable |
A useful specification connects the two. A functional statement without performance limits can allow a useless implementation. A performance target without a clear behaviour can leave reviewers unsure what is being measured.
What other types of requirements appear in space projects?
Flow Engineering's overview of requirement types in hardware projects correctly shows that the functional split is only one view. NASA and ECSS guidance also organise technical requirements around the information needed to define and realise a system. A practical taxonomy can include the following categories.
| Type | Purpose | Illustrative space-system example |
|---|---|---|
| Mission or stakeholder | Defines the outcome or externally imposed need | The mission shall provide imagery of the target region during the defined campaign |
| Functional | Defines required behaviour | The payload shall acquire an image following an accepted imaging command |
| Performance | Sets measurable quality or capacity | The imaging chain shall meet the allocated ground-sample-distance threshold |
| Interface | Coordinates physical, electrical, data or operational boundaries | The payload shall exchange time data through the defined spacecraft interface |
| Environmental | Defines exposure or survival conditions | The unit shall survive the qualification vibration environment for its mounting location |
| Physical | Constrains mass, volume, materials or geometry | The assembly shall remain within the allocated envelope and mass budget |
| Operational | Defines modes, users, maintenance or mission use | The system shall support commanded transition from standby to observation mode |
| Safety and dependability | Controls hazards, faults, reliability and availability | A single identified fault shall not cause the prohibited hazardous outcome |
| Verification | Constrains how conformity will be shown | Compliance shall be demonstrated by the approved qualification test and analysis set |
These categories overlap. An interface requirement can describe a function and a timing constraint. An environmental requirement can impose both survival and operational performance. Teams should use a taxonomy that supports reviews and ownership without forcing every statement into one artificial box.
Where do derived requirements fit?
Derived describes origin, not behaviour. A derived requirement is created from analysis, architecture, risk control or a higher-level requirement even though the source did not state the lower-level obligation directly. It can be functional or non-functional.
Suppose a mission requires continuous communications during a critical operation. Link analysis, geometry and fault analysis may derive antenna coverage, transmit power, pointing and redundancy requirements. Those lower-level statements need traceability back to the analyses and decisions that produced them. Without that rationale, a later engineer may treat a necessary system constraint as an arbitrary local preference.
Derived requirements deserve explicit review because they can introduce cost and risk that the customer never wrote down. The team should preserve the source model, assumption, trade or hazard control, identify the owner and confirm that the allocation collectively satisfies the higher-level need.
How do interface requirements differ?
Interface requirements define what two elements must agree at a boundary. They may address mechanical attachment, connectors, voltage, timing, messages, thermal conductance, fluids, fields of view or operational responsibility. Each side can implement different internal designs while honouring the same controlled contract.
An interface statement should identify the boundary and direction clearly. “The payload shall receive 28 V power” is incomplete if voltage tolerance, transients, grounding, connector pins, current limits and operating modes are left to different assumptions. Some of those details may live in a controlled interface definition rather than one sentence, but the requirements record should make the authority and version visible.
Interfaces also expose why a simple hierarchy is not enough. The payload power constraint may derive from a spacecraft budget while also constraining avionics, harness and thermal design. Typed cross-links help teams see that shared impact.
How should functional and non-functional requirements be written?
Start with intent and verification. Identify the responsible system, required outcome, conditions and measurable criterion. Use defined terms and units. Keep separate obligations atomic when they can fail or change independently. Record rationale outside the normative sentence so the requirement stays concise while the decision remains understandable.
The ISO/IEC/IEEE 29148 standard covers requirements-engineering processes and characteristics of good requirements. ECSS provides a dedicated technical requirements specification standard for space projects. A programme should apply the standards in its contract and assurance framework rather than copy a generic wording formula without context.
A strong review asks whether the statement is necessary, correct, feasible, unambiguous, singular, traceable and verifiable. It also asks whether the set is complete and consistent. One excellent requirement cannot compensate for a missing operating mode or an unresolved interface.
A worked example: a small Earth-observation spacecraft
Imagine a small spacecraft that must capture an image and make it available to the ground. The mission need is an observable outcome. It decomposes into functions for accepting a target, scheduling an acquisition, pointing, exposing the detector, processing data, storing the product and downlinking it.
Each function gains non-functional constraints. Pointing has accuracy and stability. Exposure has timing and signal-quality limits. Storage has capacity and retention. Downlink has throughput, availability and link-margin constraints. The spacecraft has mass, power, thermal and radiation limits that apply across several functions.
The architecture then creates interfaces and derived requirements. The payload needs time and attitude data from avionics. The power subsystem must support an imaging load profile. Thermal analysis may constrain imaging duration. Ground operations may restrict when commands are accepted. A complete requirements model shows these dependencies instead of placing every sentence in an isolated list.
How are the different requirement types verified?
Verification follows the claim. A discrete behaviour may be demonstrated through functional or end-to-end test. Performance can require calibrated test and analysis across conditions. Physical constraints can use inspection and measurement. Environmental survival may combine qualification test, analysis and similarity evidence. Interface compliance can require inspection, electrical test, data exchange and integrated demonstration.
Method labels alone are not enough. The team needs acceptance criteria, configuration, procedure, facility, result, anomalies and approval. One activity can provide evidence for several requirements, but each closure decision should explain which part of the evidence supports the applicable statement.
Verification planning often reveals poor decomposition. If a sentence requires three unrelated methods or could pass one obligation while failing another, split it. If no credible method can show the claim, either the requirement is unclear or the programme lacks a necessary verification capability.
What mistakes should teams avoid?
- Writing functions without conditions, outputs or failure behaviour.
- Using subjective qualities such as fast, lightweight or robust without measurable criteria.
- Combining several independently changeable obligations in one statement.
- Treating a design choice as a stakeholder need without preserving its rationale.
- Leaving derived and interface requirements disconnected from sources and owners.
- Assigning a verification method without defining acceptable evidence.
- Using classification as a substitute for checking completeness and consistency.
How Arc manages different requirement types
Arc lets space teams configure requirement types, attributes and lifecycle states around their programme. Functional, performance, interface, environmental and other statements can stay connected to stakeholder sources, architecture, budgets, changes, tests and evidence.
Typed relationships show derivation, allocation, satisfaction and verification without flattening them into generic links. Engineers can review a proposed change in a branch, inspect the affected network and merge it into the controlled baseline after approval. The taxonomy stays useful because it is connected to the work.
Related reading
Continue with requirements management for space teams, then use Arc's requirements traceability matrix guide to connect each requirement type to its source and verification evidence.
Frequently asked questions
What is a functional requirement?
A functional requirement states a capability, behaviour or transformation that a system must perform. It describes what the system does under defined conditions, such as acquiring an image, commanding an actuator or entering a safe state.
What is a non-functional requirement?
A non-functional requirement constrains how well, where or under what limits a system performs. In hardware programmes this commonly includes performance, mass, power, environmental, reliability, safety, security, physical and maintainability constraints.
What is the difference between functional and non-functional requirements?
Functional requirements describe required behaviour. Non-functional requirements describe qualities and constraints on that behaviour or on the system as a whole. Both need measurable conditions and a credible verification method.
What are examples of hardware requirements?
Examples include deploying a solar array after separation, producing a specified torque, limiting peak power, surviving a defined vibration environment, fitting an allocated envelope and exchanging data through an agreed electrical interface.
Can one requirement be both functional and non-functional?
A sentence can mix behaviour and performance, but it is usually easier to review and verify when distinct obligations are separated. Classification helps organise the work; it does not replace the need for clear, atomic and testable statements.