M8-T2: Requirements decomposition

Learning objectives

After this lesson, you should be able to:

• Allocate a system requirement to subsystems as derived requirements with owners.
• Combine independent and correlated error contributions correctly.
• Set and track margins through design, with a budget at every level.
• Identify when a budget cannot be met and the available responses.

Conceptual explanation

Established Budget allocation with root-sum-square for independent contributions and linear sum for worst-case or correlated ones is standard systems and error-budget practice. The numbers in the example are illustrative.

Decomposition breaks a system requirement into derived requirements on subsystems, with a clear owner, a threshold and a verification method for each. Three rules:

• Completeness: the derived requirements together must be sufficient to meet the parent (which is shown by the budget, not asserted).
• Allocation with budgets: for additive quantities (error, latency, mass, power) assign each subsystem a share, with explicit margin held at the system level.
• Traceability: each derived requirement points to its parent; each parent lists its children; changing one triggers review of the other (see the traceability lesson).

For example the horizontal position error over a GNSS-denied segment might be decomposed into: odometry drift per distance (perception team), time-offset-induced error (integration team), calibration-induced error (calibration owner), and controller tracking error (control team), each with a number and a verification.

Engineering intuition

Independent random errors add in quadrature: two independent 1 m errors give $\sqrt{2}\approx 1.41\,\mathrm{m}$, not 2 m. Worst-case (systematic or fully correlated) errors add linearly. Most real budgets are mixed: some terms are random (noise), some are biases (calibration), and some are correlated (the same time offset affects everything). Treating everything as independent understates the total; treating everything as worst case over-constrains the design and costs money and weight.

Margin is not slack to be spent by the first team that finds it. Hold margin at the system level, allocate it back only on a reviewed decision, and track it as the design matures: early in design 30–50 % margin is common; at flight readiness it should have shrunk to a small number backed by measurements.

Mathematical formulation

For independent contributions with standard deviations $\sigma _{i}$ the combined standard deviation is the root-sum-square (RSS); for contributions that are worst-case bounded (biases) with bounds $b_{j}$ the combined bound is the linear sum. A mixed budget:

For a horizontal (2D) error with independent north and east components of equal standard deviation $\sigma$ the radial error follows a Rayleigh distribution, whose 95th percentile is $\sigma \sqrt{-2 \ln 0.05}=2.448\,\sigma$ (not $1.96\,\sigma$), and whose 50th percentile is $1.177\,\sigma$. Margin $M$ = (Req − predicted)/Req. Correlation $\rho$ between two terms changes the combination to $\sqrt{\sigma _{1}^{2} + \sigma _{2}^{2} + 2\rho \sigma _{1}\sigma _{2}}$; for $\rho =1$ it equals $\sigma _{1}+\sigma _{2}$. When a budget cannot be met the responses, in order of preference, are: reduce the largest contributor, change the design (add a sensor), relax the requirement with the stakeholder, or reduce the operating condition (shorter segments).

$\sigma _{i}$

standard deviation of random contribution $i$.

$b_{j}$

bound of bias contribution $j$.

$\rho$

correlation coefficient between two contributions.

$M$

margin as a fraction of the requirement.

Architecture and data flow

System requirement (with ID) → error-budget table (contributors, type, value, source of the value: analysis, simulation or measurement, owner) → derived requirements per subsystem → verification at the subsystem level (bench, SIL) → roll-up recalculated from measured values → margin report at each design review. The budget file lives in the repository next to the requirements and is recomputed by a script whenever a measured value changes.

Real-world UAV applications

• Budgeting drift for a visual-inertial system over a stated segment length.
• Allocating latency across perception, planning and control.
• Power and mass budgets per mode.
• Deciding which subsystem to improve when the roll-up fails.

Implementation example

This runs as shown. An error budget for a 2D position error: random terms by RSS, bias terms by linear sum, 2D Rayleigh percentile, and a Monte Carlo check of the analytic roll-up. Values are illustrative placeholders; replace them with measured ones.

import numpy as np
rng = np.random.default_rng(31)
# ILLUSTRATIVE budget for horizontal position error over a 5-minute GNSS-denied segment (metres, per axis)
random_terms = {'odometry noise growth': 0.60, 'time-offset induced': 0.25, 'tracking jitter': 0.20}          # standard deviations per axis
bias_terms = {'scale error x distance': 0.35, 'extrinsic rotation error': 0.20}                                  # worst-case bounds (m)
Req = 2.0                                                                                                      # 95th percentile horizontal error (m)
k95 = np.sqrt(-2 * np.log(0.05))                                                                               # Rayleigh p95 factor for 2D
def rollup(random_terms, bias_terms):
    sigma = np.sqrt(sum(v * v for v in random_terms.values())); bias = sum(bias_terms.values()); pred = k95 * sigma + bias
    return sigma, bias, pred, (Req - pred) / Req
sigma, bias, pred, margin = rollup(random_terms, bias_terms)
print(f"v1: sigma per axis {sigma:.3f} m (RSS), bias {bias:.2f} m (sum), predicted p95 horizontal error {pred:.2f} m, margin {margin:.0%} -> {'PASS' if margin >= 0.1 else 'FAIL (margin below 10 %)'}")
better = dict(random_terms, **{'odometry noise growth': 0.35})                                                 # response: reduce the largest contributor (better odometry front end)
sigma2, bias2, pred2, margin2 = rollup(better, bias_terms)
print(f"v2: odometry noise reduced to 0.35 m: predicted p95 {pred2:.2f} m, margin {margin2:.0%} -> {'PASS' if margin2 >= 0.1 else 'FAIL'}")
# Monte Carlo check of v2: random terms Gaussian per axis, biases at their worst-case direction (aligned with one axis)
n = 400000; e = rng.normal(0, sigma2, (n, 2)); r = np.hypot(e[:, 0] + bias2, e[:, 1])
print(f"Monte Carlo p95 with the bias aligned to one axis: {np.percentile(r, 95):.2f} m (analytic bound {pred2:.2f})")
assert abs(k95 - 2.4477) < 1e-3 and np.percentile(r, 95) <= pred2 + 1e-6 and margin < 0.1 <= margin2
indep = np.sqrt(0.6 ** 2 + 0.25 ** 2 + 0.2 ** 2); lin = 0.6 + 0.25 + 0.2
print(f"RSS {indep:.2f} m versus linear sum {lin:.2f} m for the random terms: choosing the wrong rule changes the answer by {lin / indep - 1:.0%}")
assert lin > indep

Common engineering mistakes

Failure modes

Debugging approach

1. Recompute the roll-up from measured values and compare with the allocation.
2. Rank contributors by their contribution to the variance.
3. Look for common causes (shared clock, shared calibration) that correlate terms.
4. Check the budget with a simulation using the real error models.

Practical exercises

1. Add a time-offset-induced term for 3 ms offset at 5 m/s (velocity × offset) and update the budget.
2. Compute the 95th percentile of a 2D error with $\sigma =0.8\,\mathrm{m}$ per axis.
3. Find which single contributor must be halved to give 30 % margin.
4. Write three derived requirements with owners for the budget above.

Interview questions

Write an answer in your own words, then reveal the model answer. Nothing is sent anywhere.

References and further reading

Primary papers, official documentation and standards. Each claim above that is specific to a tool or version points here.

• NASA Systems Engineering Handbook (NASA/SP-2007-6105)
• INCOSE Systems Engineering Handbook
• Bar-Shalom, Y., Li, X. R. & Kirubarajan, T. (2001). Estimation with Applications to Tracking and Navigation. Wiley (error statistics and covariance combination)

What’s next