Communicating radar requirements to a supplier is not just a purchasing formality. The quality of the supplier’s proposal depends heavily on the quality of the requirement brief. If the buyer only asks for “a radar that detects drones at 5 km,” the supplier has to guess the target, site geometry, clutter, interfaces, alarm workflow, and acceptance conditions.
A better brief gives the supplier enough context to propose an architecture, state assumptions, identify risks, and explain what can be proven. The goal is not to make the document longer. It is to make the engineering question clearer.
Start With the Mission Outcome
Begin with what the system must help you accomplish. A supplier can respond more usefully to “detect and track low-altitude drones approaching a stadium during major events and cue EO/IR confirmation within the security operations center” than to “quote a drone radar.”
Describe:
- the protected asset or area;
- the event or behavior that matters;
- why the radar layer is needed;
- the response time or warning time that matters;
- who will use the information;
- and what decision the system should support.
This helps the supplier understand whether the project is about early warning, perimeter awareness, temporary event security, evidence collection, camera cueing, or multi-sensor fusion.
Define Targets and Operating Scenarios
Radar performance depends on the target. A small multirotor drone, a fixed-wing UAV, a bird, a person, a vehicle, and a small boat are not the same sensing problem. Even within drones, size, speed, altitude, material, payload, and flight behavior change performance.
Provide target assumptions such as:
- target classes of concern;
- typical altitude and speed ranges;
- expected approach routes;
- hovering, crossing, or direct approach behavior;
- cooperative or non-cooperative targets;
- RF-emitting or RF-silent assumptions;
- and which targets are nuisance objects rather than threats.
If you are unsure, say so. A good supplier should help refine assumptions instead of pretending that one range number covers every target.
Share the Site Context
Site context often changes the answer more than the radar model. Provide drawings, maps, photos, and notes when possible.
Useful site information includes:
- protected zones and boundaries;
- candidate mounting points;
- roof, mast, tower, or trailer options;
- building heights, terrain, vegetation, water, roads, cranes, or large metal structures;
- known clutter sources;
- power and network availability;
- grounding and lightning constraints;
- maintenance access and safety restrictions;
- expected operating schedule.
If the site is not final, share the current uncertainty. The supplier can then propose options instead of locking the project into a false assumption.
Specify Outputs and Workflow
Radar requirements should describe what the operator needs to receive, not only what the sensor can detect.
Clarify whether the system must provide:
- target position, height, speed, heading, and track history;
- map display and alarm zones;
- EO/IR camera cueing;
- RF or Remote ID correlation;
- event logs and replay;
- export formats;
- integration with VMS, C2, PSIM, or customer software;
- local and remote operator views;
- user roles and audit records.
This prevents a common mismatch: the supplier delivers a working radar, but the customer expected an integrated operating picture.
Be Clear About Constraints
Suppliers need constraints as much as desired features. Constraints shape the design and the price.
State:
- budget or budget range if available;
- delivery schedule;
- export or import requirements;
- preferred power and network options;
- environmental conditions;
- installation limits;
- cybersecurity requirements;
- language and documentation needs;
- training expectations;
- maintenance and support model.
If a constraint is non-negotiable, label it as such. If it is only a preference, label it as a preference. This helps suppliers propose realistic alternatives.
Separate Must-Have, Should-Have, and Optional Items
Not every requirement has the same weight. A clean requirement brief separates:
- must-have items that define project success;
- should-have items that strongly improve value;
- optional items that can be priced as alternatives;
- assumptions that need supplier confirmation;
- open questions that require engineering discussion.
This structure makes the supplier response easier to compare. It also reduces the chance that a proposal looks compliant by treating optional items as if they were mandatory or by ignoring critical items hidden in general text.
Ask for Assumptions and Evidence
A strong supplier response should not only list a product model. It should state the assumptions behind the recommendation.
Ask the supplier to explain:
- which target assumptions the proposal is based on;
- which site conditions may limit performance;
- what detection, tracking, or alert ranges mean;
- what requires site survey or simulation;
- what can be proven in FAT;
- what must be proven in SAT;
- what integrations are included or excluded;
- what support is included after deployment.
This is where vague marketing claims become engineering commitments.
Include Acceptance Criteria Early
Acceptance should not be invented at the end of the project. Communicate early how success will be judged.
A practical acceptance model can include:
- FAT checks for hardware, software, interfaces, logs, and documentation;
- SAT checks for site coverage, blind spots, live or representative targets, alarm zones, camera cueing, event export, and operator workflow;
- required evidence such as screenshots, logs, track exports, and test records;
- treatment of known site limitations;
- and how deviations will be closed.
If the supplier cannot agree to an acceptance concept, the gap should be discussed before purchase, not after installation.
A Simple Requirement Brief Template
A useful supplier brief can be as simple as:
- Project objective and protected site.
- Target types and operating scenarios.
- Protected zones, maps, and site photos.
- Candidate mounting locations and constraints.
- Required outputs and integrations.
- Power, network, cybersecurity, and documentation needs.
- Delivery schedule and logistics constraints.
- Must-have, should-have, and optional requirements.
- FAT and SAT expectations.
- Questions the supplier must answer.
This is enough to start a serious technical conversation.
Common Poor Briefs
Avoid requests such as:
- “Please quote your best radar.”
- “We need 5 km detection, send price.”
- “Detect all drones in all weather.”
- “We will discuss site details after purchase.”
- “Supplier to ensure everything works.”
These phrases sound simple, but they force the supplier to guess. Guessing creates risk, and risk usually becomes cost, delay, or acceptance conflict.
Conclusion
The best way to communicate radar requirements to a supplier is to describe the mission, the site, the targets, the operator workflow, the integration needs, and the acceptance standard in plain engineering terms. You do not need to solve every design problem before talking to suppliers, but you should give them enough context to make assumptions visible.
When requirements are communicated clearly, supplier proposals become easier to compare, performance claims become easier to test, and the project is less likely to discover major misunderstandings during installation or acceptance.