Requirements Flowdown: Keep Allocations True After Changes

Every hardware team gets requirements flowdown right exactly once: during the initial system architecture phase before Preliminary Design Review. Systems engineering writes the system spec, breaks top-level vehicle constraints into subsystem targets, and links child requirements to parent IDs in a spreadsheet or database. Everyone signs off, CAD starts moving, and the design matures.

Then real engineering happens. A structural analyst finds a resonance mode and thickens a bracket. A vendor delivers a battery pack that runs four degrees hotter than its datasheet promised. A customer tightens payload mass by 5%. The parent requirement updates, or the CAD mass property shifts, but nobody recalculates the intermediate budget splits. The child requirements still show active links to the parent, so leadership thinks the program is traceable. It isn't. The allocation arithmetic broke weeks ago.

This guide shows how to execute requirements flowdown so your numbers stay true through repeated design cycles. Before you start, you need your top-level functional requirements, a baseline product breakdown structure, and defined interfaces between subsystems.

Step 1: Write each derived requirement with a stated allocation rationale

A requirement without a stated rationale is an arbitrary number. When an engineer reads that Subsystem B must weigh under 4.2 kg, their first question during a redesign is whether that limit is physics-based, standard practice, or an arbitrary split of a top-level 10 kg vehicle limit. If the requirement record doesn't answer that, the engineer either treats the number as unchangeable or ignores it.

Every derived requirement needs three components in its definition field: the verifiable statement, the parent link, and the allocation rationale. The rationale must state the exact formula, assumption, or physical constraint used to derive the number. Don't just write: 'The sensor enclosure shall dissipate no more than 15 W via conduction to the primary chassis.' State the underlying model: 'Allocated from SYS-REQ-204 (max sensor bench temperature 45 C at 35 C ambient) assuming a 0.67 C/W thermal resistance path across the thermal interface pad and mounting interface.'

Documenting rationale changes how change impact analysis works. Say the chassis team switches from aluminum 6061-T6 to an additive titanium bracket. The thermal resistance across that interface changes. If the rationale is explicit, the systems engineer knows right away that the 15 W allocation is invalid. If it's missing, the team finds the thermal bottleneck when the physical prototype overheats during environmental testing.

The NASA Systems Engineering Handbook names rationale capture as necessary for managing requirement evolution. Write the engineering trade-offs, standard operating conditions, and mathematical models directly alongside the requirement text. When a parent requirement shifts later, the rationale tells you whether the child number can be scaled proportionally or whether a non-linear physical limit blocks a simple re-split.

Step 2: Allocate budgets with margin held at every level

The most common failure in requirements flowdown is allocating 100% of a parent budget to child subsystems on day one. A satellite bus with a 150 kg mass limit, divided exactly across payload, power, propulsion, ADCS, and structure, will overrun. Subsystems don't mature at the same rate, and mass growth during early detailed design is predictable.

Handle this with a hierarchical margin policy. Follow a structured standard such as NASA GSFC-STD-1000, which sets explicit contingency curves by design maturity phase. At Concept Design, hold 25% to 30% margin at the system level. The systems engineering team reserves this margin, and subsystem leads can't touch it.

Distribute the remaining 70% to 75% to the subsystems. Each subsystem lead then reserves their own contingency (typically 10% to 15%) before flowing child allocations down to lower assemblies. If the power subsystem receives a 20 kg budget from the system level, the lead power engineer holds 3 kg in reserve and flows down 17 kg across battery cells, BMS boards, harness, and casing. To do this cleanly, keep a dedicated mass and power budget tracking table that separates current best estimates from allocated limits.

Apply the same stacked margin discipline to power dissipation, volumetric envelopes, thermal dissipation, and RF link margins. Child allocations should never sum to the full parent limit. If a parent requirement allows 240 W peak power draw, the sum of child allocations at Critical Design Review shouldn't exceed 200 W to 215 W, depending on your risk classification.

Step 3: Keep the parent-child link and the split arithmetic visible in one place

Traditional requirements management tools track parent-child relationships as directional pointers. Requirement A points to Requirements B and C. But pointers don't evaluate arithmetic. Say Requirement A specifies a maximum current draw of 10 A, and over three months child requirements B and C get edited to 6 A and 7 A. The traceability matrix still reports green. Both children still link to the parent. The link is intact and the physics is broken.

Good requirements flowdown puts relational traceability and split arithmetic in the same view. A systems engineer should see a parent requirement, its allocated children, the roll-up equation, the unallocated system reserve, and the live status at once. When a property is additive, like mass or power, the roll-up is a simple sum. When a property is non-linear, like structural stiffness or system reliability, the flowdown needs root-sum-square formulas or serial reliability math.

Keep these roll-ups next to the design definition. If engineers have to open a disconnected analysis spreadsheet to check whether child allocations equal the parent, they'll skip the check during quick design iterations. Maintain structured tables where budget allocations, current engineering estimates, and allowable limits sit side by side. When an allocation changes, the delta against the parent budget should recalculate instantly and flag deficits in red before parts are released to suppliers.

Step 4: Work a structural and thermal example through a parent change

The easiest way to see silent flowdown failure is to trace a structural and thermal requirement through an engineering change. Take an optical payload assembly. The parent requirement, SYS-ENV-104, says the primary mirror mount must hold optical alignment within 50 microradians under an operating thermal gradient of -20 C to +50 C, while surviving a 15 g launch shock load.

During initial flowdown, systems engineering splits this into three derived requirements. STR-REQ-012 allocates a minimum first natural frequency of 120 Hz to the structural mounting bracket. THM-REQ-044 allocates a maximum thermal expansion coefficient of 4.5 ppm/K to the bracket material, which points to titanium or Invar. THM-REQ-045 allocates 12 W of active heater power to keep the mirror bench stable during cold orbits.

Six months in, the launch vehicle changes. The new one raises the shock load requirement from 15 g to 22 g. The structural team reacts fast. They open CAD, thicken the bracket webs, and switch the mounting bracket from titanium to high-strength stainless steel (17-4 PH) to meet stress margins. STR-REQ-012 is re-analyzed, and the bracket hits 135 Hz and passes stress analysis.

The structural requirement shows verified. The traceability matrix shows complete links. The flowdown has still failed. Stainless steel has a coefficient of thermal expansion around 10.8 ppm/K, more than double the 4.5 ppm/K allocated in THM-REQ-044. Under orbit thermal conditions, the stiffer bracket distorts the mirror mount past 85 microradians and violates SYS-ENV-104.

The structural engineer evaluated the shock load change entirely inside their own silo, so the thermal child requirement was breached without anyone noticing. A change to structural stiffness can't happen in isolation from its thermal and dimensional allocations.

Step 5: Define what to recheck when a parent requirement or subsystem CAD changes

To stop silent degradation, set an explicit recheck protocol triggered by two events: a formal change to a parent requirement, or a physical change to subsystem CAD geometry. When either happens, run a standard change impact sequence before approving the revision.

When a parent requirement changes, run these checks:

1. Recalculate allocation sums. Compare the sum of all child allocations against the updated parent limit, accounting for retained system margin.

2. Review allocation rationales. Read the rationale on every child requirement. Check whether the assumptions (ambient temperature, operational duty cycle, material properties) still hold under the new parent text.

3. Query interface constraints. Determine whether the parent change alters any physical boundary defined in your interface control document.

When subsystem CAD changes, reverse the direction:

1. Extract physical properties. Read actual mass, center of gravity, volume envelope, and surface area directly from the CAD assembly model.

2. Compare CAD actuals against allocated limits. Check whether the CAD mass exceeds the child requirement allocation minus the subsystem-level contingency reserve.

3. Identify cross-discipline impacts. If CAD geometry changes to add strength or clear a packaging clash, trigger an automatic review notification to adjacent subsystem leads (thermal, electrical routing, manufacturing).

Make these checks a mandatory gate in your design review workflow. If an engineer modifies geometry in SolidWorks or PTC Creo to fix a component clearance issue, the change review must verify that the updated component still meets its derived mass and thermal allocations.

Step 6: Tie flowdown to verification so no child closes against a superseded parent

Verification without live flowdown alignment creates false confidence. In audit after audit across aerospace and medical device programs, teams present passed test reports for child requirements that were superseded three revisions earlier. A test engineer tests a valve body to 150 psi because the child specification says 150 psi. The top-level fluid system spec moved to 200 psi two months ago, and nobody pushed the allocation to the test bench.

Prevent this by anchoring your verification cross reference matrix directly to the parent-child flowdown tree. A verification activity should never close a child requirement if that child's parent has an open change request, an unverified status, or an arithmetic allocation mismatch.

Set a strict closure rule: when a parent requirement changes, automatically flag every downstream verification result as suspect. If SYS-REQ-101 updates, all child requirements (MECH-201, ELEC-104) move from 'Verified' to 'Verification Requires Review'. The responsible engineer inspects the delta, confirms whether the previous test or analysis still holds against the new baseline, and records formal justification before re-baselining.

NASA procedural requirements for verification, such as NPR 7123.1, mandate this bidirectional lineage. You can't claim system verification just because every child component passed its stand-alone bench test. If the split arithmetic between levels is invalid, child-level success doesn't equal system-level compliance.

Step 7: Automate the checks and what to do next

Manual tracking in disconnected tools makes consistent requirements flowdown nearly impossible over a multi-year program. Spreadsheets have no live connection to CAD models, and traditional enterprise systems engineering platforms isolate requirement text from the mechanical design environment where engineering decisions actually happen.

Tandem closes that gap as the grounded context layer for hardware teams. Tandem connects design intent, requirements, CAD changes, and validation evidence in a single system. Its first-class systems engineering module lets teams build visual system, subsystem, and component architectures with custom attributes like weight, cost, thermal limits, and program status. Requirements live in structured tables with explicit hierarchy, ownership, approvals, and graph relationships.

Instead of checking CAD properties by hand, Tandem identifies what a change affects and runs requirement checks against linked CAD in tools like SolidWorks, Onshape, Fusion, and NX. When a mechanical engineer updates geometry, Tandem tracks the change against linked derived requirements and budget allocations. If a mass increase breaches an allocated limit or invalidates child-parent roll-up arithmetic, the system flags the conflict immediately during design reviews held in context with the CAD change and verification evidence.

To put this into practice on your current program:

1. Audit your top three technical budgets (mass, power, thermal). Check whether the sum of child allocations plus reserves matches parent targets today.

2. Add an explicit 'Allocation Rationale' attribute to your requirement schema. Reject any derived requirement in design review that lacks a stated mathematical or physical derivation.

3. Connect your requirements to your engineering toolchain so CAD revisions notify requirement owners before hardware hits the factory floor.

Conclusion

Requirements flowdown isn't an administrative check you do to satisfy a milestone gate. It's the math that makes a thousand independent engineering decisions add up to a working vehicle, robot, or medical device. When parent requirements shift and CAD geometry iterates, static traceability matrices hide the arithmetic drift that derails physical integration.

Tandem links your requirements, architecture hierarchy, technical budgets, CAD changes, and verification evidence in one shared context layer. Book a demo with Tandem to see how the systems engineering module keeps your allocations true from early architecture through final verification.