The question comes up in almost every frontier technology program, usually in a design review and usually phrased with some frustration: How are we supposed to write requirements for something we don’t fully understand yet?
It’s the right question to ask. You’re designing a plasma-facing component and the erosion models are still being validated. You’re specifying a rotating detonation engine and the combustion stability regime isn’t characterized at your operating point. You’re using a novel refractory alloy whose creep behavior above 1400°C exists as a single data point from a university test campaign. In every one of these situations, a traditional requirement — a shall statement with a single threshold and a verification method — is a fiction. The number in the requirement is a guess dressed up as an engineering commitment.
The answer isn’t to stop writing requirements. Ambiguity doesn’t excuse you from the discipline of systems engineering. The answer is to build a requirements structure that honestly encodes what you know, what you’re assuming, and what remains uncertain — and that can update as understanding matures without destroying traceability.
Here is how to do that.
Start With an Assumption Register, Tied Directly to Requirements
Most programs have assumptions buried in trade study reports, PDR presentations, or the head of the chief engineer. That is a process failure, not an unfortunate circumstance.
An assumption register is a structured list of every technical assumption the requirements baseline depends on. Each entry names the assumption, identifies which requirements it underlies, assigns an owner, states how confidence will be increased (a test, a simulation milestone, a literature review), and carries a current confidence level that gets updated as evidence accumulates.
The critical step most programs skip: the link between the assumption and the requirement must be explicit and navigable. If your mass requirement for a plasma-facing tile assembly assumes a particular erosion rate derived from modeling, that assumption needs to point at the requirement and the requirement needs to point back at the assumption. When your erosion model gets updated by test data, the affected requirements surface automatically rather than getting missed in a manual review cycle six months later.
This is bookkeeping, yes. It is also the difference between a program that learns from new physics and one that gets surprised by it at CDR.
Derived Requirements Must Carry Rationale, Not Just Parent Pointers
Standard traceability practice says a derived requirement must trace to a parent. That is necessary but not sufficient when the physics are uncertain.
Consider the difference between these two derived requirements:
Version A: “The cathode insert shall maintain a surface temperature below 1650°C during steady-state operation.” Parent: propulsion system thermal requirement.
Version B: “The cathode insert shall maintain a surface temperature below 1650°C during steady-state operation. Rationale: derived from the oxidation onset temperature of the specified tungsten-rhenium composition, per [material characterization report X, revision 2]. This threshold will be revisited if alloy composition changes or if oxidation kinetics testing produces results outside the modeled range.”
Version A will be correct until it is wrong, and no one will know why it went wrong. Version B encodes the physics assumption that generates the number, which means it can be updated correctly when the physics change, and the update will be legible to every engineer who inherits it.
Writing rationale takes time. On a program with physics you don’t fully understand, it is not optional overhead — it is how you avoid requirements that quietly become wrong as your understanding improves.
Use Living Requirements Baselines, Not Frozen Documents
The document-baseline model of requirements management — establish a baseline at PDR, change-control it tightly through CDR and beyond — was designed for programs where the physics are understood and the primary risk is scope creep. It works poorly for frontier systems where the primary risk is learning something that invalidates a key assumption.
A living requirements baseline is still controlled. Changes go through review. History is preserved. But the architecture treats requirements as nodes in an evolving knowledge graph rather than lines in a document that gets versioned. You can update a requirement, preserve the rationale for the change, maintain links to the test data or analysis that motivated the update, and propagate the impact assessment to every downstream requirement automatically.
The practical implication: when your plasma modeling team delivers revised sheath voltage estimates in Q3, you want to trace that new data directly to the set of requirements it affects, review those requirements in a single structured session, update them with rationale, and re-verify that the system still closes. What you don’t want is to initiate a document change order against a 400-page SRS, circulate it for 30 reviewers’ signatures, and have the updated understanding sit in a change log that half the team hasn’t read.
Technical Performance Measures as Early Warning Systems
A Technical Performance Measure (TPM) is a tracked quantity that tells you, before a requirement is formally breached, whether you’re trending toward a breach. TPMs are standard systems engineering practice. What changes on frontier programs is that some of your TPMs should be tracking the physics, not just the design.
On a conventional program, a TPM on structural mass might track design mass against the allocated mass budget. On a frontier program, you might also track a physics-confidence TPM: the uncertainty band on your thermal conductivity model, measured as the ratio of your current worst-case prediction to your best-case prediction. When that ratio exceeds a threshold, it’s a trigger to review requirements that depend on that parameter before the design is any further along.
This sounds abstract. In practice it looks like this: every requirement whose verification method includes a model or simulation carries a reference to the governing physics inputs. Each physics input has a current uncertainty characterization. Requirements engineering owns a dashboard that shows which requirements are sitting on physics inputs whose uncertainty is growing or unresolved. That dashboard is a first-order agenda item in every monthly technical review.
Most programs don’t do this because the tooling doesn’t naturally support linking requirements to model parameters. That’s a tooling problem worth solving.
Structuring Requirements to Capture What Is Known While Flagging Uncertainty
When the physics aren’t characterized, you still have to write something. Here is a practical structure that works:
Known requirements — write them normally, with rationale, verification method, and links to assumptions.
Threshold/objective pairs — when you have a physics-derived best case and a physics-derived worst case, write both. The threshold is the number the design must achieve to be viable under worst-case physics. The objective is the number that represents best-case physics. This is standard JCIDS language borrowed usefully into commercial and civil space practice. It forces intellectual honesty: you’re admitting you don’t know exactly where the requirement will land.
Placeholder requirements — when a requirement exists in the architecture (the system definitely needs to meet some thermal flux limit) but the number is not yet physically grounded, write the requirement with an explicit TBD, a date by which the TBD must be resolved, the owner of the resolution, and the test or analysis event that will resolve it. A placeholder requirement is not a failure of systems engineering. A placeholder requirement with no resolution date and no owner is.
Requirement flags — a status field on each requirement that can carry values like STABLE, PHYSICS-DEPENDENT, UNDER-REVIEW, or SUPERSEDED. Requirement flags are visible in every view of the requirement. Engineers can immediately see the confidence status of any requirement they’re designing to. This changes behavior: a designer who knows a requirement is flagged PHYSICS-DEPENDENT will make different architecture decisions than one who assumes every requirement is settled.
How Modern Platforms Handle This
Most requirements management tools were built for the assumption that requirements are stable. IBM DOORS and DOORS Next are excellent at controlling large, stable requirement sets. Jama Connect offers good collaboration and review workflows. Polarion and Codebeamer support both requirements and software change management effectively. None of them were designed around the specific problem of requirements whose technical basis is evolving.
The architectural mismatch is fundamental. Document-based or module-based tools store requirements as rows or paragraphs. Linking those rows to assumption registers, model parameters, TPM dashboards, and physics test data requires integrations that are almost always custom, fragile, and unmaintained after the integration engineer leaves the program.
Flow Engineering (flowengineering.com) approaches requirements as a graph from the start. Every requirement is a node. Assumptions, rationale, verification evidence, test data, and TPMs are also nodes. Edges between them are typed and navigable. When a physics input changes, the impact propagates through the graph and surfaces every downstream requirement that the changed assumption touches — without a manual search.
For frontier technology programs specifically, the living documentation model matters as much as the graph structure. Flow Engineering maintains full version history on every node and edge, so when your erosion model gets revised by a test campaign, the requirements that change carry a legible audit trail: what the requirement said before, why it changed, what data drove the change, and who reviewed it. That audit trail is what allows a program to maintain design authority confidence across a requirements baseline that is intentionally evolving.
Flow Engineering’s scope is currently focused on systems and hardware requirements rather than full ALM — it doesn’t replace a software change management system or an ERP. For programs that need deep software requirements and code traceability in a single platform, that boundary is worth understanding. But for the systems engineering layer where frontier physics programs live — architecture, allocation, TPMs, assumption management — the graph-native model is the right fit.
Practical Starting Points
If your program is already underway and the requirements are already partially frozen:
Audit first. Before changing anything, identify which existing requirements are physics-dependent and don’t currently carry rationale. These are your highest-risk requirements. Start there.
Create the assumption register retroactively. Yes, this is tedious. Do it anyway. Three months of retroactive assumption documentation is worth less than six months of retroactive requirement debugging after a test reveals the physics were different than assumed.
Introduce requirement flags as a metadata field. Most tools, even DOORS, can support a custom attribute. Flag every requirement with its physics-confidence status. Make the flags visible in your standard views.
Establish TPM reviews that include physics-input uncertainty, not just design performance. Put it on the monthly agenda.
Plan the tool migration when the program is young, not when it’s in crisis. The programs that end up managing evolving physics requirements in spreadsheets and email threads made that choice early, usually by not making a choice at all.
The Honest Summary
You cannot write perfect requirements for a system whose physics aren’t fully understood. You can write honest requirements: requirements that say what they’re based on, flag what they’re assuming, identify what would change them, and link to the evidence that will eventually resolve the uncertainty. That is a harder discipline than writing a shall statement with a number in it. It is also the only discipline that works when the physics are frontier.
The programs that handle this well are the ones that treat uncertainty as information to be managed rather than discomfort to be suppressed. They build assumption registers and maintain them. They write rationale. They update requirements when physics improve and they keep the audit trail. They use tools whose architecture supports that workflow instead of tools that fight it.
The physics will eventually be understood. Your requirements should be ready for that moment.