Electronic-Product Requirements, Architecture & Realization

An electronic product is not a schematic plus a board. It is a controlled realization of intended behavior inside electrical, mechanical, environmental, manufacturing, safety, cost, and lifecycle constraints. The central design skill is maintaining a defensible chain from why the product exists to what evidence proves the delivered unit is fit for that use.

flowchart TB
  N["Stakeholder need"] --> R["Measurable requirements"]
  R --> A["Architecture and budgets"]
  A --> I["Detailed implementation"]
  I --> V["Verification against requirements"]
  V --> Q["Qualified product baseline"]
  Q --> L["Validation in intended use"]
  V -- "failure evidence" --> A
  L -- "wrong need or context" --> R

The arrows back are essential. Discovery is expected; uncontrolled discovery is the problem.

Write requirements that can fail #

A useful requirement identifies the subject, observable behavior, operating conditions, numerical limit, and verification method. “Low power” cannot be designed or tested. “The assembled controller shall draw no more than 120 mA from 24 VDC in normal acquisition mode at 25 °C, excluding field loads, measured after a 5-minute warm-up” can.

Requirements must cover more than nominal function:

• input and output ranges, accuracy, latency, timing, startup, shutdown, and fault behavior;
• supply quality, transients, reverse polarity, inrush, grounding, isolation, and protection;
• temperature, humidity, contamination, vibration, shock, altitude, pressure, and ingress;
• enclosure, connectors, human access, mounting, service, and replaceable units;
• EMC, electrical safety, hazardous locations, and applicable product standards;
• manufacturing volume, test access, yield, calibration, traceability, repair, and disposal;
• software, firmware, communications, security, and update interfaces that constrain hardware.

Avoid embedding a design solution unless it is genuinely imposed. “Use a 16-bit ADC” hides the purpose. A requirement on input-referred noise, error, bandwidth, and overload recovery leaves room to choose a suitable architecture.

Allocate architecture and budgets #

Architecture assigns responsibilities and creates interfaces. A sensor channel might become: connector protection → excitation → sensing element → amplifier → anti-alias filter → ADC → digital correction → protocol output. Each boundary needs electrical levels, impedance, timing, error allocation, fault containment, and ownership.

Budgets make cross-coupling visible. For a measurement channel, allocate total error among the sensor, reference, analog chain, conversion, calibration residual, temperature influence, and drift. For power, list every rail's steady, peak, startup, and fault load, then include converter loss and source tolerance. For latency, allocate acquisition, filtering, computation, transport, and actuation. For thermal design, map dissipation into junction, board, enclosure, and ambient temperature rises.

Verification and validation answer different questions #

In the NASA product-realization model, verification determines whether the realized product conforms to specified requirements; validation determines whether it fulfills its intended purpose in the operational environment. Passing an input-range test verifies a requirement. Discovering that operators cannot interpret a fault indication is a validation failure even if every electrical test passes.

A requirements-verification matrix should exist before detailed layout:

Analysis, inspection, demonstration, and test are complementary. A continuity check cannot establish surge immunity; an elaborate test is wasteful when calibrated inspection proves a dimension directly.

Realization uses controlled baselines #

Prototypes answer questions. Engineering units verify implementation. Qualification units establish that a production-representative design survives its mission profile. Production acceptance detects workmanship or unit variation without re-qualifying the design. Mixing these roles produces invalid evidence—for example, passing EMC on a hand-modified board does not qualify an unreconciled production release.

At each review, freeze enough context to reproduce the result: requirements revision, schematic and PCB revision, BOM and approved alternatives, firmware, manufacturing package, deviations, test procedure, equipment, calibration state, raw data, and unit serial number. A photograph of “the working board” is not a baseline.

A compact realization loop #

1. Define intended use, misuse, boundaries, and governing standards.
2. Convert needs into testable requirements and interface contracts.
3. choose an architecture; allocate performance, power, timing, thermal, and reliability budgets.
4. Identify high-risk assumptions and design prototypes that isolate them.
5. Implement with design rules derived from requirements and supplier processes.
6. Review the exported manufacturing data, not only the CAD canvas.
7. Verify each requirement on controlled articles and preserve raw evidence.
8. Validate the integrated product in representative use.
9. Route failures and changes through configuration control, then repeat affected evidence.

The result is not bureaucracy around engineering. It is the memory that lets a team tell which claim is true, for which hardware, under which conditions, and why.