Requirements traceability matrix

What design control traces

Design control is the discipline of turning what users need into a design that provably meets it. It runs as a chain:

• User needs state what the user, patient or market needs, in their own terms: "comfortable to breathe around the clock".
• Design inputs turn each need into requirements the design must meet, written so they can be checked: "outlet temperature 37 °C ±2 °C at 5 to 60 L/min". Inputs also come from regulations, standards and the risk analysis.
• Design outputs are the design itself: drawings, specifications, software, labeling, manufacturing instructions.
• Verification confirms that the outputs meet the inputs. Did we build the design right?
• Validation confirms that the finished device meets the user needs in its intended use. Did we build the right design?

A requirements traceability matrix records the links, so that anyone can follow a need down to the test that proves it, or start from a drawing and find out why it exists.

The gaps it finds

• A need with no design input: a requirement was never written, so nobody designed for it.
• An input with no verification: a requirement nobody has shown is met. This is the commonest gap, and the most serious when the input is a risk control.
• A need with no validation: the device may meet every specification and still not do what the user needs.
• Orphans: an input that traces to no need, or an output that implements no input. Either the trace is incomplete, or something is in the design that does not need to be, adding cost and its own risks.

Requirements from regulations and standards are often shown by verifying their inputs rather than by a separate validation study, so they are marked "by verification" rather than as a gap. Say so in the validation plan.

Risk controls in the trace

Each risk control from the hazard analysis becomes a design input, and its verification is the evidence that the control was implemented and works. Carrying the hazard ID on the input links the two files, so a change to either can be followed through to the other.

Keeping it alive

The matrix is built up through the project and reviewed at each design review. Design changes are traced the same way: which needs, inputs, outputs and tests does this change touch, and which tests must be repeated? A matrix assembled at the end, just before submission, usually shows the gaps too late to fix them cheaply.

Validation uses initial production units, or their equivalent, under actual or simulated use. A study on prototypes needs a justification of why its results still hold for the production design.

Related tools

QFD and the CTQ tree are ways to turn the voice of the customer into design inputs; the matrix keeps track of them afterward. The IQ/OQ/PQ protocol validates the manufacturing process, which is a different thing from validating the design.

On the exam

CQE III.B.1 asks you to classify design inputs from customer needs, regulatory requirements and risk assessment, and III.B.2 names requirements traceability as a design technique. CQE III.D covers interpreting verification and validation results. CMDA III.D.2 asks you to evaluate design and development controls: planning, input, output, review, verification, validation, transfer, changes and the design file. CMDA IV.A.2 asks you to verify that risk controls were implemented in the design. Expect to tell verification from validation, and to spot the gap in a short trace.

Other tools and templates