Dear Forum,

I´m working on requirements specification and test specifications according to the V-Model. I have seen examples on traceability matrices in which single (user) requirements are traced to corresponding test cases.

Is there any explicit requirement in QSR (or ISO-13485) to have a traceability of requirements from User Requirements to Verification and Validation Testing?

If such a requirement exists, or if this is current practice, how "deep" should these traceability go? I mean, a top level user requirement might result in 10 sub-requirements which in turn each result in 10 new sub-requirement. Keeping track of the dependencies between the requirements and verification test cases might be time consuming with this approach.


[I already did a search through the relevant forums...could not find any post answering my question though some threads deal with it...]

best regards
t.

At first glance the FDA seems to be silent on customer requirements. However, ISO 13485 has something to say about (see section 7.2).

A customer requirement can be something very simple and abstract like "customer wants the device to be red". Customer requirements usually involve ideas, not specifications (but not always). The design team turns those ideas into specifications or inputs.

Just define your customer requirements from the get go. Use that to develop your inputs and focus only on verifying that your output meets your inputs.

By the way, what's the V-Model.

As I'm sure you're aware, you are required to show adequate evaluation of (design outputs) conformance to design input requirements. As you are using the V model, you do that at each stage. From my experience, it's pretty much up to you how you define that.

When we develop a product that has customer requirements, we typically map (trace) those to a top-level specification document. We trace to subsequent specification and design docs and eventually to test. Our requirements management tool provides the support needed to show traceability from customer requirements to test. Were we to try this manually, it would be quite a chore. For one of our larger projects, this mushrooms up to hundreds of pages of a trace table. But it has been VERY well received by auditors and regulatory consultants.

Hope that helps.

P.S. QA-Man, the V model is essentially a mapping of development stages to associated test levels. Here's a link to a wikipedia discussion on it: http://en.wikipedia.org/wiki/V-Model

.......By the way, what's the V-Model.

FDA also refers this as the Waterfall Design Process" where all the stages right from Design and developmental planning go through Design Input, Design Output, Design Review, Design Verification, Design Validation, Design Transfer, Design Changes and Design History File (DHF).

Refer FDA's DESIGN CONTROL GUIDANCE FOR MEDICAL DEVICE MANUFACTURERS (http://www.fda.gov/cdrh/comp/designgd.pdf)