Every failed unmanned systems program I have encountered — and there have been a number — shares a common root cause: the engineering started before the requirements were clear. Not necessarily before they were written, but before they were actually understood. This module is about the work that happens before any CAD model is opened, before any component is ordered, and before any configuration is selected. Done well, it is the work that makes everything downstream faster and cheaper. Skipped, it is the most expensive mistake in the development cycle.

What a requirement actually is

A requirement is not a wish, a preference, or a design feature. It is a precisely stated, measurable, verifiable constraint on system behavior or performance. The distinction matters enormously in practice.

"The vehicle should be easy to transport" is not a requirement. "The vehicle, with all ground support equipment, shall fit within a standard full-size pickup truck bed without disassembly" is a requirement. The second version is verifiable — you either fit or you don't. The first version will mean different things to the customer, the designer, and the test engineer, and that divergence will surface at the worst possible moment: during acceptance testing.

Requirements use the word shall for mandatory constraints and should for desirable but negotiable objectives. This is not bureaucratic pedantry. It is the mechanism by which a design team knows what is non-negotiable and what can be traded away when the schedule compresses or the weight budget runs over.

The three levels of requirement Every well-structured program has at least three levels. Mission requirements describe what the system must accomplish operationally — "detect, identify, and track surface contacts within a 5 km radius." System requirements translate mission capability into measurable system performance — "the EO/IR payload shall detect a 2.3 m surface vessel at a minimum range of 5 km under clear-sky conditions." Subsystem requirements allocate system performance to individual components — "the gimbal shall maintain boresight alignment to within ±0.5 mrad RMS during 15-knot wind disturbances." Each level is verifiable on its own terms.

The CONOPS — Concept of Operations

Before requirements can be written, someone must describe the operation: what the system does, who operates it, where, under what conditions, and with what support infrastructure. This is the Concept of Operations — CONOPS — and it is the most important document in any program, precisely because it is written before any engineering decisions are made.

A well-written CONOPS answers the following questions without ambiguity:

Every answer to these questions becomes a constraint — and constraints, properly formalized, become requirements. The CONOPS is not a bureaucratic deliverable. It is the translation layer between what the customer needs and what the engineer designs.

Trade studies: choosing between competing solutions

Once the CONOPS is written and requirements are drafted, the design team faces choices. A trade study is the formal method for evaluating competing options against weighted criteria — it is how engineering teams make defensible decisions instead of defaulting to familiar technology or the loudest voice in the room.

The trade study process is straightforward in principle: identify the options, define the evaluation criteria, weight the criteria by their importance to the mission, score each option against each criterion, and select the option with the highest weighted score. The difficulty lies in the weighting, because weighting criteria forces an explicit conversation about priorities that many teams prefer to avoid.

Example: airframe configuration trade study for a coastal ISR mission
Mission context: 4-hour endurance ISR, 2 kg EO/IR payload, BVLOS, truck-portable, 2-person crew, 20-knot operating wind limit.
Options considered: Fixed-wing conventional (A), Multirotor (B), Hybrid VTOL fixed-wing (C).
Criteria and weights: Endurance (30%) · Portability (20%) · Wind tolerance (20%) · Payload capacity (15%) · Crew workload (15%).
Scoring (1–5): Fixed-wing: 5/3/4/3/3 = weighted 3.90. Multirotor: 2/4/2/4/5 = weighted 3.05. Hybrid VTOL: 4/3/4/4/3 = weighted 3.70.
Selection: Fixed-wing wins on endurance and wind tolerance — the two highest-weighted criteria for this specific mission. If the mission were urban building inspection (requiring hover), multirotor would score higher. The configuration serves the mission, not the designer's preference.

Requirements hierarchy and traceability

The requirements developed from the CONOPS are not a flat list. They form a hierarchy — a tree in which every lower-level requirement exists to satisfy a higher-level one, and every higher-level requirement is satisfied by one or more lower-level ones. This is called requirements traceability, and it is the mechanism by which a test engineer can answer the question: "Does this test prove that the system meets this mission requirement?"

In practice, traceability is maintained in a requirements traceability matrix (RTM) — a table that maps each requirement to its parent requirement above and its verification method below. The verification methods are four in number, and choosing the right one matters:

The V-model: designing verification in from the start

The V-model is a systems engineering development framework that places verification planning at the same stage as design decomposition. Its power lies in a simple insight: the requirements you write today determine what tests you must run at the end of the program. If you write requirements that cannot be verified, you have designed a program that cannot be completed.

The left arm of the V descends from mission requirements through system requirements, subsystem requirements, and component specifications — this is the design decomposition phase. The right arm ascends from component testing through subsystem integration testing, system testing, and operational validation — this is the verification phase. The two arms are connected horizontally: each level of design on the left has a corresponding level of verification on the right, and the connection is drawn before the design work begins.

In a 65-day design-to-test program — which is a realistic timeline for a Group-1 or Group-2 UAV — you cannot afford to discover on Day 60 that a requirement is unverifiable. The V-model forces that discovery on Day 1, when something can still be done about it.

The most common requirement failure mode Requirements that use subjective, unmeasurable language. "High reliability," "good performance," "adequate range," "easy to operate" — none of these can be verified, which means none of them can be delivered with confidence. If a requirement cannot be written in terms that would allow two engineers to independently agree on whether it has been met, rewrite it until it can.

A worked example: from operational need to engineering specification

The following example traces the full chain from a customer's initial request to a set of verifiable engineering requirements. This is representative of how a real program begins.

Customer statement: "We need a drone for coastal surveillance. It needs to stay up for a while, carry a camera, and be something a small team can operate from a truck."

This contains exactly four pieces of useful information: coastal (operating environment), surveillance (mission type), camera (payload type), small team from a truck (crew and logistics). Everything else is undefined. The engineering team's first job is to make the undefined explicit.

Requirement development chain
Operational need: "Stay up for a while" → CONOPS clarification: 6-hour patrol cycle, 2 launches per day, 30-minute turnaround → System requirement: "The vehicle shall achieve a minimum endurance of 6.5 hours at cruise speed carrying the baseline payload at sea level standard conditions."
Operational need: "Carry a camera" → CONOPS clarification: detect vessels to 5 km, identify to 2 km, day and night, stabilized gimbal → System requirement: "The payload bay shall accommodate a sensor package of no more than 2.5 kg and 8 W continuous power draw, with a stabilized two-axis gimbal capable of ±30° azimuth and -90° to +15° elevation."
Operational need: "Small team from a truck" → CONOPS clarification: 2-person crew, no launch equipment, airstrip not available → System requirement: "The system shall be hand-launchable or catapult-launchable by a crew of two without fixed infrastructure. All system components, including GCS and recovery equipment, shall be transportable in a standard full-size pickup truck without disassembly."
Derived from logistics: "Small team" also implies maintenance burden → System requirement: "The vehicle shall require no special tooling for field replacement of the propulsion unit, wing panels, or avionics bay. All field-replaceable components shall be swappable in under 15 minutes with standard hand tools."

What this looks like on a real program

On a 65-day program — the timeline for the Group-2 UAV built for ADUSEA — the requirements and CONOPS phase occupied roughly the first five days. That may sound like too long given the total schedule, but those five days produced the configuration trade study that selected fixed-wing over multirotor, the payload interface specification that drove the avionics bay dimensions, and the logistics requirement that mandated hand-launch — which in turn drove the maximum takeoff weight to a value that could realistically be achieved in the available structural weight budget.

Compressing this phase does not save five days. It costs them — usually on Day 55, when an integration problem is discovered that traces directly back to an assumption that was never written down, challenged, or agreed to.

The modules that follow cover each phase of the design-to-test process in the order it actually occurs. Module 02 takes the configuration decision made in the trade study and develops it into a full aerodynamic design. But before any of that is productive, the requirements must be right. A fast answer to the wrong question is still the wrong answer.