European representative
Discuss a project
Service · phase 1

Defining requirements

Knowing the risk you need to avoid does not yet define what the solution must achieve. This stage turns it into technical objectives.

Three people discuss a small orange parachute sample at a table; overlay reads “50 Years of High-End Aerodynamics”

Requirements are connected

Considered separately, each requirement looks simple; in practice each one affects the wider physical system. A lower descent rate may require a larger canopy. A larger canopy can increase packed volume, soft-goods weight and opening shock. Greater opening shock may require additional load absorption, changes to mechanical components or adjustments to the platform structure.

What this stage settles

Five questions are brought together:

  • What must be protected: platform, payload, critical asset or operational area — and the damage, loss or mission interruption to be prevented.
  • What the platform can support: available space, weight limits, geometry, structural capacity, attachment points and integration conditions.
  • How the solution must perform: descent rate, sink rate, terminal velocity, opening-shock limits, stability, deployment timing, impact protection, flotation or containment.
  • Which direction fits: parachute, airbag, deceleration mechanism, deployment bag, ballistic or capture net, flotation system or another custom textile direction.
  • What can move forward into development: whether the requirement is realistic, needs adjustment or requires further technical review before design and prototype development begin.

Getting in

For new customers the initial requirements discussion is normally included as part of understanding the project and evaluating its technical scope. It therefore comes before design and development, not alongside them.

The full sequence in view

There is no single rule of thumb. The technical direction is shaped by the risk, the platform limits, the mission conditions and the level of survivability or reliability the project requires. The result is a shared understanding of what the textile solution must achieve and what the platform can realistically support — before resources are committed to development.

The review therefore covers the full sequence in which the solution must operate, including:

  • Opening shock on the canopy, textile elements and platform.
  • Canopy stability and pendulum behaviour.
  • Descent rate and terminal velocity at impact.
  • Soft-goods weight and packed volume.
  • Available space within the UAV or platform.
  • Deployment height, timing and flight dynamics.
  • Clean or turbulent airflow.
  • Payload sensitivity and structural limits.
  • Safety factor and acceptable risk.
  • Why an off-the-shelf solution does not fit.

What your team receives

Your team receives a defined technical basis for moving into design and prototype development. The goal is to reduce uncertainty before development begins, so the project moves forward from defined technical requirements rather than assumptions.

For complex programmes the work may continue through formal stages such as a System Requirements Review (SRR) or Preliminary Design Review (PDR), depending on the project scope. Depending on the project, the result can include:

  • A defined recovery or protection objective.
  • A clear understanding of the asset, payload or platform being protected.
  • Identified weight, volume, structural and airflow constraints.
  • Defined performance and deployment requirements.
  • A practical direction for the textile solution.
  • A basis for safety-factor decisions.
  • A basis for prototype, testing and validation planning.
  • Early identification of conflicting or unrealistic requirements.
  • Clearer alignment between engineering, integration and operational teams.
Flow simulation: pressure contour along the span of a curved canopy, colour scale in pascals

Why APCO

Defining requirements can look like listing specifications. Understanding how those specifications affect one another takes technical judgement.

The manufacturer develops defense textile solutions for recovery and protection across defense, aerospace and unmanned systems: UAV recovery systems, parachutes, airbags, deceleration mechanisms, deployment bags, ballistic nets, capture systems and other custom textile-based applications. It has developed UAV recovery solutions for platforms ranging from under 1 kg to more than 1,000 kg.

At the requirements stage the textile element is therefore not considered in isolation. The review looks at how the complete recovery or protection direction must work with the platform, payload and mission outcome — shock, stability, weight, volume, deployment timing, airflow and platform structure as one connected physical system.

Phase
Define
Continues with
PrototypingDesign

Technical data per manufacturer documentation from APCO Aviation Ltd , as of 2026-07-30.

Frequently asked

Asked in technical terms.

What does defining requirements cost?

For new customers the initial requirements discussion is normally included as part of understanding the project and evaluating its technical scope. It comes before design and development rather than alongside them, and produces the technical direction that every later step builds upon.

Why can requirements not be settled one at a time?

Because each one affects the whole physical system. A lower descent rate may require a larger canopy, a larger canopy can raise packed volume, soft-goods weight and opening shock, and greater opening shock may demand additional load absorption, different mechanical components or adjustments to the platform structure.

Do we need to know which textile solution we require?

No. Your team may understand the risk without knowing whether the right direction is a parachute, airbag, net, deceleration system, flotation element or another textile solution. Defining the requirements helps identify the appropriate direction, starting from what must be protected and what the platform can realistically support.

What information is needed to begin?

The discussion normally includes the platform, payload, risk, mission environment, available space, weight limits, deployment conditions and the result the recovery or protection solution must achieve. From this comes a shared understanding of what the textile solution must achieve and what the platform can realistically support before resources are committed.

Does this stage include the final design?

No. It defines the technical requirements and direction that the design and prototype must follow. The goal is to reduce uncertainty before development begins, so the project moves forward from defined requirements rather than assumptions. For complex programmes the work may continue through formal stages such as a System Requirements Review or Preliminary Design Review.

Can this stage identify an unrealistic requirement?

Yes. The review may reveal conflicts between descent rate, canopy size, packed volume, opening shock, structural capacity or another technical factor before development begins. A lower descent rate may require a larger canopy, which can in turn increase packed volume, soft-goods weight and opening shock. Identifying such conflicts early is part of this stage.

Can an existing requirement be reviewed?

Yes. The manufacturer can review an existing requirement to understand whether it reflects the platform limits, mission conditions and full recovery or protection sequence. The review covers factors such as opening shock, canopy stability, descent rate, packed volume, available space, deployment height and airflow, and why an off-the-shelf solution does not fit.

What happens after the requirements are defined?

The next stage is normally creating a physical prototype, followed by testing, validation and preparation for production. It builds on the basis defined at this stage: the recovery or protection objective, performance and deployment requirements, a practical direction for the textile solution, and a basis for safety-factor decisions and for prototype, testing and validation planning.

Tell us what the system has to do.

Define a project