Nuclear SMR Programs Are Creating a New Demand for Systems Engineers
Why small modular reactors are triggering a talent and tooling crisis that aerospace practices can only partially solve
The first wave of small modular reactor programs is no longer a policy discussion. NuScale’s VOYGR is working through the NRC design certification process. X-energy has DOE funding and utility partnerships. Rolls-Royce SMR is in pre-GDA assessment with the UK’s regulators. Kairos Power broke ground on a demonstration reactor in Tennessee in 2024. Across North America and Europe, somewhere between fifteen and twenty distinct SMR concepts are in active engineering development — not concept studies, not white papers, but programs with headcounts, schedules, and regulatory dockets.
Every one of them needs systems engineers. Experienced ones. And there are not enough to go around.
This article examines what SMR development actually demands from systems engineering practice, what the sector is borrowing from aerospace and defense, where that borrowing breaks down, and what the tooling landscape needs to provide to close the gap.
The Talent Gap Is Structural, Not Cyclical
The nuclear industry went through a long contraction. After Three Mile Island and Chernobyl, and then again after Fukushima, Western utilities stopped ordering new reactors. The workforce that built the existing fleet of large light-water reactors aged out. Graduate programs in nuclear engineering shrank. The systems engineering discipline that existed in organizations like Westinghouse and Combustion Engineering dispersed into retirement, defense, and oil and gas.
What remained was a maintenance and operations workforce, not a design and qualification workforce. Those are different skill sets.
Now the demand signal has reversed sharply. SMR developers are not just competing with each other for talent — they are competing with aerospace primes, defense contractors, semiconductor fabs, and grid-scale energy storage companies. All of these sectors want the same profile: someone who understands how to decompose complex system requirements, manage interface control documents, run hazard analyses, and maintain traceability from stakeholder need to physical implementation.
The talent gap will not close quickly. A systems engineer who is genuinely useful on a nuclear program typically needs three to five years of nuclear-specific context before they are operating independently. The regulatory vocabulary alone — design basis, licensing basis, defense in depth, single failure criterion, probabilistic risk assessment — takes time to internalize as engineering practice rather than compliance language.
Programs are currently bridging the gap with three strategies: hiring from aerospace and defense and running internal nuclear orientation programs, poaching from operating utilities and national laboratories, and using contractors from organizations like Kinectrics, Curtiss-Wright, and the UK’s National Nuclear Laboratory. None of these strategies is fully satisfying. The first produces engineers who know systems engineering but not nuclear. The second produces engineers who know nuclear but not modern systems engineering tooling or model-based methods. The third is expensive and creates knowledge transfer problems when contracts end.
What Makes Nuclear Systems Engineering Structurally Different
Aerospace and defense systems engineering is demanding. But SMR programs face a set of constraints that do not have clean aerospace analogues.
Regulatory citation chains are multi-layered and mandatory. A requirement on a nuclear safety system does not just trace to a design specification. It traces to the plant’s licensing basis, which traces to NRC regulatory guides, which trace to 10 CFR standards, which connect to IEEE standards for nuclear qualification. The chain is long, the citations are mandatory, and the connections must be demonstrable to a regulator during inspections. A flat requirements document with a manual traceability matrix is not adequate for this. The connections between a specific design requirement and the regulatory basis for that requirement need to be navigable and auditable.
Design life is not a program life. An aircraft program might have a 30-year design life and a 20-year development cycle. SMRs are being designed for 60 years of operation with potential life extensions to 80. Requirements written today will be the basis for maintenance decisions in 2090. This creates demands on requirements quality, version control, and change management that go beyond what most aerospace programs have dealt with. When a component is replaced 40 years from now, someone needs to be able to answer: what was this component required to do, why was it designed this way, and what was the regulatory basis for the approach?
The COTS integration problem has no aerospace equivalent. Defense avionics programs have stringent COTS qualification requirements, but the ecosystem of MIL-SPEC and DO-qualified components is mature. Nuclear has a much thinner qualified component supply chain, and the pathway to nuclear qualification for a commercial component is governed by 10 CFR 50.59, Appendix B, and IEEE Std 323. Qualifying a pressure transmitter for nuclear service — demonstrating it will function through a design basis event including the radiation and thermal environment — can cost more than the component itself. This cost distorts architectural decisions. Engineers sometimes choose less capable components that are already qualified over better components that would require qualification campaigns.
Radiation environment degrades materials in ways that other harsh environments do not. Neutron fluence embrittles reactor vessel steel on timescales that must be modeled, tracked, and managed over decades. Gamma radiation degrades polymer insulation in electrical components through mechanisms that are different from thermal aging. Qualification for nuclear service requires demonstrating performance after irradiation plus thermal aging plus seismic loading, applied in combinations that require careful test sequencing. Systems engineers writing environmental qualification requirements need to understand the physics well enough to specify the test regime correctly, or the qualification is invalid even if the component passes.
What Aerospace Practices Transfer Well
Despite those differences, aerospace and defense systems engineering provides the most useful methodological foundation available. The transfer works in several areas.
Requirements decomposition and interface management. The practice of allocating system-level requirements to subsystems, managing interface control documents between organizations, and running formal interface working groups is identical in structure to what aerospace primes do on complex programs. SMR developers who have hired from Boeing, Raytheon, or Northrop report that these engineers bring disciplined habits around interface management that the nuclear industry has historically underinvested in.
Hazard analysis methods. MIL-STD-882E and its predecessors provide a mature framework for system safety analysis that maps reasonably well to nuclear probabilistic risk assessment. FMEA, fault tree analysis, and common cause failure analysis are standard in both domains. The specific regulatory acceptance criteria differ, but the analytical methods translate.
Model-based systems engineering. MBSE adoption in aerospace was driven partly by the same problem SMRs face: complex systems with long development timescales where document-based processes create version control and consistency problems. SysML-based models that connect requirements to architecture, behavior, and test cases have proven their value on programs like F-35 and Orion. Several SMR developers are now running MBSE pilots, with varying levels of regulatory acceptance of model-based artifacts as licensing basis documents.
Configuration management discipline. The rigor around baseline management, change control boards, and engineering change documentation that mature defense programs practice is directly applicable. SMR programs that have skimped on configuration management infrastructure early are finding it painful to reconstruct when they reach regulatory review stages.
Where the Analogy Breaks Down
There are three areas where importing aerospace practice without adaptation causes problems.
Verification by analysis has limits in novel reactor physics. Aerospace programs verify many requirements through analysis rather than test, with the analysis models validated against test data. For SMR concepts with novel moderators (molten salt, liquid metal, high-temperature gas) or novel fuel forms, the validated physics models that would support verification by analysis are less mature than the models that underpin light-water reactor licensing. Regulators are skeptical of analysis-only verification for safety-significant requirements in novel reactor types, which pushes programs toward expensive integral testing they had not planned for.
The 60-year lifespan breaks standard V&V logic. A test program can verify that a component meets its requirements at the beginning of life. Demonstrating that it will continue to meet requirements after 40 years of radiation exposure requires accelerated aging test methods whose correlation to actual aging is itself a source of uncertainty. Systems engineers need to write requirements that anticipate this, including requirements for surveillance programs, inspection intervals, and retirement criteria — none of which have aerospace analogues.
Regulatory engagement is not a gate; it is a continuous process. Defense acquisition programs interact with oversight bodies at defined program milestones. NRC licensing is a continuous dialogue that begins early in development and continues through construction and operation. Requirements documents, design descriptions, and safety analyses become licensing basis documents that are legally binding once submitted. Changes to them require formal change control processes with regulatory notification or approval. Systems engineers who treat regulatory submission as a phase-end deliverable rather than an ongoing commitment to a living document set create problems for themselves that are very difficult to unwind.
What the Tooling Landscape Needs to Provide
The tooling picture in SMR programs today is varied. Some programs are using IBM DOORS Next or Jama Connect, imported from adjacent defense or medical device work. Others are still managing requirements in Word and Excel with manual RTMs, which will become untenable as programs scale toward licensing submittals. A smaller number are running purpose-built MBSE environments with Cameo or Capella as the architecture backbone.
The specific demands of nuclear regulatory traceability — multi-level citation chains, mandatory connection to regulatory basis, change history that persists across decade-long timescales — favor tools built around a graph model rather than a document hierarchy. A graph-based model can represent the connection between a specific design requirement, the regulatory guide that motivates it, the licensing basis document that commits to it, and the verification record that closes it, without forcing those relationships into a flat matrix.
Tools like Flow Engineering, which are built on graph-based requirements representation with AI-assisted traceability analysis, are starting to appear in SMR program evaluations precisely because they can represent these multi-layer citation relationships natively. The ability to ask “show me every requirement that traces to 10 CFR 50 Appendix A General Design Criterion 17” and get a navigable answer — not a spreadsheet filter — has direct value in preparation for regulatory audits and design certification reviews. Flow Engineering’s deliberate focus on hardware and systems programs rather than software requirements management is a reasonable fit for the domain, where the most important traces connect physical design decisions to regulatory commitments.
The tooling gap is not primarily about features. It is about the organizational commitment to use tools at the fidelity that nuclear programs require. Programs that buy a requirements tool and use it like a document editor get document-editor results. The discipline to decompose requirements to the level where individual requirements are verifiable, to maintain traceability continuously rather than reconstructing it before reviews, and to treat the requirements database as the authoritative source of truth rather than a report generator — that discipline is cultural, not technological.
Honest Assessment
The SMR sector will produce nuclear power plants. The economics are credible enough, the policy support is real enough, and the engineering progress is tangible enough that the first wave of SMR deployments in North America and Europe will happen within this decade. But the programs that get there will be the ones that invest early in systems engineering infrastructure — talent, process, and tooling — rather than treating it as something that can be bolted on when regulators ask for it.
The aerospace comparison is useful but should not be carried too far. Nuclear regulatory practice is its own discipline, and the engineers who have internalized it over careers in operating plants, national laboratories, and regulatory bodies are genuinely scarce. The programs that bridge this gap successfully will be the ones that pair that nuclear domain expertise with modern systems engineering methods, rather than running either in isolation.
The talent gap is structural and will not resolve in the next five years. The programs that are investing now in attracting, developing, and retaining systems engineers with genuine nuclear fluency are building a competitive advantage that cannot be replicated quickly. That is a harder problem than choosing the right requirements tool — but the tool choice matters too, because systems engineers are scarce enough that spending their time managing document forests is a cost the sector cannot afford.