Solution Development from Requirement Definition to Mass Production

A solution development project begins with a requirement and ends with a product that can be manufactured, and the distance between those two points is filled with decisions that are much cheaper to take early than late. This introduction describes the route as it is actually followed: what is agreed at the start, what the prototype rounds are for, and how the design is handed over into volume without losing the information that production needs.

Starting From a Requirement

The first stage is requirement definition, and it is the stage that determines the cost of everything after it. A requirement that has not been examined produces a design that satisfies the literal words and misses the intent: a product described as needing a wireless connection may in practice need a connection that survives a certain distance, a certain interference level and a certain battery budget, and those three conditions pull the design in different directions.

The work therefore starts with a structured conversation that turns the customer’s description into a technical statement. The functions are separated into what must be present for the product to exist, what is needed for it to be competitive, and what could be added later if the cost allows. The interfaces, the supply arrangement, the mechanical envelope and the environmental conditions are fixed at the same time, because each of them constrains the architecture before a component has been chosen.

The output is a short document rather than a specification library: the functions, the constraints, the interfaces, the compliance requirements, the rough cost target and the schedule. It is deliberately readable by someone who is not an engineer, because the decisions in it are commercial as much as technical.

Choosing the Architecture

With the requirement agreed, the technical route is selected and compared against at least one alternative. The choice between a single integrated device and a processor with separate peripherals, between a discrete supply and a module, and between a wired and a wireless interface are all decisions that move both the cost and the performance, and they are all settled before the schematic is drawn.

At this point a preliminary bill of materials is produced with an indicative cost, and the embedded firmware implications of each route are stated. A route that is cheaper in hardware and much more expensive in software is not cheaper overall, and the comparison is only meaningful when both sides are visible at the same time. Our embedded firmware group works beside the hardware designers so that this comparison is available during the selection rather than after it.

Design and Prototype

The hardware design proceeds from the schematic to the layout, and the firmware proceeds in parallel, so that the first board can be brought up as soon as it returns rather than waiting for a software effort to begin. The prototype stage has a defined purpose: the first round proves that the architecture works, the second proves that the performance meets the requirement across the conditions that matter, and the third, when it is needed, resolves the issues that emerged from testing. Each round is planned with what it is intended to answer, because a prototype that is built without a question is an expensive way to confirm an assumption.

Testing covers function, performance and reliability. The supply margins, the temperature extremes, the aging behaviour and the endurance of any battery are measured rather than assumed, and the compliance requirements are approached through pre-compliance work so that the formal test confirms a result instead of producing one.

Prototype to Mass production

The handover into volume is a stage in its own right. The design that was verified on a handful of boards has to be built on a line, with a stencil, a placement programme, a reflow profile and a test fixture that did not exist during development. Running a small batch first is the cheapest way to find the process issues, because the quantity is small enough to investigate carefully and large enough to reveal a systematic problem.

That batch also produces the production revision: the released artwork, the bill of materials, the coordinates, the assembly drawing, the programme and the test requirements, all confirmed against a physical board. It is the reference against which later orders are compared, and it removes the reliance on notes that were made during development and never retired.

The same operation then carries the product through PCB design and layout, PCB manufacturing, SMT assembly, PCBA testing and quality management, which is what makes the handover a transfer of information rather than a restart.

How the Engagement Can Be Structured

The arrangement is matched to what the customer already has. A customer with no engineering resource can hand over the requirement and receive a design that is ready for production. A customer with a software team can take the hardware work alone. A customer with an existing platform can have a variant derived from it, which is the fastest route when the product is a member of a family rather than a new concept.

Whichever the arrangement, the project is followed by a named engineer who reports at fixed points and confirms the key decisions with the customer, so that the state of the project is visible from outside rather than inferred from the absence of questions.

What Goes Wrong Without a Defined Route

Development projects rarely fail because a circuit was impossible to design. They fail because a decision was deferred until it could no longer be made cheaply. The most common pattern is a requirement that was never written down: the product is built to satisfy the description given at the first meeting, and the description omitted the condition that the customer assumed without saying. The second is an architecture chosen before the cost target was known, so that the design is complete before anyone asks whether it can be sold at the intended price.

A third pattern is the prototype that is treated as a demonstration rather than as a test. A board that works on a bench under laboratory conditions has proved very little about the product, because the temperature range, the supply variation, the electromagnetic environment and the endurance requirement have not been examined. The cost of discovering those conditions after the tooling has been released is far higher than the cost of examining them on the second prototype.

The fourth pattern is the handover that loses information. The settings, the substitutions and the corrections that were made during development live in the heads of the engineers unless they are written against the order, and a production batch that starts from a fresh setup reintroduces problems that the prototype already solved. Recording the production revision, and retiring the temporary notes when it is confirmed, is the single most effective protection against that loss.

How Progress Is Reported

The project is divided into stages, and each stage ends with something that can be looked at rather than with a statement that it is finished. The requirement stage ends with the agreed statement of functions and constraints. The architecture stage ends with a chosen route, an indicative cost and a schedule. The design stage ends with a released data set. The prototype stage ends with measured results against the requirement. The pilot stage ends with a confirmed production revision and a yield figure.

That structure exists so that the customer can stop at any of those points, or change direction at one of them, without having paid for the next. It also means that the status of the project is a matter of reading the last completed stage rather than asking for an opinion, which is what makes the schedule a commitment instead of an estimate.

FAQ

What is needed to start? A description of what the product has to do and the constraints it has to work within. A complete specification is not required at the first meeting.

How many prototype rounds are usual? Two or three, each planned around the questions it is meant to answer rather than repeated on a calendar.

Who owns the design data? The customer, who receives the artwork, the bill of materials, the coordinates, the programme and the design files at the end of the project.