A requirement defect usually shows up in the cost of poor quality (COPQ) well after the point where it started. When it does surface, as scrap or a warranty claim, the team has to reopen the design and test work built on that requirement.
The ledger books that cost as internal or external failure, wherever the defect entered. For engineering leaders on regulated programs, the share of COPQ that enters upstream, where we write a requirement or verify a change, is the part we can still prevent. This guide covers the COPQ and Cost of Quality (COQ) formulas with a worked calculation, then where the upstream share comes from and how we can measure and cut it.
What Is COPQ and How Does It Fit Into COQ?
COPQ is the money we spend because the work wasn’t right the first time, whether the defect turned up in the factory or in the field. “The costs associated with providing poor quality products or services” is how the American Society for Quality (ASQ) defines the cost of poor quality. A more practical definition describes COPQ as all the costs that would disappear if the work had no deficiencies, errors, rework or failures, which is how the Juran Institute puts it.
COPQ sits inside COQ, which adds the resources spent to prevent and detect poor quality to the cost of the failures themselves. Quality teams commonly split it with the Prevention-Appraisal-Failure (PAF) model, usually credited to Armand Feigenbaum. The table maps each ASQ category to where it shows up on a regulated program.
| PAF Category | ASQ Definition (Paraphrased) | Regulated Engineering Examples |
|---|---|---|
| Prevention | Incurred to prevent or avoid quality problems; planned before operation | Requirements definition, quality planning, training |
| Appraisal | Measuring and monitoring to confirm conformance to specifications | Verification, quality audits, supplier rating |
| Internal failure | Remedying defects found before delivery to the customer | Scrap, rework, failure analysis, re-verification |
| External failure | Remedying defects discovered by customers | Warranty claims, complaint investigations, retrofits, penalties, lost sales |
The narrow view counts only the two failure categories. A broader view counts three, appraisal and inspection plus internal and external failure, which is how Joseph A. DeFeo of the Juran Institute set out the categories in ASQ’s Quality Progress in 2001. The three-category view is the more honest one for regulated product development, where a change can force re-verification and re-qualification. Either view still understates COPQ, because failure costs such as the engineering hours spent on root-cause investigation, or a launch that slips while a fix is re-verified, often go without a ledger line of their own.
The COPQ Formula and the COQ Formula
The standard COPQ formula adds the two failure categories. Internal failure covers scrap, rework, rectification, failure analysis and re-inspection on product that never reached the customer. In regulated engineering it also covers re-verification: when a nonconformance fix changes the product, we may have to plan and perform verification again. External failure covers complaint investigations, returned goods, retrofits, warranty claims, liability, penalties and lost sales.
COPQ = Internal Failure Costs + External Failure Costs
The COQ formula puts those failure costs alongside the money we spend trying to avoid them. If failure costs make up most of COQ, we are paying for defects after they escape. Shifting some of that spending toward prevention can address defects before they compound. The expanded COQ formula keeps prevention and appraisal spending visible beside the two failure categories:
COQ = (Prevention Costs + Appraisal Costs) + (Internal Failure Costs + External Failure Costs)
How to Express COPQ as a Percentage of Revenue
To express COPQ as a percentage of revenue, divide the two failure costs by sales revenue for the same period. Using the same revenue basis every period turns the result into a figure we can compare quarter to quarter:
COPQ as % of Revenue = (Internal Failure Costs + External Failure Costs) ÷ Sales Revenue × 100
What does the percentage reveal? The percentage shows how much of every revenue dollar we lose to internal and external failures, and whether that share is rising or falling against sales. Scrap rate and first-pass yield track the internal side of that figure, and warranty cost per unit tracks the external side, in units a program team can act on between quarters.
A benchmark worth comparing against names the industry it measured, and the year where the source gives one. In medical devices, the direct COQ ran at about 6.8 to 9.4 percent of industry sales in a 2017 estimate, and about two-thirds of it was the direct cost of poor quality. Scrap and rework alone ran at a median of 1.0 percent of sales across 1,008 companies in the cross-industry benchmark of the American Productivity & Quality Center (APQC). U.S.-based manufacturers paid $30.37 billion in warranty claims in 2025 across the 18 industry groups Warranty Week tracks, which leaves an aerospace or automotive program better off building its COPQ baseline from its own ledger.
Working Through a COPQ Calculation Example
Say our medical device team ships 10,000 units in a quarter, and internal failures, including scrap and rework on rejected assemblies, cost $150,000. External failures, covering warranty claims and one field corrective action, cost $800,000. Total COPQ is $950,000. If that field corrective action traced to design, it was a defect that survived design verification, design validation and release.
Against $5M in quarterly revenue, that is 19 percent of sales going to failure costs. The 19 percent counts failure costs alone, and total COQ would also include prevention and appraisal spending. Even so, the figure sits far above the COPQ share implied by the medical device estimate earlier in this guide, roughly 4.8 to 6.9 percent of sales (6.8 to 9.4 percent, less the 2.0 to 2.5 percent spent on prevention and appraisal). External failures, including one field corrective action, account for most of this quarter’s total.
Where COPQ Originates in Regulated Product Development
Requirements defects are a minority of all defects by count, but most of them are found after the stage that introduced them, and the later a defect is found the more it costs to fix. Defects introduced at the requirements stage made up 15.6 percent of the defects reported by transportation manufacturing software developers in a 2002 National Institute of Standards and Technology (NIST) study. Among financial services developers, the share was 30.3 percent.
Software projects spend about 40 to 50 percent of their effort on avoidable rework, and about 80 percent of that rework comes from 20 percent of the defects, according to Boehm and Basili’s 2001 defect-reduction review. Hastily specified requirements are one of the major sources of that rework.
Functional faults, where software did not do what its functional requirements said, were the most common kind of software error on the National Aeronautics and Space Administration (NASA) Voyager and Galileo spacecraft. The finding comes from a Jet Propulsion Laboratory analysis of 387 errors found during integration and system testing. Behavioral faults alone made up about half of those functional faults on both spacecraft.
Finding and fixing a software problem after delivery is often far more expensive than fixing it during requirements and design, the same Boehm and Basili review found. The increase was smaller for less critical systems. Costs also escalate steeply from requirements through operations under all three estimating methods in a 2004 NASA study led by Jonette Stecklein. So the escalation measured in software holds in NASA’s whole-system estimates too, and the cost a requirements defect adds to COPQ depends on how late it is found.
How Verification and Change Control Breakdowns Add to COPQ
A change that slips past verification adds to COPQ twice, first when the defect it introduced escapes and then when everything the fix touches has to be re-verified. The Airbus A320 family’s Elevator and Aileron Computer (ELAC) shows how far a fix can reach once a change is in service. A software update to the ELAC introduced susceptibility to data corruption from intense solar radiation.
Airbus’s preliminary technical assessment identified a malfunction of the affected ELAC as a possible contributing factor in an uncommanded pitch-down on a commercial A320 flight in October 2025. The European Union Aviation Safety Agency (EASA) then issued an emergency airworthiness directive on 28 November 2025 requiring each affected ELAC to be replaced or modified before the aircraft’s next flight. “A significant number of A320 Family aircraft currently in-service” may have been affected, Airbus said the same day.
Under the superseded Quality System regulation, design changes (54 observations) and design validation (51) were the design items U.S. Food and Drug Administration (FDA) investigators cited most often on Form 483s in fiscal year 2019. The tally comes from a 2020 conference presentation by an FDA investigator. On a device program, incomplete change control traceability makes it hard to assess and document what one changed requirement affects.
Certification and clearance on regulated programs depend on traceability and verification evidence that stays current. A change that breaks a trace link or invalidates a test therefore triggers re-verification, which is internal failure when the change fixes a defect found before delivery. Change impact analysis evaluates and predicts the consequences a change can have so we can scope that re-verification to the items the change touched.
How to Measure the Upstream Share of COPQ
Tagging defects and rework by origin assigns each failure cost to the phase that created it. Five methods measure that upstream share:
- Orthogonal Defect Classification (ODC): Developed by Ram Chillarege and colleagues at IBM Research, ODC tags each defect with a type (what the fix changed) and a trigger (what exposed it). The type distribution can indicate whether requirements or design defects dominate, and the trigger distribution can indicate how complete verification was.
- Phase Containment Effectiveness (PCE): Per phase, the share of defects injected in that phase that are also found in it. PCE exists to catch and fix defects before they escape into later phases, where they are much more expensive to fix.
- Requirements verification coverage: Percentage of requirements with verified test cases, tracked against plan. Percentage of requirements verified appears as a sample technical performance measure in the Department of Defense (DoD) Systems Engineering Plan outline, with a goal of 99.99 percent.
- Requirements volatility and suspect link count: The number of requirement changes that triggered downstream rework, and the number of trace links those changes left stale. The later a requirements change arrives in the life cycle, the more systems engineering effort it adds, according to a 2015 study in the International Council on Systems Engineering (INCOSE) journal Systems Engineering.
- Rework hours by origin phase: Engineering hours logged against defect records tagged with injection phase, joined across time tracking and the defect tracker. The metric puts dollars on the requirements share directly.
PCE and rework hours by origin phase both depend on an origin-phase field on every defect and rework record, so that field is the first thing to add. On hardware programs, the records include hardware engineering change orders and design changes, tagged with the phase whose output they correct.
Some of the work that cuts the upstream share of COPQ is already on a regulated program’s schedule. Medical device programs subject to § 820.10(c) of Title 21 of the Code of Federal Regulations (CFR) hold design and development reviews under International Organization for Standardization (ISO) 13485 Clause 7.3, a requirement that covers Class II, Class III and listed Class I devices. Aircraft system suppliers get a matching recommendation, to map requirements management, validation and verification processes to the ARP4754A objectives, from a research report sponsored by the Federal Aviation Administration (FAA). A requirements-share figure built from those reviews and the defect records behind them gives us a case for shifting budget out of failure costs and into prevention.
Reducing COPQ Upstream
The upstream share of COPQ comes down when requirement and change defects are caught before anyone builds design and test work on them. In PAF terms, every practice that catches them that early is prevention or appraisal spending, at whatever point in a requirement’s life it runs.
Requirements Rules That Catch Ambiguity at Authoring
The rules for well-formed requirement statements in the INCOSE Guide to Writing Requirements target the words that create defects, among them vague terms such as “adequate,” escape clauses such as “where possible,” open-ended clauses and compound sentences. Alistair Mavin and Rolls-Royce introduced the Easy Approach to Requirements Syntax (EARS), which constrains natural-language requirements to a small set of clause patterns. We can follow the same patterns teams at Airbus and NASA use.
Rules only reduce COPQ if we check every requirement against them, which at program scale means automating the check. Tested across 2,725 requirements from 13 financial-domain systems, an automated checker detected requirement smells (wording that signals a likely quality problem) with 89 percent precision and recall. The checker’s recommended fixes, drawn from a controlled requirements language, reached 96 percent precision and 94 percent recall in what the paper called the largest industrial case study to date on requirements quality assurance.
Requirements and Design Inspections Before Downstream Work
Formal inspections catch many defects before later work depends on them. On one IBM applications project, inspections found 82 percent of the errors and saved 25 percent of programmer resources, Michael Fagan reported in 1976. Inspected code on an IBM operating-system component had 38 percent fewer errors than a comparable walk-through sample over seven months of testing. Running an inspection each time a requirement changes extends the same logic to smaller batches, which the IBM studies did not test directly.
On a medical device program, a design review that runs each time a requirement changes can catch the change while few items depend on it. Reviewing at every change depends on review cycles short enough to finish before the next change lands. Grifols reported cutting review cycles from 90 days to fewer than 30 days and saving more than 80 hours per project. The company runs its reviews in Jama Connect®, a web-based requirements management and traceability platform for complex, regulated product development.
Grifols’ Diagnostic Divisions R&D Instruments Senior Manager described reviewing in Review Center this way. “With Review Center, we review things more incrementally, and we can catch changes, or things to fix, very early in the process. So, the cost at the end is less.”
Traceability Evidence for Changed Requirements
More complete requirements traceability decreases the expected defect rate in developed software, according to a 2017 paper in the Institute of Electrical and Electronics Engineers (IEEE) Transactions on Software Engineering that analyzed 24 medium-to-large open-source projects. With traceability in place, a changed requirement marks its linked tests and design items for review, so the rework it causes is caught while it is still a document edit and well before it becomes scrap. After FORT Robotics moved its product development off spreadsheets, it reported a 30%+ decrease in rework in less than a year. Rework like that sits on the internal-failure line of COPQ, and tagging each rework record by origin phase shows how much of a program’s rework traces to requirements.
How Jama Connect Supports Reducing the Cost of Poor Quality
To address defective requirements, Jama Intelligence scores each requirement against 30 of the 40 INCOSE rules and 6 EARS patterns as it is written, and generates a rewrite that the engineer accepts or rejects. Jama Intelligence is an add-on for Jama Connect Cloud. The Traceability Information Model (TIM) defines which downstream items each requirement must have and flags the ones that are missing. A requirement change marks the link to every downstream item as suspect, and each suspect link is a piece of potential rework for an engineer to assess and resolve by updating the item or clearing the suspect link.
For measurement, Live Trace Explorer™ identifies requirements without downstream test cases, surfaces test cases that have not been executed and reports the percentage of suspect relationships still unassessed. Each defect logged against a failed test step keeps its trace back to the test case and the originating requirement. A custom origin-phase field on the defect item type then lets the team count defects by injection phase straight from those records, with no reconstruction by hand. The two remaining measures, ODC’s type and trigger tags and rework hours by origin phase, still depend on the team’s own defect classification and time tracking.
Tracking the Cost of Poor Quality in Your Requirements Process
Tagging the next design review’s findings with an origin phase from the first entry, and one quarter’s scrap, rework and field-action costs with the requirement each corrected, turns the requirements share of COPQ into a measured figure on the ledger. Working out what that origin-phase field should hold, and how a changed requirement traces through to the defects logged against it, is a job for a free 30-day trial with full access to Jama Connect, before a live program depends on either.
Frequently Asked Questions About Cost of Poor Quality
What is the difference between cost of quality and cost of poor quality?
COQ counts everything a program spends on quality, adding prevention and appraisal spending to the internal and external failure costs. In the two-category view this guide’s formula uses, COPQ is the failure share alone, the money that would disappear if the work were right the first time. Prevention and appraisal costs also sit under COPQ in ASQ’s glossary entry, so where the line falls depends on the model a team adopts. Tracking COQ and COPQ side by side shows whether a quality budget goes mostly to preventing defects or to paying for them after they escape.
Is it true that half of all defects originate in requirements?
No primary study supports that figure. One origin is James Martin’s 1984 book An Information Systems Manifesto, which reported that 56 percent of the bugs at one unnamed large bank were in the requirements document, a count from a single installation. Requirements-stage defects made up 15.6 percent of the defects developers reported in transportation manufacturing and 30.3 percent in financial services, in NIST’s 2002 surveys. Most of them surfaced after the requirements stage, and that timing is the stronger argument for improving the requirements engineering process.
Can COPQ be estimated before failures happen?
Only roughly, by weighting identified safety-critical failure modes by their risk. Each failure mode’s Risk Priority Number (RPN), based on severity, occurrence and detection, can weight the average effort and hourly cost to resolve a failure. Multiplying that RPN-weighted cost by the expected reduction in failure events turns Failure Modes and Effects Analysis (FMEA) into a COPQ estimate. The published method was written for Six Sigma process-improvement projects, so a design team has to supply its own estimate of how many failures a change will prevent.
What did Philip Crosby mean by the price of nonconformance?
Crosby used the phrase for the expense of doing things wrong, including scrap, rework, warranty service, inspection and testing made necessary by nonconformance. The phrase casts a wider net than the two-category COPQ formula because it counts inspection and testing forced by defects.
