What information is required before detailed design can start?

Before detailed design can start, a project team needs complete, approved design inputs: a defined set of technical specifications, regulatory requirements, interface constraints, and validation criteria that collectively describe what the design must achieve. Without these inputs in place, engineers are designing against assumptions rather than verified requirements, which creates rework risk and potential compliance gaps. The sections below address the most common questions that arise when teams are preparing to move into detailed design.

What happens if detailed design starts without complete requirements?

Starting detailed design without complete requirements almost always results in rework, cost overruns, and schedule delays. When engineers make design decisions based on assumptions rather than approved inputs, those decisions frequently have to be reversed or redesigned once the actual requirements are confirmed. In safety-critical industries such as aero engine and gas turbine development, incomplete requirements at this stage carry additional consequences.

The most common outcome is a cascade of design changes. A component dimensioned against an assumed pressure ratio, for example, may need to be completely reworked once the actual operating envelope is specified. Each change late in the design cycle costs significantly more to implement than the same change made before design work begins, because downstream drawings, analyses, and procurement actions all need to be revisited.

Beyond schedule and cost, there is a regulatory dimension. Certification authorities require that design inputs be documented and traceable before design outputs can be assessed. If a team begins detailed design without this documentation, they may produce technically sound work that cannot be certified because the evidentiary chain from requirement to design decision is missing. In aerospace development, this is not a procedural inconvenience but a fundamental barrier to airworthiness approval.

What technical specifications must be defined before detailed design?

Before detailed design begins, the following categories of technical specification must be defined and approved: performance requirements (such as pressure ratios, flow rates, efficiency targets, and operating temperatures), mechanical and structural loads, interface definitions with adjacent systems, material and manufacturing constraints, and environmental operating conditions. Each of these shapes design decisions that are difficult to reverse once detail work is underway.

For gas turbine components, performance specifications are particularly consequential. A compressor stage designed to meet a specific pressure ratio and efficiency target will have blade geometry, tip clearances, and stage matching that are directly derived from those numbers. If the target changes after detailed design has started, the aerodynamic design may need to be substantially reworked.

Interface definitions are equally important and often underestimated. A component does not exist in isolation: it connects to upstream and downstream elements, and those connections impose constraints on dimensions, flange configurations, instrumentation ports, and access for assembly and maintenance. Defining these interfaces before detail design starts prevents conflicts that are expensive to resolve once drawings are in progress.

Material and manufacturing constraints also need to be established early. The choice of alloy, coating system, or manufacturing process can affect what geometric features are achievable, what tolerances are realistic, and what inspection methods apply. Discovering late in design that a specified geometry cannot be manufactured to the required tolerance is a common and avoidable source of delay.

What regulatory and certification requirements apply at the design stage?

The regulatory requirements that apply at the detailed design stage depend on the product type and its intended market, but in aero engine development they typically include airworthiness standards set by authorities such as EASA or the FAA, along with any applicable military standards for defence applications. These standards define what must be demonstrated, how design outputs must be documented, and what analysis and test evidence is required to support certification.

For civil aero engines, the relevant certification basis is established early in the programme and forms part of the design inputs. This means that before detailed design starts, the team should already know which edition of the applicable airworthiness code governs the design, what special conditions or equivalent safety findings apply, and what means of compliance have been agreed with the authority.

Defence programmes follow a different but parallel logic. Requirements are typically captured in a system specification or statement of work, and design compliance is demonstrated through a structured review process. For teams working across both civil and defence sectors, the documentation and traceability requirements share common principles even where the specific standards differ.

Certification requirements also have direct implications for how the design is structured. If a particular failure mode must be shown to be extremely improbable, that requirement drives design choices around redundancy, separation, and material selection from the earliest stages of detailed design. Treating certification as something to address after the design is complete is one of the more reliable ways to generate expensive late-stage redesign.

How do test and validation requirements shape design inputs?

Test and validation requirements shape design inputs by defining what evidence must be produced to demonstrate that the design meets its requirements, which in turn constrains how the design must be configured to make that evidence collectible. A component that cannot be instrumented adequately, or that cannot be tested in a representative environment, creates a certification gap regardless of how well it is designed analytically.

For aerothermal components, this means that instrumentation access needs to be considered as a design input rather than an afterthought. Pressure tappings, thermocouple ports, and optical access windows all need to be accommodated in the geometry, and their locations are often determined by the test plan rather than by the component’s primary function. If the test plan is not defined before detailed design starts, the design may not support the measurements needed to validate it.

The test environment also matters. A component designed to operate in a full engine will be tested in conditions that approximate, but do not exactly replicate, that environment. Understanding the differences between test and service conditions is a design input because it determines what corrections need to be applied to test data and whether the test configuration can genuinely validate the design intent. Experimental test facilities that can closely replicate representative aerothermal conditions reduce the uncertainty in this translation from test evidence to service prediction.

Validation requirements also influence design margins. If the test programme cannot cover the full range of operating conditions, the design may need additional margin to account for the untested portions of the envelope. Establishing these margins before detailed design starts prevents the situation where a design that passes analysis fails to demonstrate adequate margin during test.

Who is responsible for defining and approving design inputs?

Responsibility for defining and approving design inputs is shared across several functions, but the system or chief engineer typically holds accountability for ensuring that inputs are complete, consistent, and formally approved before detailed design is released. In practice, requirements originate from multiple sources: the customer, the certification authority, the systems engineering function, and the design teams themselves.

Customer requirements are usually captured in a specification or contract document and form the top level of the requirements hierarchy. Below that, systems engineers decompose top-level requirements into component-level specifications, resolving conflicts and allocating performance budgets across the design. Design engineers contribute by identifying derived requirements: constraints that emerge from the design itself, such as the need for a specific surface finish to achieve the required aerodynamic performance.

Approval of design inputs typically involves a formal review, often called a system requirements review or preliminary design review, at which the completeness and consistency of the requirements baseline is assessed before detailed design is authorised to proceed. This review is not a formality. It is the point at which the organisation commits that the requirements are sufficient to design against, and any gaps identified at this stage are far cheaper to resolve than gaps discovered during detailed design or test.

In organisations where design and testing are handled by different teams or external suppliers, clear ownership of requirements becomes even more important. A supplier beginning detailed design needs to know not only what the requirements are, but who has authority to approve changes to them, because a change to a design input after detailed design has started has cost and schedule implications that need to be managed through a formal change process.

How AneCom supports the transition from requirements to detailed design

AneCom AeroTest works with gas turbine and aero engine development programmes at precisely the stage where requirements meet design, providing the engineering services and experimental test capability that help teams establish robust design inputs before detailed work begins. Specific ways AneCom supports this process include:

Aerothermal component testing to generate validated performance data that can be used to anchor design requirements, rather than relying on analytical predictions alone
Instrumentation design and integration, so that test configurations are planned in parallel with component design and the two remain compatible throughout development
Design and analysis services that help identify derived requirements and interface constraints before they become conflicts in detailed design
Access to Europe’s largest anechoic chamber and a dedicated Compressor Test Center, providing representative test environments for fan and compressor validation that directly support the test evidence required for certification
Non-destructive testing and inspection services that inform material and manufacturing constraints as part of the requirements definition process

If your programme is approaching the detailed design gate and you need to close gaps in your requirements baseline or plan your test and validation strategy, contact AneCom to discuss how our engineering and testing services can support your programme.