How to Brief a Custom UAV Development Project

Describe the task before selecting a configuration

Start with the work the UAV must perform and the environment in which it will operate. An inspection, mapping, monitoring or research task can place different demands on the platform. State what success means for the operator and which constraints are already fixed.

Record whether you are commissioning a new aircraft, adapting an existing platform or asking for help with a specific integration failure. Include the intended countries of operation and who will own the operational approvals. This is a development brief, not a substitute for an operating or certification review.

Put the payload at the centre of the brief

List the payload mass, dimensions, mounting needs, power input and data interfaces. Explain whether it is already selected or still a design choice. Include any onboard processing and operator display requirements that come with it.

Separate required values from preferences. A payload that is still changing should be marked as an open decision, because it can change the design boundary for the airframe, power system, avionics and software. Include reference documents only when you have permission to share them.

Write measurable endurance and navigation objectives

Describe the mission duration and duty cycle with the payload attached, rather than asking for a headline endurance number alone. State relevant operating assumptions and identify how the target will eventually be evaluated.

For GPS-denied applications, explain where satellite positioning is unavailable and the required behavior in that area. For communication or anti-jamming requirements, describe the evaluation objective at a non-confidential level. These are system requirements to investigate and validate, rather than universal properties of an aircraft configuration.

Identify the existing hardware and software

Include the flight controller, firmware version, sensors, radio, ground control software and companion computer where known. Note custom modifications and identify which components are maintained by your own team.

If you are reporting an integration problem, describe what worked before the change, what changed and what evidence can reproduce the issue. Share a summary first; detailed design files, logs and credentials do not belong in a public enquiry form.

Agree the engineering handover

A proposal should make clear whether the deliverable is a review, a design package, firmware changes, an integrated prototype or a broader development partnership. Ask which files, source code, build instructions and test records are included.

Define acceptance criteria and the owner of each test activity. Distinguish a bench demonstration, a platform integration test and any later operational validation. Record assumptions, open issues, exclusions and technology-transfer terms alongside the delivery milestone.

Project brief checklist

• Mission, operating environment and intended countries
• Payload mass, dimensions, power and data connections
• Required endurance with operating assumptions
• Navigation availability and communication requirements
• Current hardware, firmware and integration status
• Required deliverables, ownership and acceptance evidence
• Target milestone and access to test hardware