Verification Methods: Test, Analysis, Inspection, Demonstration

Hardware teams regularly spend weeks rebuilding verification evidence right before a preliminary design review or customer audit. The root cause is almost always the same: someone labeled a requirement as verified by analysis eighteen months ago, but nobody recorded the boundary conditions, the meshing assumptions, or the specific CAD revision used in the simulation.

Picking the right verification method early in a program prevents late, expensive redesigns. This guide shows how to assign verification methods, record defensible engineering rationale, and preserve verification status when CAD models change. You will need a draft requirements list, an initial bill of materials or system architecture, and access to your design review process.

Step 1: Write the requirement so a method can actually close it

A verification method cannot rescue a poorly written requirement. If an engineering specification says the actuator housing must be durable under vibration, you cannot verify it. You can't write a test plan for durability, you can't build an analysis model for it, and an inspector can't measure it. Durability is a goal, not a verifiable engineering statement.

Every requirement needs an explicit pass or fail boundary, precise engineering units, and the environment where that boundary applies. Rewrite ambiguous goals into verifiable performance targets: The actuator housing shall maintain structural integrity with zero plastic deformation when subjected to random vibration of 0.04 g2/Hz from 20 Hz to 2000 Hz for 3 minutes per axis across three orthogonal axes. Now a test engineer can build a shaker profile, an analysis engineer can construct a harmonic FEA model, and a quality engineer knows what to look for after the run.

Avoid composite requirements that bundle multiple verification methods into one sentence. If a requirement states that the chassis shall weigh less than 4.5 kilograms and sustain a 500 newton drop load without functional impairment, split it. The first clause verifies by inspection on a calibrated scale. The second verifies by structural test on a drop tower or by dynamic FEA. Bundle them and you force teams into ambiguous, multi-method closeouts that muddy the audit trail during a verification cross reference matrix review.

Step 2: Choose the method: test, analysis, inspection or demonstration

Engineering standards in space, aviation, and medical devices sort verification into four classic methods: test, analysis, inspection, and demonstration. The NASA System Engineering Handbook outlines standard definitions for test, analysis, inspection, and demonstration.

Test verifies a requirement through quantitative empirical measurement during or after exposure to operational or simulated environmental conditions. Use test when the physics are too nonlinear for analytical confidence, when material properties are unproven, or when regulatory standards mandate hardware-in-the-loop proof. Dynamic drop shocks, thermal vacuum cycling, and electromagnetic compatibility tests all fall here.

Analysis predicts system behavior using mathematical models, simulations, or conservative engineering calculations. Choose analysis when testing to failure costs too much, when physical test chambers can't match the scale of the operational environment, or when high margins of safety make physical testing redundant. Thermal dissipation models, structural finite element analyses, and aerodynamic pressure predictions are standard examples.

Inspection examines physical characteristics visually or through dimensional measurement tooling like calipers, optical comparators, and coordinate measuring machines. Inspection confirms that hardware matches drawings, material certifications are valid, or surface coatings match drawings. It confirms what the hardware is, not how it performs dynamically.

Demonstration observes qualitative system operation without specialized instrumentation. It answers a binary functional question: does the latch open when the handle turns? Does the software user interface display an error code when power drops? If you have to measure voltage, displacement, or temperature to verify the requirement, the method is test, not demonstration.

Step 3: Record the rationale and the assumptions behind the choice

Assigning a verification method without documenting the rationale creates technical debt that surfaces during audits. An engineering reviewer or regulatory body will not accept a bare spreadsheet cell that says analysis. They need to know why testing was ruled out, what assumptions make the model valid, and what safety factor was applied.

Your rationale record must capture three data points: the technical reason for the choice, the boundary conditions or baseline assumptions, and the fallback trigger. For example, if you verify a bracket yield strength by analysis, state: Verified by static structural FEA because yield factor of safety exceeds 2.5 on a linear isotropic material (6061-T6 aluminum) with well-characterized properties. Fallback trigger: if mass optimization reduces the factor of safety below 1.5, switch method to physical pull test.

If your rationale doesn't name the analysis tool, boundary conditions, or tolerance stack-up assumptions, the method choice is undefended. When an engineer leaves or a sub-tier supplier updates a component, the next team can't tell whether the original justification still holds.

Step 4: Worked examples: requirement -> method -> evidence -> rationale

Seeing the full chain from requirement to rationale shows how teams keep technical baselines defensible.

Example 1: Structural bracket.

• Requirement: The sensor mounting bracket shall support a 150 N static normal load without exceeding 0.2 mm deflection at the sensor interface.

• Method: Analysis.

• Evidence: Static structural FEA report (Document TR-0482) referencing SolidWorks model revision C, showing maximum deflection of 0.08 mm.

• Rationale: Deflection margin is greater than 200% under static load, and the geometry uses homogeneous 6061-T6 billet without welds or complex joints.

Example 2: Enclosure ingress protection.

• Requirement: The battery enclosure shall prevent water ingress under 30 minutes of immersion at 1.0 meter depth (IPX7).

• Method: Test.

• Evidence: Environmental test lab test report (ETR-109) with continuous pressure decay logging and post-submersion internal inspection.

• Rationale: Gasket compression and elastomeric seal relaxation under hydrostatic pressure are nonlinear; physical testing is required to confirm manufacturing seal integrity.

Example 3: Fastener engagement.

• Requirement: All structural chassis fasteners shall show a minimum of 2.0 full thread pitches protruding beyond the locking nut.

• Method: Inspection.

• Evidence: Quality inspection sign-off sheet against engineering drawing note 4 on production unit SN-004.

• Rationale: Thread protrusion is a physical geometric dimension verifiable by standard optical measurement or visual check without operating the mechanism.

Example 4: Emergency power cut-off.

• Requirement: The emergency stop switch shall isolate main motor power within 100 milliseconds of depression.

• Method: Test (not demonstration).

• Evidence: Oscilloscope capture showing contact trip to bus voltage drop to zero within 42 milliseconds.

• Rationale: The switch activation is visible, but the 100 millisecond response requirement needs quantitative timing instrumentation that demonstration cannot supply.

Step 5: Avoid common mistakes: unrecorded analysis assumptions, demonstration where test is needed

The most frequent failure in verification is using demonstration when the requirement demands test. Demonstration can't prove quantitative performance. If an engineer flips a mechanical switch and writes verified by demonstration because the status LED turned green, they verified that the switch closed, not that the circuit met its response time, current draw, or isolation impedance. Guidance documents such as FAA Order 8110.49 outline specific criteria for software approval and verification tools.

Another routine trap is unrecorded analysis assumptions. An engineer calculates that a cold plate will keep power electronics below 65 degrees Celsius. They write analysis, upload an FEA summary, and move on. Nobody recorded the assumed interface thermal resistance, the coolant flow rate, or the ambient temperature. When the cooling pump supplier changes the delivery pressure or the thermal interface pad thickness goes from 0.5 mm to 1.0 mm, the baseline analysis silently breaks. Capture these dependencies during the design review or within your DVP&R so future design changes flag the analyses they invalidate.

Finally, watch out for the inspection catch-all. Quality teams sometimes use inspection to sign off requirements that say a system was built according to the schematic. Checking that a wiring harness matches a harness drawing doesn't verify that the harness carries full line current without melting its sheath. Inspection verifies layout and BOM conformance. Electrical performance requires test or analysis.

Step 6: Re-check the method choice when the design changes, and keep it linked to CAD changes, reviews and evidence

A verification plan is not a static milestone deliverable. It reflects your CAD baseline, and that baseline moves. When a mechanical engineer updates a model in SolidWorks, Onshape, Fusion, or NX to resolve a clearance conflict, they might remove a stiffening rib or thin a wall. That minor CAD revision can quietly drop an analysis margin of safety from 2.5 to 1.1, which invalidates the original rationale for skipping a physical test.

Hardware teams need a structured way to connect requirements, verification methods, and CAD changes. When a requirement allocation or a part geometry shifts, the engineering system has to alert the team so they can check whether the verified-by-analysis claim still holds. If an engineering trade drops a safety factor below acceptable organizational limits, the verification method must move from analysis to physical test before tooling freezes.

This is where Tandem helps on complex hardware programs in aerospace, robotics, automotive, and medical devices. Tandem connects design intent, requirements, CAD changes, and validation evidence in a single context layer. Instead of keeping verification matrices in static spreadsheets detached from CAD repositories, Tandem links CAD changes directly to requirements and verification evidence. If geometry updates alter structural or thermal margins, engineers can review the impact in context and adjust verification methods before hardware enters manufacturing.

What Tandem does not do

Tandem connects design intent, requirements, CAD changes, and validation evidence, but it has defined boundaries.

Tandem is not a CAD tool and does not replace your PDM or PLM system. It stores design intent, requirements, and evidence rather than geometric solids or CAD file versions.

Tandem does not run engineering calculations, execute finite element analyses, or simulate thermal models. It does not manage physical test bench execution, capture real-time sensor streams, or act as a test case execution harness. It stores the validation evidence you generate in those external tools and connects it back to the original requirements, design reviews, and CAD changes.

What to do next

Open your current program verification matrix today and filter down to every line marked verified by demonstration. Check each one against its written requirement text. If the requirement includes a number, a tolerance, or a time limit, change the method to test or analysis now.

Next, audit every requirement verified by analysis where the margin of safety is below 20%. Confirm that the CAD model revision cited in the simulation report matches the current production release in your CAD environment. If the CAD geometry has moved, schedule an analysis rerun or re-evaluate physical testing before your next formal gate review.

Conclusion

Tracking verification methods across evolving CAD assemblies takes a unified record of technical intent. When requirements, method rationale, and CAD changes live in separate spreadsheets and file directories, verification drift is inevitable. Tandem closes that gap by linking your engineering requirements and verification evidence directly to CAD changes in SolidWorks, Onshape, Fusion, and NX. Request a demo with Tandem to build an audit-ready verification baseline for your hardware program.