What Is Allocating Requirements?

A system-level requirement says the aircraft shall descend from cruise altitude to approach altitude within four minutes under maximum certified weight. That statement belongs to the aircraft. No single subsystem — not the flight control computer, not the engine control unit, not the hydraulic actuators — can independently satisfy it. Someone has to decide which piece of that four-minute window belongs to which element, under what conditions, with what margin. That process is requirements allocation.

Allocation is the systems engineering activity of distributing system-level requirements down to the subsystems, components, hardware elements, and software modules that together produce system behavior. The output of allocation is a set of derived requirements: statements assigned to specific elements that, when satisfied simultaneously, guarantee the parent requirement is met. Allocation does not happen once. It recurses through every level of the system hierarchy until you reach an element small enough to verify independently.

This article defines what allocation is, why it differs from the adjacent concept of decomposition, why allocation decisions are inherently architectural, and how misallocation produces the integration failures that kill schedule and cost. The second half covers how modern tooling — specifically graph-based platforms — makes allocation visible and traceable in a way that document-based approaches cannot.

Allocation vs. Decomposition: A Distinction That Matters

Engineers use these words interchangeably in hallway conversations. They are not the same thing.

Decomposition is structural. It breaks a system into its constituent parts: the aircraft has a propulsion system, an avionics suite, a structural airframe, a fuel system. Decomposition produces a hierarchy — a Work Breakdown Structure, a system architecture block diagram, a product tree. It answers the question: what are the parts?

Allocation is functional. It assigns requirements — performance obligations, behavioral constraints, interface budgets — to the elements identified through decomposition. It answers the question: who is responsible for what?

You can decompose without allocating. If you build a product tree and never assign requirements to its leaves, you have a picture of structure with no assignment of accountability. The integration team will discover this problem when no one can answer whether the thermal budget for the avionics bay has been satisfied, because no one was ever formally responsible for it.

Allocation also involves distributing budgets: mass, power, latency, reliability, electromagnetic interference margins. A top-level reliability requirement of 10⁻⁹ probability of failure per flight hour for a safety-critical function must be allocated across redundant channels and components such that the mathematical combination of their failure rates satisfies the top-level figure. This is not decomposition. It is apportionment — a specific form of allocation that requires engineering judgment and quantitative analysis.

Why Allocation Decisions Are Architectural Decisions

The moment you assign a latency budget to a specific ECU in an automotive drivetrain, you have constrained the processor architecture of that ECU. The moment you allocate a weight budget to the landing gear actuation subsystem, you have constrained material choices across that entire element. Allocation sets the design space before design begins.

This is why allocation decisions belong in systems engineering — not component engineering, not software architecture, not manufacturing — and why they must be made deliberately rather than by default.

Aerospace Example: Fly-By-Wire Control Latency

Consider a fly-by-wire aircraft with a system-level requirement: pilot control input shall produce a control surface response within 80 milliseconds. The systems engineer must allocate that 80 ms across the signal chain: pilot input transducer digitization, flight control computer processing, data bus transmission, actuator control electronics processing, and electro-hydraulic actuator mechanical response. Each allocation is a constraint on a downstream component. If the data bus standard already has a fixed frame rate — say, MIL-STD-1553 at 1 ms per minor frame — that consumes a known slice of the budget before the software team writes a single line of code. Allocating the remaining budget incorrectly — giving the flight control computer 30 ms when the actuator electronics physically require 25 ms just for their interrupt service routine — means the system cannot be built to satisfy the parent requirement. That failure surfaces at integration, not at component qualification.

Automotive Example: ADAS Decision Latency

An ISO 26262 ASIL-D autonomous emergency braking function carries a system-level requirement: the vehicle shall initiate braking within 150 ms of a confirmed obstacle detection. Allocation distributes that window across sensor fusion processing, the brake control module arbitration logic, the hydraulic pressure buildup time, and the communication latency on the CAN-FD backbone. The decision about whether sensor fusion lives in a central compute domain or at the sensor node is not just a software architecture choice — it is an allocation decision that determines how much latency budget remains for the brake actuation path. Engineers who treat it as a purely architectural choice without tying it to the allocation chain routinely discover at vehicle-level integration that the total latency does not close.

The allocation decision is the architecture decision. They are the same choice expressed in two vocabularies.

How Misallocation Produces Integration Failures

Misallocation takes three forms, and each produces a different failure mode.

Over-allocation assigns more stringent requirements than necessary to a component, driving cost and complexity into elements that do not need it. The power supply is designed to ±0.1% regulation when the load circuit could tolerate ±2%. This wastes engineering effort and often introduces manufacturing risk, but it does not typically cause integration failure — it causes cost overrun.

Under-allocation is the dangerous case. It leaves a gap: the sum of what has been allocated to child elements does not cover what the parent requirement demands. In a mass budget, this means the vehicle is heavier than its launch allocation. In a reliability budget, it means the failure probability of the assembled system exceeds the certified limit. Under-allocation is almost always invisible until integration, because each subsystem team is validating against its allocated requirement — which individually appears satisfied — while no one is checking whether the allocations sum correctly.

Misrouted allocation assigns a requirement to the wrong element. The timing requirement belongs to the communication middleware, but it was allocated to the application software layer. The software team satisfies its allocated requirement. The middleware behavior — which was never allocated to anyone — violates the system timing constraint. At integration, the system fails a test that no component team was responsible for preventing.

All three forms share a common cause: requirements allocation managed in disconnected documents, spreadsheets, or siloed tools with no live traceability between the parent requirement and its allocated children.

How Modern Tooling Makes Allocation Visible

Document-based requirements management treats allocation as text annotation. A requirement in a Word document or a flat DOORS module gets a “Derived From” note in a cell. The relationship exists as a string, not as a live connection. No tool can compute whether the allocations covering a given parent requirement are complete. No tool can flag that a parent requirement has no children. No tool can propagate a change in the parent’s numerical value into the child allocations automatically.

Graph-based requirements platforms change this. Because requirements and their relationships are first-class nodes and edges in a connected model, the allocation structure is queryable, analyzable, and computable.

Flow Engineering (flowengineering.com) is built specifically for this model. Each requirement in Flow Engineering exists as a node in a directed graph. Allocation relationships — parent to derived child, system need to subsystem obligation — are typed edges. This means Flow Engineering can answer questions that document tools cannot:

  • Which parent requirements have no allocated children? (Gap detection)
  • Which allocated requirements have no verification method assigned? (Coverage gap)
  • If this system-level performance value changes, which derived requirements inherit the change and which are now inconsistent? (Change impact)
  • Does the sum of allocated reliability figures across all child elements satisfy the parent’s top-level reliability requirement? (Budget closure)

The gap-flagging capability is particularly consequential. In a large aerospace program, a system with 2,000 system-level requirements may generate 15,000 or more derived requirements across subsystem and component levels. No human reviewer catches every allocation gap in a review cycle. Flow Engineering surfaces unallocated requirements as structural flags in the model — not as a report generated after the fact, but as a live condition visible during the engineering process.

Flow Engineering also connects every derived requirement back to the system need it satisfies through explicit traceability links. This means when a subsystem team asks “why does this component have a 40 ms latency budget,” the answer is not in someone’s inbox — it is a live link from the component requirement, through the subsystem allocation, back to the system-level timing obligation, back to the operational scenario that defines the four-minute descent constraint. The rationale is structural, not narrative.

Flow Engineering’s scope is focused on systems and hardware engineering workflows. Teams that need deep integration with manufacturing execution systems or enterprise ERP will need interface work. That focus is deliberate: depth in the systems engineering problem rather than breadth across enterprise functions.

Practical Starting Points

If your program is managing allocation today through spreadsheets or manually maintained DOORS attributes, the path forward does not require replacing everything at once. Start with structure.

Map your system hierarchy explicitly. Before allocating, confirm that your decomposition is complete enough to allocate to. Allocation to a vaguely defined “avionics subsystem” that has not been further decomposed is not traceable — it is a placeholder.

Identify your budgets. List every numerically constrained system-level requirement: mass, power, latency, reliability, EMC limits, thermal dissipation. These are your allocation-critical requirements. They require apportionment, not just assignment.

Make the allocation relationship explicit and typed. Whether in a tool or a structured database, every derived requirement should carry a formal link to its parent — not a text field, but a queryable relationship. This is the minimum condition for gap analysis.

Audit for completeness at each level. For every parent requirement, confirm that at least one child allocation exists. For every budget, confirm that the children sum correctly. This is not a one-time gate review activity — it is a continuous check that belongs in your engineering workflow.

Treat allocation changes as architectural changes. When a system-level requirement changes, the allocation change process must be as formal as the original allocation decision. Informal change propagation — a verbal agreement that the new timing budget is acceptable — is how allocation gaps reopen after they have been closed.

Requirements allocation is where system intent becomes engineering accountability. Done rigorously, it makes integration predictable. Done poorly — or not done explicitly at all — it makes integration the phase where the program discovers what no one decided.