How Do You Scope a Requirements Baseline for a First-of-Kind System?

There is a version of this question that engineers ask politely in program reviews, and a version they ask at 11 PM when the schedule has just been cut by six months. Both versions deserve the same answer: scoping a requirements baseline for a first-of-kind system is a structured act of disciplined reasoning under uncertainty, not a documentation exercise that follows design.

Novel energy systems—fusion reactors, high-altitude hydrogen fuel cells, grid-scale flow batteries—have no certified predecessors. Experimental aircraft like high-altitude pseudo-satellites or electric vertical takeoff and landing vehicles with distributed propulsion are writing their own certification basis as they fly. New space mission classes, from in-space servicing vehicles to crewed lunar surface systems, operate in domains where the requirements landscape is simultaneously under-defined by standards bodies and over-constrained by physics. In all three domains, the question is the same: how do you draw a defensible boundary around what the system must do before you fully understand what the system is?

This article walks through the mechanisms that actually work, with examples drawn from each domain.

The ConOps Is Not a Narrative. It Is an Anchor.

The Concept of Operations is frequently written as a story: “The vehicle departs the launch site, enters a parking orbit, and…” That narrative form serves communication. It does not serve requirements scoping. To anchor a baseline, a ConOps must be written as a structured enumeration of states, transitions, actors, and constraints.

For a first-of-kind system, the ConOps is the only external reference that is not borrowed from another program. Everything else—design heritage, certification precedent, supplier history—is either absent or weakly applicable. The ConOps is what you own. It describes how the system will be used, by whom, under what conditions, and to what end. Every requirement that cannot be traced back to at least one ConOps element is either speculative or inherited from somebody else’s system.

Example: Novel Energy Systems

Consider a 50 MW direct-current ocean-current energy converter—no commercial precedent, no grid code directly applicable, no maintenance vessel class certified for the installation depth. The ConOps for such a system must enumerate: the grid interconnection states (startup, steady generation, frequency response, islanded fault mode, shutdown); the maintenance operational concept (remotely operated vehicle access, diver exclusion zones, surface vessel constraints); and the environmental loading conditions considered credible versus those considered beyond design basis. Each of these ConOps elements generates a cluster of requirements. Without the ConOps, engineers write requirements about the system’s internal behavior and miss entire external interface categories—because there is no prior system to remind them those interfaces exist.

Example: Experimental Aircraft

A high-altitude, solar-electric unmanned aircraft operating at 65,000 feet for 90-day continuous missions has essentially no directly applicable airworthiness certification path. The FAA’s special class regulations (14 CFR Part 21.17(b)) require the applicant to propose the airworthiness criteria. The ConOps, in this case, must be specific enough to bound the airworthiness criteria proposal itself. If the ConOps says “the aircraft operates in Class A and RVSM airspace” but does not specify the traffic density assumptions, the navigation performance requirements cannot be set. The ConOps must go down to the level of: what does this system actually do, hour by hour, and what can go wrong at each step?

Example: New Space

NASA’s Artemis lunar surface systems—habitats, pressurized rovers, power generation assets—are first-of-kind in the sense that no human has used a lunar surface system of any kind since 1972. The ConOps for these systems must distinguish between nominal operations, degraded operations, and emergency operations, because the requirements for each class are structurally different. A nominal power system requirement might be “shall provide 10 kW continuous during crew surface operations.” An emergency requirement might be “shall sustain crew life support for 72 hours following loss of primary generation.” These are different in verifiability, in margin philosophy, and in how conservatively they must be stated. Without a ConOps that distinguishes between those operational modes, a team will collapse them into a single requirement that is simultaneously too loose in nominal operation and dangerously under-specified in emergency.

Functional Decomposition: Top-Down Structure Before Architecture Exists

Functional decomposition is the mechanism by which a system-level need becomes a tractable set of lower-level requirements without requiring a finalized architecture. For first-of-kind systems, this is essential, because the architecture is not known when the baseline must be set.

The discipline here is to decompose functions, not components. “The system shall generate power” decomposes to: capture energy from the source, convert it to electrical energy, regulate output to grid specification, store excess, and manage fault states. Each of those functions carries independent performance, interface, and reliability requirements. The physical elements that perform those functions are determined later. This ordering—function before form—lets requirements precede architecture.

Practical mechanism: Build a functional hierarchy with at least three levels before connecting any function to a physical element. The top level states what the system accomplishes for the user or mission. The second level states the major functional groupings the system must perform. The third level states the performance requirements on each function, including boundary conditions. Only at that point do you begin allocating functions to candidate physical elements—and even then, you mark the allocation as tentative until PDR.

This discipline breaks down in practice in two predictable ways. First, teams skip levels: they jump from “the aircraft shall achieve 65,000 feet” directly to “the wing structure shall carry 3.2g at maximum takeoff weight,” bypassing the aerodynamic performance function entirely. When the wing geometry changes, the structural requirement is orphaned. Second, teams decompose hardware instead of functions: they create a requirements hierarchy that mirrors the WBS rather than the functional architecture. The result is requirements that are physically bounded but operationally incomplete—they describe the component but not the system behavior the component must produce.

Marking Assumptions: The Most Neglected Discipline in Novel System Requirements

Every first-of-kind requirements baseline contains assumptions disguised as requirements. The difference between a requirement and an assumption-wrapped requirement is whether the underlying fact has been verified or merely asserted.

A requirement that reads “the electrolyte shall withstand a thermal cycling environment of -40°C to +85°C over 10,000 cycles” is a real requirement only if the thermal environment characterization has been verified. If that temperature range came from a desktop analysis using conservative estimates of the deployment site, it is an assumption. The requirement is real, but its basis is not. If the assumption is wrong—if the actual environment is more severe—the requirement will pass acceptance testing and then fail in operation. No amount of requirements management process recovers from that.

The operational convention for marking assumptions should be explicit and visible:

  1. Tag every requirement whose performance target or boundary condition derives from an analysis not yet validated by test, simulation above TRL 5, or operational data from a comparable system.
  2. Record the assumption explicitly in a linked assumption field, not buried in a rationale comment. The assumption statement should be falsifiable: “Assumed maximum ambient temperature at installation site is 35°C based on NOAA 99th-percentile data for the Gulf of Mexico, not site-specific survey.”
  3. Assign a verification plan to the assumption itself. When will the assumption be validated? By what method? What happens to the requirement if the assumption is invalidated?
  4. Flag assumption-dependent requirements in stakeholder reviews as a distinct category with their own maturity signal. A requirement that has been agreed-to but whose basis is unverified is not in the same health state as a requirement that has been derived from confirmed operational data.

Example: New Space

The lunar south pole power system requirements developed for Artemis surface missions carry numerous assumptions about the illumination environment—specifically, the fraction of time a given ridge crest maintains line-of-sight to the sun across a full lunar year. These assumptions are based on orbital topographic models, not surface-truth measurements. Requirements written against those models must carry explicit assumption tags, because when surface measurements become available, some requirements will need to be revised. If those tags don’t exist, a future engineer reviewing the baseline sees a confident requirement with no indication that its basis is still provisional.

The Iterative Nature of First-of-Kind Requirements Development

The waterfall mental model—requirements set, then design, then build, then test—is wrong for every engineering program and catastrophically wrong for first-of-kind systems. Requirements for novel systems mature iteratively through at least three mechanisms:

Design feedback. As the design matures, it reveals constraints that the requirements did not anticipate. A hydrogen fuel cell system designed against a requirements baseline that specified 95% efficiency will, during thermal modeling, generate design feedback that the efficiency target and the waste heat management requirement are in tension at the assumed operating pressure. That tension must be resolved by revisiting the requirements, not by hiding it in a design margin.

Assumption validation. As early testing, analysis, and site surveys complete, assumptions embedded in requirements are either confirmed or invalidated. Each invalidation triggers a requirements revision. The baseline must be structured to absorb those revisions without losing the traceability that connects the revised requirement to the original ConOps element.

Regulatory and customer evolution. For novel system classes, the certification basis and customer requirements are themselves under development during the program. The FAA’s emerging framework for Advanced Air Mobility, for example, has evolved substantially since the first eVTOL programs began. A requirements baseline that was set against an early draft of those criteria will need structured updating as the criteria mature.

The practical implication is that a first-of-kind requirements baseline should be planned for re-baselining. Not as an admission of failure, but as a program structure. Typical first-of-kind programs should plan for at least one major re-baseline between project kickoff and PDR, and at least one more between PDR and CDR. Each re-baseline should be a controlled event with full traceability to what changed, why it changed, and what downstream impacts were assessed.

How Modern Platforms Track Maturity and Confidence

Communicating baseline health to stakeholders on a first-of-kind program requires more than a requirements count and a percent-complete metric. A requirements count tells you how many requirements exist. It tells you nothing about how many of those requirements you actually trust.

Requirements maturity and confidence tracking gives each requirement an explicit health signal. Maturity describes the process state: drafted, reviewed, approved, verified. Confidence describes the epistemic state: how certain is the team that this requirement is correct, complete, and stable? These are different dimensions. A requirement can be approved (high maturity) but carry low confidence because its derivation assumes unvalidated physics. A requirement can be high-confidence but still in draft state because it is waiting for a stakeholder signature.

Tools that surface both dimensions give program managers something actionable: not “we have 1,247 requirements,” but “we have 1,247 requirements, of which 312 are assumption-dependent and 87 have low confidence flags currently under active investigation.”

Flow Engineering (flowengineering.com) implements this kind of maturity and confidence tracking natively in its graph-based requirements model. Rather than treating a requirement as a document element with a status field, Flow Engineering represents requirements as nodes in a connected model, where each node carries attributes for maturity state, confidence level, assumption linkages, and open action items. The graph structure means that when an assumption is invalidated, the platform can surface every requirement that depends on that assumption—not through a manual search, but through the model’s native connectivity.

For first-of-kind programs specifically, that connectivity is what separates a useful platform from an expensive word processor. The requirement you wrote in month two, derived from a ConOps state that has since been revised, needs to be findable. Flow Engineering’s graph model makes that traceability persistent rather than dependent on an engineer’s memory of what they linked three quarters ago.

The platform is intentionally focused on the systems engineering workflow—it does not try to replace configuration management systems or project scheduling tools. For teams that need deep integration with legacy PLM environments, that focus means integration work is required. For teams starting a first-of-kind program without legacy constraints, it means the tool is available immediately and grows with the program rather than against it.

Practical Starting Points

For a team beginning a first-of-kind requirements baseline, the following sequence is operationally sound:

  1. Write the ConOps as a state-transition model, not a narrative. Enumerate every operational state, every mode transition, every actor, and every external interface. Do not proceed to requirements until every ConOps element has been reviewed by the full technical leadership.

  2. Build a three-level functional hierarchy before allocating any function to a physical element. Treat the functional hierarchy as a living document through PDR—not as a fixed artifact.

  3. Create an assumption register as a first-class program artifact, linked to the requirements database. Every requirement derived from an unverified assumption must reference the assumption register entry. The assumption register should be reviewed at every technical review.

  4. Assign confidence levels explicitly to every requirement at the time of baselining. Low confidence does not mean the requirement should be removed—it means it should be flagged for active management.

  5. Plan for re-baselining. Build it into the program schedule. Identify the trigger events that will cause a re-baseline review: completion of major test campaigns, regulatory criterion releases, design phase transitions.

  6. Choose a requirements platform that tracks connectivity, not just content. For first-of-kind programs, the relationships between requirements, assumptions, ConOps elements, and design decisions matter as much as the requirement text itself.

Honest Assessment

First-of-kind systems punish teams that treat requirements baselining as a documentation event. The baseline is not a record of what was agreed—it is a model of what is understood, including what is not yet understood. When that distinction is embedded in the process—through structured ConOps derivation, functional decomposition, assumption tagging, and confidence tracking—the baseline becomes a useful tool for managing a program through uncertainty. When it is not, the baseline becomes a liability: a set of confident-sounding statements that nobody actually trusts, maintained because the program requires a CDR artifact rather than because the team believes it is correct.

Novel systems are hard. The requirements process does not need to make them harder.