Requirements Engineering for Attritable Uncrewed Systems: When ‘Good Enough’ Is the Spec

The phrase “good enough to complete the mission” sounds like an engineering compromise. In attritable uncrewed systems, it is the engineering objective. That distinction changes almost everything about how requirements are written, how verification is structured, and what constitutes a successful program.

Attritable platforms occupy a specific cost band — roughly $2M to $20M per unit, depending on who’s defining the term this week — where the vehicle is affordable enough to expend in high-threat environments but expensive enough to still require real systems engineering. They are not cheap commercial drones. They are not F-35s. They are something new, and the requirements frameworks inherited from both worlds fit them badly.

The Cost Ceiling as a First-Class Requirement

In conventional aerospace programs, cost is a program management concern. It surfaces in acquisition documents, it drives trade studies, and it informs design decisions — but it is rarely written into the system requirements specification as a hard constraint at the same level as range, payload, or survivability.

Attritable programs flip this. The unit cost target is not downstream of the requirements; it is upstream of them. If a proposed capability drives the unit cost above the affordability ceiling, that capability gets cut or re-scoped. The cost constraint is load-bearing.

This creates a requirements writing challenge that legacy tools and legacy processes handle poorly. In a document-based requirements management environment — IBM DOORS being the canonical example — cost typically lives in a program office spreadsheet or a separate affordability analysis, loosely coupled to the technical requirements in the SRS. Engineers track the connection manually, through meeting notes and tribal knowledge. When the cost constraint forces a requirements change, the traceability between “why this requirement changed” and “what it connects to” degrades fast.

The XQ-58 Valkyrie program, developed by Kratos and AFRL under the Low Cost Attritable Strike Demonstrator (LCASD) initiative, was explicit about the $3M unit cost target being the governing constraint from day one. Every subsystem trade — propulsion, avionics, airframe materials — was evaluated against that ceiling. The program achieved first flight in 2019 and has since demonstrated a cost-performance profile that validated the attritable concept for USAF planning purposes. But publicly available program documentation suggests the requirements management approach leaned heavily on informal tradeoff coordination rather than structured bidirectional traceability. That works when the team is small and co-located. It gets fragile as programs scale or transition to production.

What ‘Mission Success Probability’ Does to Verification

Conventional aerospace reliability requirements are written in terms of MTBF, MTBCF, or availability over an operational life measured in flight hours or years. A requirement might read: “The propulsion system shall achieve a mean time between critical failure of no less than 2,000 flight hours.” This drives a verification approach built around accelerated life testing, component qualification testing, and statistical sampling across production lots.

Attritable platforms have operational lives measured in single-digit flight hours. Some are explicitly one-way. The relevant metric is not MTBF — it is mission completion probability (MCP): the probability that the vehicle completes its assigned mission profile before either achieving its objective or being expended.

That sounds like a softer standard. It is not. Writing a defensible MCP requirement is harder than writing an MTBF requirement, because MCP is a system-level emergent property that depends on threat environment, mission profile variability, subsystem interdependencies, and engagement geometry. An MTBF requirement can be verified at the component level through bench testing. An MCP requirement cannot. It requires simulation, hardware-in-the-loop testing, and probabilistic analysis across representative mission scenarios.

For programs operating in the attritable cost band, this creates a verification resourcing tension. You cannot run 500 flight test sorties to statistically validate MCP. You run a handful of demonstration flights and rely on validated simulation models for the rest. The requirements document has to be written to acknowledge this: verification methods that would be “Test” in a conventional program become “Analysis” or “Similarity” in an attritable program, and the basis for those analysis methods has to be documented somewhere.

This is where programs get into trouble. The shift from Test to Analysis as the primary verification method is legitimate — it is accepted in MIL-STD-3031 and related guidance — but it requires that the analysis tools and assumptions be traceable to the requirements they are verifying. In practice, that traceability often exists in slide decks and engineering notebooks rather than in the requirements management system.

Kratos and the Emerging Attritable Engineering Culture

Kratos Defense has built its uncrewed systems business around the attritable concept more deliberately than almost any other prime. Their UCAV portfolio — including the XQ-58 (developed with AFRL), the UTAP-22 Mako, and more recent programs under Air Force and Navy contracts — reflects a manufacturing-first philosophy where producibility is a design requirement from day one, not a late-program concern.

The Kratos approach involves significant reuse of commercial and modified commercial components where those components meet the MCP requirements for the mission profile. This is certification-light in a specific sense: it is not that Kratos forgoes requirements rigor, but that the qualification basis is mission-envelope specific rather than spectrum-wide. A component that cannot survive 30-year airframe life or extreme arctic storage does not need to. If it survives the mission envelope with sufficient probability, it passes.

This approach requires requirements authors to write bounded requirements — requirements that explicitly scope the operational envelope the system must perform within. “The fuel system shall operate reliably across ambient temperature ranges of -20°C to 50°C” is a bounded requirement. “The fuel system shall operate reliably across MIL-STD-810 full environmental suite” is not. The difference seems semantic until you reach verification: the bounded requirement is verifiable within program resources, the unbounded requirement is not.

Writing bounded requirements correctly is technically demanding. It requires knowing the likely operational environments well enough to scope them without being so narrow that the vehicle fails in the field under conditions the requirements author didn’t anticipate. Getting that scoping wrong is one of the primary technical risks in attritable program requirements.

Swarm Platforms and the Emergent Behavior Problem

Individual attritable UCAVs are engineering challenges. Swarm systems are a different category of problem.

DARPA’s OFFSET program, the Air Force’s Collaborative Combat Aircraft (CCA) initiative, and various classified programs under development are all grappling with a fundamental requirements writing problem: emergent swarm behavior cannot be fully specified at the vehicle level. The interaction of 50 or 200 or 1,000 autonomous agents in a contested environment produces system-level behaviors — coordination patterns, target prioritization decisions, airspace deconfliction — that are not the property of any individual vehicle.

This creates a gap between how requirements are conventionally structured (as properties of a defined system with a defined system boundary) and what actually needs to be specified and verified. You can write requirements for the autonomous behavior algorithms of a single vehicle. You can write requirements for the communication protocol between vehicles. But writing requirements for “the swarm shall achieve 70% target coverage within 15 minutes of ingress” requires a different unit of analysis — the swarm as the system, with individual vehicles as components.

Requirements documents for swarm programs that treat the individual vehicle as the system boundary will miss critical verification areas. The swarm-level behaviors need to be specified, traced to vehicle-level capabilities, and verified through swarm-scale simulation or live testing. This requires a requirements architecture that supports multiple levels of system hierarchy with explicit traceability between levels.

Document-based tools — DOORS, Word-based SRS documents — handle flat or two-level hierarchies reasonably well. They handle multi-level hierarchical requirements with emergent cross-level behaviors poorly. The traceability structure becomes a rat’s nest of manual links that breaks the moment a vehicle-level requirement changes.

What Certification-Light Actually Means

“Certification-light” is used loosely in discussions of attritable systems, and the looseness causes confusion. It is worth being precise.

What attritable programs are not doing: abandoning requirements rigor, skipping functional hazard analysis, or flying hardware with no verification basis. Programs operating in contested airspace with explosive payloads cannot take a genuinely casual approach to safety and remain legally defensible or operationally credible.

What attritable programs are doing: scoping the certification basis to the operational envelope rather than the full aerospace qualification envelope; accepting Analysis and Similarity as primary verification methods where Test would be required for manned systems; moving verification into the field through progressive live-test campaigns rather than lab qualification suites; and relying on design margins and redundancy to manage residual uncertainty rather than exhaustive statistical qualification testing.

The FAA small UAS (Part 107) framework, while not directly applicable to defense systems, influenced how some commercial-off-the-shelf components in attritable vehicles are treated. MIL-STD-882 (system safety) remains fully applicable and is not relaxed in attritable programs — the hazard analysis has to happen, but the design responses to identified hazards are evaluated against the operational context rather than against peacetime or commercial aviation standards.

How Modern Requirements Tools Handle Attritable Complexity

The requirements challenges of attritable programs — cost as a first-class constraint, mission-envelope bounded requirements, multi-level swarm architectures, Analysis-based verification — are all tractable. They require tooling that can model relationships and constraints, not just store text.

Document-centric tools like IBM DOORS or legacy DOORS Next installations treat requirements as structured text. Relationships between requirements, between requirements and cost targets, between vehicle-level and swarm-level specifications, are managed through manual traceability links. Those links can be created and maintained, but the semantic meaning of the relationship — “this requirement was bounded specifically because of the $4M unit cost constraint” — is not captured. It lives in someone’s head or in a program office briefing.

Graph-based requirements platforms model the relationships themselves as first-class objects. A cost constraint node can be connected to every requirement it bounds, with the relationship type and rationale captured explicitly. When the cost target changes — as it does in nearly every attritable program during source selection — the downstream requirements that need re-evaluation are immediately visible.

Flow Engineering is one of the tools built on this architecture. Designed for hardware and systems engineering teams rather than document management, it models requirements as connected nodes in a graph rather than paragraphs in a document. For attritable program teams working with cost-constrained requirements, multi-level swarm hierarchies, and rapid design iteration, the ability to query “what requirements are affected by this cost target change” or “what vehicle-level capabilities trace to this swarm-level performance requirement” without manually tracing through a requirements document is operationally significant. The tool’s AI-native architecture also supports rapid requirements generation and gap analysis — useful when programs are moving fast and requirements documents need to evolve in days rather than weeks.

The limitation worth naming: Flow Engineering, like most modern SaaS requirements platforms, is less mature in the formal qualification evidence packaging that some defense contracts require. Programs with formal DO-178C or ARP4754A deliverables may need supplemental tooling or process artifacts. For the attritable program space — where formal civil aviation qualification frameworks are explicitly not the model — this is generally not a binding constraint.

The Honest Assessment

Attritable uncrewed systems programs are producing real hardware that flies and, in some cases, has been used operationally. The engineering approaches they have developed — cost-bounded requirements, mission-envelope scoping, analysis-heavy verification — are legitimate adaptations to a real constraint set, not shortcuts.

The risk is that “certification-light” becomes a cultural permission slip for undisciplined requirements practice. The cost constraint is real. The schedule pressure is real. But the answer to those pressures is targeted, well-scoped requirements and efficient verification — not thin requirements and informal traceability.

Programs that get this right are investing in requirements architecture that can evolve with the design, track the cost-performance tradeoffs explicitly, and support simulation-based verification with auditable analysis chains. Programs that get this wrong have requirements documents that do not reflect the actual design, verification matrices that are maintained in arrears, and cost growth that cannot be traced to specific technical decisions.

The attritable concept works. The engineering challenge is making sure the requirements practice that supports it is as deliberately designed as the platform itself.