Regulatory Open Forum

Best practice includes early communication and negotiation about requirements at a high level.

First the Marketing function may say where are the target markets and the Design function may suggest the product concept. Then the Regulatory function can evaluate relevant regulations and extract some hard requirements.

Standards compliance comes next. The Regulatory function can say which standards are required or recommended, in full or in part, for the product type in those jurisdictions, and whether third-party verification of compliance is required vs in-house verifications. Of course the process can be iterative... If the cost of compliance is too high, the design could be changed or the list of target markets could be shortened.

Once the standards list is agreed, the Design and Design Quality functions convert the applicable sections of the standards into verifiable requirements that are applicable to the design concept.

As you say, you can't expect any one person in any one functional area to have all the expertise. It often takes some discussion, with each party sharing what they know and don't know about the relevant topics, and some trial-and-error to find effective ways of working together. It also takes some recognition that requirements development is a valuable process that needs resourcing with people and time.

To add an extra dimension on to the great responses from Anne and Ed; your teams need to know what they are looking for. Requirements from regulations are more likely to be very high level in terms of performance etc, apart from those that stipulate the labelling/IFU content etc. Requirements from standards will be a mixed bag of design requirements, design specifications (maybe), test methods, acceptance criteria and maybe even some performance criteria for the intended use (e.g. some standards for implants have lifetime performance criteria). The markets and the applicable standards (even if only partially applicable) need to be decided upon (as Anne said) and then the team need to review, identify, extract and translate into your internal method for documenting requirements etc. For those with large product portfolios with similar intended uses, then there will be lots of requirements etc. that can be applied across multiple product families. For those with small and developing product portfolios, then it is a chance to clearly identify your product requirements and then strategically iterate on how you fulfil those requirements and/or add new requirements to develop your product and/or portfolio.

To add an extra dimension on to the great responses from Anne and Ed; your teams need to know what they are looking for. Requirements from regulations are more likely to be very high level in terms of performance etc, apart from those that stipulate the labelling/IFU content etc. Requirements from standards will be a mixed bag of design requirements, design specifications (maybe), test methods, acceptance criteria and maybe even some performance criteria for the intended use (e.g. some standards for implants have lifetime performance criteria). The markets and the applicable standards (even if only partially applicable) need to be decided upon (as Anne said) and then the team need to review, identify, extract and translate into your internal method for documenting requirements etc. For those with large product portfolios with similar intended uses, then there will be lots of requirements etc. that can be applied across multiple product families. For those with small and developing product portfolios, then it is a chance to clearly identify your product requirements and then strategically iterate on how you fulfil those requirements and/or add new requirements to develop your product and/or portfolio.

For ease of maintenance when things change, it helps to trace which product requirements were derived from which standards.

To add an extra dimension on to the great responses from Anne and Ed; your teams need to know what they are looking for. Requirements from regulations are more likely to be very high level in terms of performance etc, apart from those that stipulate the labelling/IFU content etc. Requirements from standards will be a mixed bag of design requirements, design specifications (maybe), test methods, acceptance criteria and maybe even some performance criteria for the intended use (e.g. some standards for implants have lifetime performance criteria). The markets and the applicable standards (even if only partially applicable) need to be decided upon (as Anne said) and then the team need to review, identify, extract and translate into your internal method for documenting requirements etc. For those with large product portfolios with similar intended uses, then there will be lots of requirements etc. that can be applied across multiple product families. For those with small and developing product portfolios, then it is a chance to clearly identify your product requirements and then strategically iterate on how you fulfil those requirements and/or add new requirements to develop your product and/or portfolio.

We have a small systems engineering group that prides themselves on excellence in requirements development. They need help in finding the right set of standards for a product, but they have learned how to read them.

https://www.incose.org/communities/working-groups-initiatives/requirements

Original Message:
Sent: 29-Apr-2024 10:37
From: Anonymous Member
Subject: Derivation of product requirements from regulatory information/standards - Best practice?

This message was posted by a user wishing to remain anonymous

For ease of maintenance when things change, it helps to trace which product requirements were derived from which standards.

To add an extra dimension on to the great responses from Anne and Ed; your teams need to know what they are looking for. Requirements from regulations are more likely to be very high level in terms of performance etc, apart from those that stipulate the labelling/IFU content etc. Requirements from standards will be a mixed bag of design requirements, design specifications (maybe), test methods, acceptance criteria and maybe even some performance criteria for the intended use (e.g. some standards for implants have lifetime performance criteria). The markets and the applicable standards (even if only partially applicable) need to be decided upon (as Anne said) and then the team need to review, identify, extract and translate into your internal method for documenting requirements etc. For those with large product portfolios with similar intended uses, then there will be lots of requirements etc. that can be applied across multiple product families. For those with small and developing product portfolios, then it is a chance to clearly identify your product requirements and then strategically iterate on how you fulfil those requirements and/or add new requirements to develop your product and/or portfolio.