The Design Brief

Drawing up a Good Design Brief

No rational design process can start without a specification of the desired final product. This is a list of requirements put together by the customer (or by someone playing the role of a potential customer), though the engineer’s input may already be required here too. The fundamentals of the design brief may be relatively easy to formulate for some classes of aircraft: for example, an airline may wish to express a requirement for a new aircraft capable of transporting 300 passengers and 101 of freight at Mach 0.8 over 3000 nautical miles when departing from an airport at sea level experiencing temperatures of 25 °C above the International Standard Atmosphere value and admitting aircraft with a wingspan under 65 m. However, with unmanned systems, formulating a good original specification may be thornier (somewhat paradoxically, considering that the result may be orders of magnitude simpler than in the example above).

In practice, the greatest stumbling block might be that the customer is often prejudiced by having half a solution in mind, which they are liable to weave into the formulation of the design brief. A typical bad design brief begins with something like “we need a multicopter to conduct surveillance of- ? ?.” The role of the engineer here is to guide the customer toward specifying the problem and the problem alone (“I need an unmanned system capable of pointing a camera at...”). After all, if offered a helium-balloon-based platform or a fixed-wing aircraft with a slow loiter capable of the same surveillance task, but costing less than the multicopter, they would no doubt accept it - they just may not have thought of that solution when picturing the result of the unmanned aircraft development process, perhaps biased by their existing system or by whatever they may have seen a competitor operate. Even if, in this notional example, the best solution was rotorcraft-based, what if this solution involved a swarm of 10 very small rotorcraft? A system-level view does not come naturally to many customers, but it should do to an engineer.

This also underlines the importance of a dialogue between the customer and the engineer, where the initial concept is the result of an iterative process. Such an exchange may also refine the design brief itself, down to some of its numerical elements; for example, the engineer may be able to provide feedback on which component of the brief is the strongest cost driver (we shall return to this later in this chapter).

< Prev   CONTENTS   Source   Next >