Every CTQ without a defined acceptance criterion and verification approach creates design risk. DFSS requirements traceability connects each Critical-to-Quality characteristic to its customer need, a measurable acceptance criterion, a suitable verification method, and an accountable evidence owner before design freeze.
If the team cannot answer "How will we prove this requirement is met?", the CTQ is not ready for release. This article shows how to assign requirement IDs, define acceptance criteria, select verification methods, and identify who owns the evidence.
Key Takeaways
- Trace each CTQ back to a customer need.
- Give every requirement a unique, stable ID.
- Define measurable acceptance criteria early.
- Choose verification methods with documented rationale.
- Assign ownership and retain objective evidence.
Traceability is more than documentation. It is a design discipline that clarifies what the product must do and how the team will prove it.
What DFSS Requirements Traceability Requires at the CTQ Verification Matrix Level
In DFSS, each CTQ should trace backward to the customer need that created it and forward to the evidence used to verify it. This bidirectional link helps teams assess the effect of requirement changes and confirm that every approved requirement has a verification path.
The NASA Systems Engineering Handbook lists test, analysis, inspection, and demonstration as verification methods and recommends identifying the method while requirements are developed. NASA's requirements verification matrix guidance also calls for a unique requirement identifier, source, planned method, verification level, success criteria, and verification lead.
A response-time CTQ such as "the device shall respond within two seconds" remains incomplete until the team defines the operating conditions, measurement procedure, acceptance rule, and responsible approver. Sample size or confidence requirements should be included when they are relevant to the evidence, not treated as mandatory fields for every CTQ.
1. Assign a Unique Requirement ID to Every CTQ
A requirement ID gives the CTQ a stable label that follows it through design reviews, verification plans, and closure records. Use a structured format such as CTQ-001 or REQ-SYS-014 that fits the system hierarchy and remains unchanged across revisions.
2. State the Customer Need in Plain Language First
Record the customer need in clear language before translating it into a technical specification. This preserves the rationale for the CTQ and helps reviewers distinguish customer-driven requirements from internal design preferences.
3. Write Measurable Acceptance Criteria Early
Acceptance criteria define what counts as a pass. Specify the target, tolerance, unit, applicable conditions, and any required statistical confidence or decision rule before finalizing the verification plan.
4. Select the Verification Method Based on Evidence Needs
Test, analysis, inspection, and demonstration provide different kinds of evidence. Select the method—or combination of methods—that can reliably show compliance, considering requirement criticality, technical feasibility, model validity, cost, schedule, and applicable regulatory or contractual obligations.
Physical testing is not automatically the best method for every high-risk CTQ. A validated analysis, qualified similarity argument, inspection, or demonstration may be appropriate when it supplies sufficient objective evidence and the governing requirements allow it.
5. Name an Accountable Evidence Owner
Assign one accountable individual or clearly defined role to coordinate the evidence for each CTQ. Supporting work may span several functions, but ownership for completing, reviewing, and archiving the verification record should be unambiguous.
6. Record Verification Status at Each Design Gate
Update the matrix as requirements and designs mature. Use clear status values such as planned, in progress, passed, failed, deferred, or closed, and escalate unresolved CTQs according to the program's risk and change-control process.
7. Archive Evidence With the Requirement ID
Link test reports, analysis files, inspection records, demonstrations, approvals, and other closure artifacts to the applicable requirement ID. This makes the evidence retrievable for reviews, audits, later changes, and lessons learned.
A Complete DFSS Requirements Traceability Example: From Customer Need to Test Evidence
The following example is illustrative. Its values, names, and planned test details are fictional and are not medical-device guidance or empirical findings.
Imagine a medical-device development team records this customer need: "The user must be able to read the display clearly in the intended clinical environment." The team could translate that need into a display-luminance CTQ, then confirm the final criterion through human-factors, risk, and regulatory review.
| Field | Illustrative Entry |
|---|---|
| Requirement ID | CTQ-007 |
| Customer Need | Display readable in the intended clinical environment |
| CTQ Description | Display luminance under defined ambient lighting and viewing conditions |
| Acceptance Criterion | Project-defined luminance threshold, viewing angle, ambient illumination, and measurement tolerance |
| Verification Method | Test using a calibrated photometer and an approved procedure |
| Test Condition | Approved unit count, repeat measurements, ambient-light range, and viewing geometry |
| Evidence Owner | Human Factors Engineering Lead |
| Verification Status | Planned—targeted for design verification |
| Evidence Reference | DVT-Report-CTQ-007-Rev-A, to be assigned at closure |
This row connects one customer need to a measurable requirement and a planned verification record. The actual threshold, sample size, test conditions, and approval route must come from the project's risk analysis, intended-use definition, applicable standards, and documented design controls.
Apply the same logic across the CTQ set. Blank criteria, "TBD" methods, unsupported analytical models, unclear ownership, or missing evidence references are gaps that should be resolved or formally dispositioned before the relevant design gate.
The Design for Six Sigma Scorecard Short Course helps teams organize CTQ performance and development evidence so gaps can be seen earlier in the design process.
How to Find CTQs With No Credible Verification Path Before Design Freeze
Audit the traceability matrix for missing criteria, infeasible methods, unclear ownership, and evidence that cannot be retrieved. The timing and severity of each gap depend on the project's lifecycle, risk classification, and applicable quality system.
Review every CTQ assigned to analysis and confirm that the model, assumptions, input data, uncertainty treatment, and validation basis are adequate for the decision. If analysis cannot supply credible evidence, choose another approved method or revise the requirement through change control.
- Flag criteria that rely on undefined terms such as "acceptable," "sufficient," or "as required."
- Replace vague ownership with an accountable person or defined role.
- Review regulatory, safety, and contractual requirements against their governing evidence rules.
- Match the verification method to the required evidence, not team convenience.
- Confirm that conditions represent the specified operating and use environments.
The Detailed Design (HOQ 2) Short Course supports the translation of customer requirements into technical specifications. Clearer specifications make acceptance criteria and verification planning more direct.
NASA's approach identifies verification methods while requirements are developed, rather than waiting until the design is complete. Early planning exposes requirements that are ambiguous, infeasible, or costly to verify while the team still has options.
Air Academy Associates Resources That Support DFSS Requirements Traceability
These four Air Academy Associates offerings support different parts of the work, from CTQ definition to test coverage and full IDOV application.
Design for Six Sigma Scorecard Short Course
The DFSS Scorecard Short Course teaches a structured way to track design performance against important CTQs and customer requirements. It can help teams organize evidence for design reviews and identify performance gaps.
- Organizes CTQ performance for design reviews
- Supports early visibility into design gaps
- Connects customer priorities with design tracking
Detailed Design (HOQ 2) Short Course
The Detailed Design HOQ 2 course applies Quality Function Deployment to translate customer requirements into technical specifications. This strengthens the specification work that verification planning depends on.
- Converts customer requirements into technical specifications
- Supports measurable design targets
- Links detailed design decisions to customer needs
Validation Testing Short Course
The Validation Testing Short Course covers efficient test planning when many factor combinations are possible. Its topics include all-pairs testing, representative sampling, Latin hypercube sampling, and descriptive sampling.
- Compares practical test-coverage strategies
- Addresses factor combinations and representative sampling
- Connects screening, modeling, and validation testing
Design for Six Sigma Green Belt (IDOV) Online Training
The Design for Six Sigma Green Belt (IDOV) Online Training places requirements work within the Identify, Design, Optimize, and Validate framework. It provides broader DFSS context for practitioners who need to connect CTQs, risk analysis, design decisions, optimization, and validation.
- Provides self-paced DFSS training
- Covers the full IDOV framework
- Builds practical design-project competency
Conclusion
DFSS requirements traceability connects customer needs to measurable CTQs and objective evidence. Give each CTQ a stable ID, defined acceptance criteria, an appropriate verification method, accountable ownership, and a retrievable evidence reference.
Air Academy Associates offers DFSS training and certification to help teams strengthen CTQ definition, requirements flowdown, design reviews, and verification planning. Explore the available programs to choose the level of support that fits your team.
FAQs
How Do You Link Each CTQ to Verifiable Evidence?
Translate the CTQ into an objective requirement with defined conditions and acceptance criteria. Assign one or more approved verification methods, an accountable owner, and an evidence reference such as a test report, analysis record, inspection log, or demonstration record.
What Fields Belong in a DFSS Traceability Matrix?
Useful fields include the customer need, CTQ definition, requirement ID, requirement statement, source or rationale, target and tolerance, priority or risk, allocation, verification method and level, conditions, acceptance criteria, owner, status, planned date, and evidence reference. Tailor the matrix to the project's lifecycle, governing procedures, and compliance obligations.
How Do You Identify Requirements Without a Feasible Test?
First decide whether analysis, inspection, demonstration, similarity, simulation, or a combination can provide acceptable objective evidence under the governing process. If no credible method exists, clarify or revise the requirement through approved change control instead of carrying an unverifiable statement forward.
Related Articles
