How Do You Write Good Requirements for a System That Has Never Been Built Before?

The honest answer is: carefully, iteratively, and with a lot of explicit uncertainty management built into the process from the start.

Most requirements training assumes you have something to copy from. A new aircraft variant inherits from the previous one. A next-generation radar inherits from its predecessor. Even the most ambitious new systems typically have analogues that give you a starting point — prior mission concepts, similar operational environments, related technology.

Novel systems break that assumption. A compact fusion reactor has no commercial predecessor. An autonomous urban air taxi operates in an airspace regime that doesn’t yet have a defined regulatory framework. An AI-enabled diagnostic system may be the first of its kind in a clinical setting where the failure modes aren’t fully characterized. When you sit down to write requirements for systems like these, you can’t flip to the prior program’s System Requirements Document and start editing.

What you can do is work from first principles. This article explains how.

Start With Physics and Operational Need, Not Prior Specifications

The instinct when faced with a blank requirements document is to borrow. You look for the closest analogous system, copy its structure, and modify from there. For truly novel systems, this is dangerous — you inherit assumptions that don’t apply and miss requirements that are genuinely new.

The better starting point is a two-pronged approach: physics constraints and operational need.

Physics constraints are the requirements that nature imposes regardless of what any customer asks for. A fusion reactor must sustain plasma temperatures above ignition threshold. An air vehicle must generate lift sufficient to overcome its weight. A diagnostic AI must operate within the latency window that supports clinical decision-making. These requirements exist before you’ve written a single stakeholder need statement. They bound what’s physically achievable and give you a hard floor for performance requirements.

The technique here is dimensional analysis combined with first-principles modeling. Start with the governing equations for your system’s core function. What quantities must be achieved for the system to work at all? These become your Level 0 performance bounds — not yet requirements in the formal sense, but physical constraints that any compliant design must satisfy. They’re also extremely useful as sanity checks later when proposed requirements seem to violate them.

Operational need is the other anchor. What problem is this system solving, and for whom, under what conditions? This sounds obvious, but for novel systems it requires unusual rigor because the operators themselves may not know yet. A utility company planning to integrate fusion power into a grid has never operated fusion before. An air traffic controller handling urban air mobility vehicles is working in a future operational environment. The stakeholders can tell you what problems they need solved; they often cannot tell you what a solution should look like.

This is where the requirements engineer’s job is genuinely creative: translating vague but real operational needs into bounded, verifiable statements. The translation mechanism is the Concept of Operations.

Use ConOps and Operational Scenarios as the Primary Derivation Engine

For novel systems, the Concept of Operations (ConOps) is not a downstream document that describes how the system will be used after you’ve designed it. It’s the primary derivation mechanism for requirements, developed before and alongside the requirements themselves.

The ConOps describes the operational environment, the actors involved, the key scenarios the system must handle, and the operational outcomes that define success. For a novel system, building this document is inherently speculative — you’re describing an operation that hasn’t happened yet. That’s fine. Explicit speculation is better than implicit assumption.

The technique is to build a scenario library: a structured set of operational scenarios that spans normal operations, off-nominal conditions, and edge cases. For each scenario, ask: what must the system do, to what level of performance, under what constraints, and what happens if it fails? Each answer is a candidate requirement.

Walk through a concrete example. You’re writing requirements for an autonomous urban air taxi operating in dense urban airspace. No such system exists at scale. Start with scenarios:

  • Normal: Single passenger, planned route, standard weather, coordinated with air traffic management
  • Off-nominal: Vehicle detects obstacle mid-route, must reroute in real time
  • Emergency: Primary propulsion failure, must execute emergency landing with zero fatalities
  • Edge: Communication link to ground control degraded, system must operate autonomously for defined period

Each scenario generates requirements. The emergency scenario generates safety requirements, fault tolerance requirements, landing site detection requirements, and passenger notification requirements — none of which you’d derive from a normal operations document alone. The off-nominal scenario generates real-time performance requirements for the onboard planning system. The edge scenario generates autonomy duration requirements and communications degradation handling requirements.

This process surfaces requirements that no analogy-based approach would give you, because the operational situations themselves are novel.

Bound Design Freedom Without Prescribing Solutions

The second major challenge for novel systems is that the design space is genuinely open. You don’t know yet whether the fusion reactor will use a tokamak or stellarator configuration, whether the air taxi will use distributed electric propulsion or a hybrid system, whether the diagnostic AI will use a transformer architecture or a graph neural network. Requirements written at this stage must bound the acceptable design space without closing it prematurely.

This means writing functional requirements with performance bounds, not solution requirements. A solution requirement says “the system shall use a redundant ducted fan propulsion system.” A functional requirement says “the system shall maintain controlled flight following any single propulsion component failure.” The second form allows the designer to choose any propulsion architecture that achieves that capability. The first form locks down a design choice before the trade study that would justify it.

The practical discipline is to ask, for every proposed requirement: “Does this require a specific design, or does it require a specific capability?” If it requires a specific design, either the trade study has been done and the design choice is justified (in which case, document the rationale explicitly), or the requirement is premature and should be rewritten as a capability bound.

Allocating requirements to interfaces rather than internals is another technique. If you specify what the system must deliver at its boundaries — power output, data rate, precision, latency, safety behavior — you leave the internal architecture open. This is especially important for novel systems where the internal architecture may change substantially as the technology matures.

Use Threshold and Objective Values to Manage Uncertainty Honestly

For novel systems, pretending you know the right performance number is worse than admitting uncertainty. A single requirement value implies that you know with confidence that the value is achievable, necessary, and correctly derived. For unprecedented systems, that confidence often isn’t warranted.

The threshold/objective construct — borrowed from NASA and defense acquisition practice — is the right tool here. A threshold value is the minimum acceptable performance: the system fails its purpose if it doesn’t achieve this. An objective value is the target that would deliver full intended value if achievable. The gap between them is the design trade space.

For a fusion reactor: threshold net energy gain might be Q > 1.2 (the system produces more energy than it consumes); objective might be Q > 5 (economically competitive with other generation sources). Both values are grounded in physics and economics, not arbitrary. The threshold establishes the viability floor; the objective establishes the value ceiling. The design team now knows they have a real range to optimize within.

This construct forces stakeholders to think carefully about what they actually need versus what they’d like, which is productive even when it’s uncomfortable. It also makes the requirements honest: rather than specifying a number you’re not confident in, you’re specifying a range with explicit rationale for both ends.

Document the rationale for both values explicitly. Where does the threshold come from — physics, regulation, economics, safety? Where does the objective come from — competitive analysis, operational modeling, stakeholder preference? That rationale is what allows the requirements to be intelligently updated as knowledge grows.

Treat Requirements as Living Artifacts From Day One

The biggest process failure in novel system development is treating requirements as a document that gets written, approved, and then defended against change. For systems at the frontier of what’s been built, requirements will change — because your understanding of the physics will improve, because the operational concept will be refined, because the regulatory environment will evolve, and because early prototype results will invalidate some assumptions.

The question isn’t whether requirements will change; it’s whether those changes will be managed with discipline or absorbed informally and invisibly.

This means your requirements infrastructure needs to support iterative development from the beginning. Specifically:

Every requirement needs traceable rationale. Not just a source reference, but an explicit statement of why this requirement exists and what assumption or operational need it derives from. When the assumption changes, you can find every requirement derived from it.

Change history must be first-class. Not a footnote in a revision log, but a structured record: what changed, when, why, and what downstream requirements or design decisions were affected. This is how you avoid the failure mode where a prototype result changes an assumption, the relevant requirements get updated, but a dozen downstream allocations still reflect the old version.

Traceability must link requirements to their derivation, not just to verification methods. Most requirements management tools focus on the downward trace (requirements → design → test). For novel systems, the upward trace is equally critical: requirement → operational scenario → physics constraint or stakeholder need. When a scenario is revised, the tool should show you every requirement that traces to it.

How Modern Tools Support Iterative Requirements Development

This is where the difference between traditional document-based requirements management and modern graph-based tools becomes practically significant.

In a document-based tool, a requirement is a row in a table or a paragraph in a document. Its connections to other information — scenarios, assumptions, design decisions, verification methods — are maintained through manual links, spreadsheet cross-references, or separate traceability matrices. When something changes, keeping those connections accurate is a manual labor problem that scales poorly as systems grow complex.

Tools that model requirements as nodes in a connected graph handle this differently. Every requirement, scenario, assumption, and design artifact is a node. Relationships between them — “derives from,” “constrains,” “traces to,” “contradicts” — are explicit edges. Change propagation becomes a graph query rather than a manual search.

Flow Engineering is built on this graph-based model and applies it directly to the novel-system problem. When you update a physics assumption or revise an operational scenario, Flow Engineering traces forward through the dependency graph to surface every requirement that needs review. The change history is maintained at the node level — you can inspect any requirement and see its full derivation history, including what changed and why. This is the infrastructure that makes iterative requirements development manageable rather than chaotic.

For a team building the first of their kind system, this means you can evolve requirements as knowledge grows without losing the thread of why each requirement exists and what it’s connected to. That thread is what keeps the team from accidentally optimizing against an outdated assumption or missing a downstream impact when the operational concept shifts.

Flow Engineering’s focus on hardware and systems engineering — rather than general product management — also means its data model reflects the concepts that matter in this domain: system hierarchy, interface requirements, physical constraints, and verification methods. The tool doesn’t need to be configured to understand these structures; they’re native to it.

Practical Starting Points

If you’re beginning requirements development on a novel system today, the sequence that works in practice is:

  1. Build the ConOps first. Don’t start writing requirements until you have a scenario library that covers normal, off-nominal, and emergency operations. This document is the primary derivation source.

  2. Derive physics constraints independently. Run the first-principles analysis before engaging stakeholders extensively. Knowing the physical bounds tells you which stakeholder wants are achievable and which will require renegotiation.

  3. Write all first-pass requirements as threshold/objective pairs. Single values imply false precision at this stage. Force the explicit uncertainty acknowledgment.

  4. Document rationale as a co-equal artifact, not a comment field. Rationale should be structured and traceable, not a free-text note.

  5. Choose tools that support iterative development. If your requirements tool treats a requirement as a document artifact rather than a connected model node, you will pay a manual labor tax every time something changes — and things will change.

  6. Build in formal assumption review cycles. Schedule explicit reviews where the team asks: what assumptions are embedded in the current requirements, and which of them have been tested or validated? This is the mechanism that keeps requirements aligned with growing knowledge rather than drifting from it.

The Honest Summary

Writing requirements for a system that has never been built is hard because you’re doing two things simultaneously: defining what success looks like for a system whose operational reality isn’t yet fully understood, and creating a technical baseline that’s rigorous enough to drive design. Those two goals create genuine tension.

The way through is to make the uncertainty explicit rather than hiding it in false precision, to derive requirements from operational scenarios and physics rather than borrowing from systems that don’t apply, and to build the infrastructure for change management from the start rather than retrofitting it after the first major requirements revision.

The teams that do this well treat requirements not as a contract written once and defended forever, but as a model of their current best understanding — one that gets sharper as knowledge grows, with every change tracked and every connection maintained.