How Do You Write Requirements for Hardware That Must Operate in Environments We Have Never Fully Characterized?
You are designing a thermal protection system for a hypersonic vehicle. You know the vehicle will encounter aeroheating, but the precise heat flux at a particular forebody location depends on trajectory dispersions, atmospheric density variations, and turbulent boundary layer transition — none of which you can pin to a single number. You must write a temperature requirement. What number do you write, and how do you justify it?
This is the central problem of environmental requirements under deep uncertainty: you must bound something you cannot fully measure, specify something you cannot fully test, and then defend that specification through a design review, a qualification program, and — if everything goes wrong — a failure review board.
The answer is not to leave the requirement vague. It is to write the requirement precisely, including its uncertainty structure, and to make the rationale for every assumption a permanent, traceable part of the requirements record.
What “Environmental Requirements” Actually Means in Uncharacterized Domains
An environmental requirement defines the conditions a system must survive and operate within. In well-characterized domains — an office building, a factory floor — you write a temperature range from a standard, a humidity spec from a handbook, and you’re done. The environment is known.
In deep space, hypersonic flight, fusion reactor interiors, and hadal ocean zones, the environment is partially unknown by definition. No one has made thousands of measurements at 60 km altitude in the entry corridor of a Mars mission. No one has characterized the neutron flux spectrum at every point inside a first-of-a-kind compact fusion device. The deepest ocean trenches have been visited by fewer vehicles than the Moon.
This does not mean requirements cannot be written. It means requirements must carry their uncertainty explicitly, must be derived from worst-case analysis rather than nominal measurement, and must document the models, assumptions, and margins that transform an uncertain environment into a specified design condition.
Worst-Case Analysis: Structure, Not Pessimism
“Worst case” is frequently misunderstood as maximum conservatism — pile on all the margins and call it done. That approach produces unachievable requirements and kills programs. Real worst-case analysis is a disciplined process of identifying which combinations of credible extremes are physically simultaneous and stacking only those.
Deep Space: Radiation and Thermal
The James Webb Space Telescope operates at L2, roughly 1.5 million kilometers from Earth, at cryogenic temperatures approaching 40 K on the cold side of its sunshield. Its radiation environment combines galactic cosmic rays, solar energetic particle events, and trapped particle belts during Earth departure. No single mission had precisely characterized the combined total ionizing dose and displacement damage dose at L2 over a 10-year mission before JWST was designed.
The approach: derive worst-case TID from solar maximum models (AP-8/AE-8 updated with sector shielding analysis), add a radiation design margin factor (typically 2× on TID for Class B missions), and write component-level radiation tolerance requirements from that derived environment. The requirement does not say “the environment is exactly X rad(Si).” It says “components shall tolerate Y rad(Si) TID, where Y equals the worst-case predicted environment over mission life multiplied by a radiation design margin of 2×.” The margin factor is in the requirement, and the derivation — which solar flux model, which shielding analysis, which trajectory — is in the rationale.
When the solar cycle behaves differently than the model predicted, the traceability chain from rationale to requirement drives a controlled change assessment. Without that chain, engineers are guessing whether the specification is still valid.
Hypersonic: Heat Flux and Boundary Layer Transition
A hypersonic glide vehicle re-entering the atmosphere faces heat flux that varies by orders of magnitude depending on whether the boundary layer over a surface is laminar or turbulent. Transition is stochastic — it depends on surface roughness, freestream disturbances, and local flow conditions that vary flight to flight. You cannot specify a single heat flux for your thermal protection material requirement.
The structured approach: define a trajectory design space (altitude-velocity corridor with dispersions), run a Monte Carlo thermal analysis across that space with boundary layer transition modeled stochastically, identify the high-percentile heat flux (95th or 99th percentile depending on criticality), add a design margin (frequently 25–40% on peak heat flux for new material systems), and write the requirement as: “The TPS shall maintain bondline temperature below T_max under a peak surface heat flux of Q W/cm², applied for a duration of D seconds, where Q represents the 99th percentile worst-case trajectory condition plus 30% design margin.”
Every term in that requirement has a derivable lineage. The 99th percentile comes from the Monte Carlo. The 30% comes from program risk posture and material characterization maturity. That rationale must be recorded.
Fusion: Neutron Flux and First-Wall Loading
First-generation commercial fusion devices like those being developed by Commonwealth Fusion Systems and TAE Technologies operate in an environment that is, by definition, not fully characterized before operation — because the device itself creates the environment. The 14.1 MeV neutron flux at the first wall of a compact high-field tokamak has been predicted by neutronics codes (MCNP, OpenMC), validated on fission test reactors to first approximation, but the exact spectrum at every structural location in a novel geometry is a model output, not a measurement.
Requirements strategy here involves two layers: bounding requirements derived from the most credible neutronics model plus an uncertainty envelope (often expressed as ±X% on total fluence at end of design life), and requirements that explicitly state the assumed neutron energy spectrum used for displacement damage calculations. A structural material requirement that says “shall maintain fracture toughness above K_IC_min after 10 dpa displacement damage” is only auditable if the requirement record also captures which dpa calculation was used and what spectrum was assumed. As the device operates and actual activation measurements are taken, the environmental characterization improves — and the rationale chain shows which requirements are potentially affected.
Deep Sea: Pressure, Temperature, and Biofouling Chemistry
At hadal depths (6,000–11,000 meters), hydrostatic pressure reaches 110 MPa. The Challenger Deep bottom water temperature is approximately 1–2°C. Both values are well characterized for that specific point. The problem arises for systems operating in less surveyed regions — mid-ocean ridge hydrothermal vent fields, for example, where vent fluid temperature can range from 2°C in ambient bottom water to over 400°C at the vent orifice, and fluid chemistry includes dissolved sulfides, metals, and gases that vary vent to vent and even within a single vent over time.
For a sensor system deployed near active venting, the environmental requirement cannot be “ambient bottom water conditions.” It must bound the potential thermal and chemical excursion. The approach: characterize the envelope from available vent surveys (the NOAA and Schmidt Ocean Institute dive databases provide decades of measurements), identify the credible worst-case thermal exposure for the deployment scenario, apply material compatibility margins for corrosion and biofouling, and document which survey data was used, when it was collected, and what geological setting it represents.
A pressure housing requirement written as “shall survive 120 MPa external pressure with a safety factor of 1.5 on yield” is meaningless without documentation that 120 MPa was chosen as the deepest credible deployment plus pressure transient margin, derived from target site bathymetry plus the uncertainty in that bathymetric survey.
Structuring Requirements When Parameters Have Uncertainty Bands
The mechanical structure of the requirement itself must change when the input environment has uncertainty. Three patterns are useful:
Pattern 1: Requirement at the Deterministic Worst Case Write the requirement as a fixed value, but make that value the output of a worst-case analysis documented in rationale. The requirement is crisp; the uncertainty is in the derivation. This works when the uncertainty band can be fully collapsed into a single bounding number with acceptable conservatism.
Example: “The electronics assembly shall operate within specification across a temperature range of -55°C to +125°C.” The rationale documents that this was derived from orbital thermal analysis with worst-case albedo, beta angle, and eclipse fraction, plus 10°C margin.
Pattern 2: Requirement With Explicit Uncertainty Acknowledgment Write the requirement with the nominal value and the uncertainty range stated, and require the design to maintain compliance across the full range.
Example: “The first-wall structural panel shall maintain yield strength margin above 1.25 at a neutron fluence of 2.5 × 10²⁶ n/m² ± 15%, where the ±15% reflects neutronics model uncertainty as characterized in [reference document].”
This forces the designer to demonstrate margin across a range, not just at a point. It prevents the failure mode where a design passes at the nominal but fails at the credible upper bound.
Pattern 3: Tiered Requirements by Scenario For environments with qualitatively different modes (normal operations vs. off-normal vs. worst credible accident), write separate requirements for each tier with explicit applicability conditions.
Fusion systems use this extensively: steady-state neutron loading during normal plasma operation, off-normal loading during disruption events, and beyond-design-basis conditions are three separate requirement sets with different margin philosophies.
What Test Environments and Simulation Actually Do
Qualification testing in uncharacterized environments does not prove the requirement was right. It demonstrates that the hardware survives the specified requirement. The requirement’s adequacy rests on the analysis.
This is the distinction that matters: test bounds the hardware response; analysis bounds the environment. When the environment is uncertain, analysis must precede and frame every test. A thermal vacuum test that cycles a spacecraft component to -40°C / +80°C proves the component works at those temperatures — it says nothing about whether those temperatures represent the actual worst case unless the analysis tying operational environment to test condition is documented and defensible.
Simulation’s role is to extend physical test coverage into parameter space that cannot be physically replicated — neutron flux levels that would require a reactor, pressures that would require full ocean depth, hypersonic conditions that exceed any existing ground facility’s capability. But simulation introduces its own uncertainty, and that uncertainty must be quantified and reflected in margins.
A CFD-derived heat flux used to set a hypersonic TPS requirement carries a validation uncertainty band. That band should drive margin selection, and the margin selection should be documented in the requirement rationale.
The Rationale Is Not a Footnote
In a traditional document-based requirements management approach, rationale is often captured in a separate column of a spreadsheet, or in a separate document linked by reference. In practice, it gets separated from the requirement during revisions, becomes stale, or is never written in the first place.
This is operationally dangerous. When a mission profile changes — a hypersonic vehicle now flies a different trajectory corridor, a space mission extends its life by three years, a fusion device increases its planned plasma current — the first question is “which requirements are potentially invalidated by this change?” Without rationale linked to requirements, engineers must re-derive everything from scratch or, worse, assume nothing changed.
Modern graph-based requirements tools address this structurally. Platforms like Flow Engineering represent requirements, assumptions, rationale, and derived constraints as nodes in a connected graph rather than rows in a document. When an upstream environmental assumption changes — say, the thermal model is updated with new atmospheric density data — the tool can traverse the graph to identify every downstream requirement that was derived from that assumption. This is not an automated analysis; it is a structured audit path. The engineer still makes the judgment call. But the traceability exists to make that call informed rather than approximate.
Flow Engineering also enables teams to capture the “this requirement exists because of this specific analysis, performed under these assumptions, with this margin logic” relationship explicitly — not as a comment, but as a linked record. For programs where environmental characterization is still evolving (an early-phase fusion device, a new ocean sensor platform), this means the requirements base can be updated in a controlled, auditable way as measurements replace models.
Practical Starting Points for Programs Facing Uncharacterized Environments
Characterize uncertainty before writing requirements. Identify which environmental parameters are known (handbook values, prior measurements), which are modeled (analysis outputs with known uncertainty), and which are genuinely unknown (no validated model, sparse data). Treat each category differently in the requirement.
Margin is not a single number. Margin on a structural load is different from margin on a radiation dose is different from margin on a thermal cycle count. Each environmental parameter has its own margin tradition rooted in the nature of the uncertainty. Adopt domain-relevant margin standards (MIL-STD-1540 for launch vehicles, NASA-STD-7002 for space systems, ITER materials specifications for fusion) and document deviations explicitly.
Write rationale as a structured argument, not a sentence. Good rationale answers: what data or analysis produced this value, what uncertainty exists in that data/analysis, what margin was applied and why, and what conditions would invalidate this requirement. A one-sentence rationale note fails all four.
Plan for requirement evolution. In an uncharacterized environment, early requirements are hypotheses. Build your requirements management process to support controlled re-baselining as characterization improves. Every requirement derived from a model should be flagged for review when that model is updated.
Link environmental requirements to test plans. Every environmental requirement should have a traceable verification method. If the verification is “analysis only” because physical testing is impossible, that fact must be documented and the adequacy of the analysis must be formally assessed.
The Core Discipline
Writing requirements for uncharacterized environments is not fundamentally different from writing requirements for well-understood ones. The discipline is the same: be specific, be derivable, and be traceable. What changes is that the input to the derivation carries uncertainty, and that uncertainty must be made explicit in the requirement and its rationale rather than hidden in an analyst’s notebook.
The programs that get this right — JWST, the ITER fusion experiment, the Woods Hole deep submersible programs, hypersonic development programs that survive their test campaigns — treat the environmental characterization and the requirements derivation as one continuous analytical record. When the environment surprises them, they have the record to respond to the surprise systematically. When the environment confirms the analysis, they have the record to close the verification loop cleanly.
The ones that get it wrong treat environmental requirements as negotiated numbers in a specification table, with the analysis that produced those numbers living elsewhere, in someone else’s file, or nowhere at all.