8D.wiki Editorial — Drafted with AI assistance, then reviewed, edited and formatted by the founder — facts, numbers, tables and terminology are checked before publication.
Reviewed & edited by: Alvin Jin — IATF 16949 expert · Certified Product Engineering (PE) coach · DRBFM expert
Published 2024-03-09 · Last reviewed 2026-10-25
an automotive quality department deep-dive survey: over 70% of aftermarket failures stem from poor requirements engineering, over 60% from inadequate test me...
In the depths of manufacturing, it is common to attribute failures to operator mistakes on the production line or random material defects. However, years ago, the an automotive quality department conducted a deep-dive root cause survey of aftermarket product failures. The results revealed a truth hidden beneath the surface: the majority of quality problems originate not in manufacturing, but at the very beginning of product creation — the research and development and specification definition phase.
The survey found that the primary driver of product failure is inadequate requirements engineering, accounting for over 70% of failures. This means more than seven out of ten aftermarket faults were already seeded before a single line of code was written or a single drawing was drafted.
The data further reveals a leverage effect between requirements investment and total project cost. When only 4% of the budget is spent on developing technical requirements, the final project cost overrun averages 120%. When this investment increases to approximately 15%, the cost overrun narrows to roughly 20%. What appears to be saving money in the requirements phase is actually borrowing at compound interest for later changes, rework, and recalls.
The breakdown of requirements engineering is fundamentally a failure of translation and closure. It manifests across three core dimensions.
1. Requirements Elicitation (360-degree Sensing). Failure to collect information comprehensively from external sources (user stories, misuse cases, regulations) and internal sources (manufacturability, serviceability).
2. Requirements Development (Precise Translation). Failure to translate ambiguous user needs into clear, unambiguous technical language. What gets developed is a subset, not the complete set, of what is actually required.
3. Requirements Management (Traceability). Lack of verification and traceability of requirements, causing the design to drift progressively further from the original intent.
If requirements define the direction, verification is the defense line. The survey found that the second largest cause of failure is inadequate test methods and tools, accounting for over 60% of failures. This is not simply a shortage of test equipment, but a lack of verification coverage.
Many organizations fall into the trap of passing in the lab while failing in the field. The core question: are real user use cases being fully converted into test cases? Do the test equipment and software tools faithfully simulate the user actual environment? If testing is conducted only to pass a standard, rather than to cover real-world scenarios, then even the most perfect test report is self-deception. Lagging test tools allow products carrying undetected defects to cross the defense line and fail in the customer hands.
Furthermore, the survey found that inadequate design methods and tools, along with insufficient design review and product release processes, each account for over 40% of failures. This demonstrates that every stage — from the scientific rigor of design methodology to the final gate before product launch — accumulates probability of failure when standards slip.
The research paints a clear picture: product failure is not a matter of random bad luck, but the inevitable result of systems engineering capability. To address failure at the root, the center of gravity must shift from downstream firefighting to upstream fire prevention. Invest heavily in requirements definition. Pursue realistic verification testing. Maintain rigorous standards in design review. Only by doing so can the fuse of failure be extinguished at its source.
Turn this method into a submittable 8D report
Generate a D0–D8 report skeleton with a 5-Why chain and containment actions.
8D.wiki — Quality Engineering Knowledge Base