Hardware Product Requirements for PCB Design: Testable Inputs
Design inputs 路 Before schematic capture
Hardware product requirements for PCB design should tell the team what the board must do, under which conditions, and what evidence will demonstrate success. A feature list is a starting point. A usable design input also defines interfaces, operating states, limits, tolerances and who resolves unanswered questions.
This guide helps a product owner, electronics engineer and manufacturing partner agree on those inputs before component selection locks in cost or layout. The worked example is an illustrative low-voltage sensor interface board, not a customer project or a qualified reference design. Adapt its numbers to your product rather than copying them into a specification.
Start with the product boundary, not the MCU
Write down the user, the job and the surrounding system. Does the PCB include the power adapter, or does it receive regulated DC from another assembly? Does it produce a calibrated physical measurement, or only digitize a voltage supplied by a separate sensor? Is a cable part of the delivered product? These boundaries determine which performance claims the board can reasonably own.
For our example, an indoor monitoring product contains a sensor interface PCB, a separate enclosure and an external regulated supply. The PCB reads two analog signals and reports samples to a host. The product team owns sensor accuracy and host behavior; the board team owns input loading, conversion, power and the electrical interface. An interface agreement connects these responsibilities. Without it, each team can pass its own test while the assembled product fails.
Record exclusions with equal care. 鈥淣o battery charger on this revision鈥� prevents an assumed feature from appearing after layout. An exclusion is not permission to ignore foreseeable connections: if a service cable can supply power, its interaction with the normal input still needs a decision. Draw every external power path, signal connector, exposed conductive surface and mechanical attachment before refining the specification.
Separate needs, requirements and implementation choices
A need explains the reason for the product: an operator must see a useful reading after switching it on. A requirement makes the expected behavior testable: identify the input state, the output event and the allowed time. An implementation choice explains how the team intends to achieve that behavior, such as using a particular regulator, processor or communication peripheral.
Sometimes a component really is a constraint because firmware, qualification or purchasing has already fixed it. Record that constraint and its owner explicitly. Otherwise, specifying a part too early can hide a better solution. 鈥淯se a faster MCU鈥� is neither a complete performance requirement nor a justified component decision; it leaves timing, workload and cost undefined.
is useful general guidance on clear, consistent and verifiable statements. The PCB examples below are an engineering adaptation; following this worksheet does not establish compliance with a NASA program or a product certification.
Use one observable obligation per requirement. Put its rationale, assumptions and verification approach in separate fields. Avoid combining input voltage, radio range, battery life and enclosure sealing into one sentence with a single pass box. When one condition fails, a reviewer must be able to identify precisely which requirement needs work.
A worked example: specify conditions before choosing limits
Assume the example board will be checked at 23 卤 5 掳C, with its production-intent firmware, a defined host interface and a regulated DC source. These are starting assumptions for a bench prototype, not a complete operating-environment qualification. The team must separately approve temperature, humidity, electromagnetic compatibility and other intended-use requirements.
| ID and subject | Illustrative requirement | Evidence to plan |
|---|---|---|
| PWR-01 路 Input | The board shall operate from 10.8鈥�13.2 V DC measured at connector J1 under each defined operating state. | Record J1 voltage and function at both endpoints and nominal input; include the cable used. |
| TIM-01 路 Start | The board shall issue its first valid sample message within 2.0 s after J1 reaches 10.8 V during the specified startup waveform. | Capture input voltage and the decoded message timestamp on the same time base. |
| ANA-01 路 Loading | Each signal input shall present at least 1 M惟 DC resistance to the signal reference over 0.2鈥�2.8 V while powered in acquisition mode. | Measure input current at defined voltages; cover every channel and relevant input configuration. |
| COM-01 路 Reporting | The board shall send one identified sample per channel every 100 ms, with interval error no greater than 卤5 ms, during the defined host test. | Analyze a recorded message sequence; specify test duration and handling of invalid samples before release. |
| MEC-01 路 Fit | The PCB and populated components shall remain within the controlled mechanical envelope and keep-out drawing ME-001, revision A. | Inspect the assembled board against the drawing, including connector and fastener access. |
Notice what remains unresolved. The input-loading requirement says nothing about unpowered behavior, protection-clamp current or transient survival. Those need separate requirements if the sensor can remain active while the board is off. Likewise, reporting every 100 ms does not specify measurement accuracy. Add an error budget covering the sensor, reference, input network, converter, temperature and calibration before selecting an ADC by bit count.
The startup requirement also needs a defined power waveform. Starting a timer at a switch click is ambiguous when a cable, regulator or soft-start circuit delays the rail. Identify the measurement points and threshold crossings. For the example, a 1.84 s first-message result meets the 2.0 s timing limit only under the recorded conditions; it does not prove all production units or all temperatures will pass.
Build a power and operating-state table
鈥淟ow power鈥� has little design value without states. List off, startup, acquisition, communication, service and fault behavior as applicable. For each state, identify active loads, supply paths, expected duration and the event that changes the state. A radio transmit pulse, display backlight or sensor heater may dominate a peak even when the average is small.
For an original planning example, suppose a device draws 30 mA for 90% of a repeated interval and 110 mA for 10%, measured at the same 12 V input. Its time-weighted average is 0.9 脳 30 + 0.1 脳 110 = 38 mA, and the corresponding average input power is approximately 0.456 W. This arithmetic does not select the supply: the source must also support startup and the 110 mA state, including tolerances and transient behavior.
Do not add currents from different voltage rails to estimate input current. Convert rail loads to power and account for conversion losses using the intended regulator鈥檚 data. For a battery product, the usable energy, temperature, aging, conversion efficiency and actual duty cycle all matter. Leave a target marked unresolved until the assumptions behind it can be reviewed.
Discuss measurement access at the same time. If every rail is permanently tied together, separating a sensor fault from an MCU fault can become difficult. Test points, optional links and deliberate enable controls may be worthwhile prototype features. Their value is the evidence they make accessible, not the number of test pads added.
Connect every requirement to evidence
A compact verification matrix links a requirement ID to a method, setup, pass criterion, owner and result record. illustrates traceability between requirements and their verification. For a commercial PCB project, keep the implementation proportionate: a controlled table can be more useful than an elaborate system that nobody maintains.
Choose the method deliberately. Connector orientation can be inspected. A power budget can be analyzed before hardware exists and later compared with measurements. Startup timing needs a repeatable test. A demonstration that an LED flashes is not evidence that measurement accuracy, communication integrity or fault recovery meets its specification.
Include the board revision, assembly variant, firmware identifier, instruments, test conditions and file location in a result record. Write 鈥渘ot tested鈥� when evidence is missing. A blank cell is easily mistaken for a pass during purchasing or production review. If a test fails, retain the failed evidence and link the correction and retest rather than replacing history with a green status.
Verification asks whether the design meets its agreed inputs. Product validation asks whether those inputs deliver the intended user outcome. A beautifully documented PCB that reports too slowly for the operator can be verified against the wrong requirement. Run a representative usage trial before treating the requirements baseline as settled.
Interactive design-input review
Use these checkboxes during a joint review. They are a local reading aid, not a certification score; selections are not saved or submitted. Keep unresolved items in your project鈥檚 controlled record.
What should happen if a box remains unchecked?
Classify the missing input by the decision it affects. An unknown enclosure height can block component selection and layout. An unapproved cosmetic label may be resolved later. Record the assumption used, the risk if it changes, and the person authorized to accept it. Do not silently replace an unknown with a convenient default.
Control changes without freezing learning
Prototype evidence should improve the requirements. However, a changed input can affect multiple disciplines. If the example鈥檚 startup limit changes from 2.0 s to 0.5 s, review regulator startup, sensor settling, calibration loading, communication initialization and the test procedure. Replacing a sentence in the requirements file is only one part of the change.
Use a small change record: old requirement, new requirement, reason, affected files, verification impact and approval. Mark obsolete BOMs and fabrication packages clearly so the assembly partner does not build to one revision while the firmware team tests another. For broader build stages and learning objectives, continue with hardware prototype development.
What to send for a useful manufacturing review
Send the approved schematic and PCB revision, BOM with manufacturer part numbers, fabrication outputs, assembly data and the applicable mechanical drawing. Add a short requirements extract containing critical interfaces, special handling, inspection needs and the intended test scope. The manufacturer does not need every internal product discussion, but does need the requirements that change fabrication, assembly or acceptance.
Separate a development question from a build instruction. 鈥淧lease review access for testing the 3.3 V rail鈥� invites an engineering response. 鈥淭est all functions鈥� leaves equipment, firmware, limits and responsibility undefined. Use the electronics NPI checklist to connect these inputs to a controlled release package, and discuss the build through prototype PCB assembly when the design is ready for hardware.
If important inputs are still open, identify them rather than withholding the entire project. A focused review can establish what is needed next without suggesting the design is already approved.