Regulatory Open Forum

Hi all,
 I was hoping someone could help me understand the relationship between the terms "Design Input Requirements" and "System (or Subsystem) Requirements Specifications." 

My understanding is that User Needs and Intended Uses are first determined at the beginning of a development effort, and then these are translated into Design Input Requirements along with regulatory requirements, outputs of risk management, etc (per ISO 13485:2016 7.3.3). These Design Input Requirements, written to an engineering level of detail, can take the form of system-level requirements, such as System Requirements Specifications and/or subsystem-level requirements, such as Software Requirements Specifications, Hardware Requirements Specifications, Labeling Requirements, etc. 

However, I was recently told that Design Input Requirements are typically different than System Requirement Specifications, that they are more general and high-level, and contain User Needs as a subsection. So the process would go User Needs -> DIR -> System Requirement Specifications.  Now I'm totally confused.

So I have two questions:
(1) How are Design Input Requirements related to System Requirement Specifications and Subsystem Requirement Specifications?
(2) How many layers of requirement specifications do you tend to use (i.e., do you have a single System Requirement Specification that contains all of the subsystem specifications as well, do you go straight to subsystem requirement specifications and skip the comprehensive document, or do you have a higher-level System Requirements Specification that is then broken down into more detailed Sub-system Requirement Specifications?).

Thanks in advance!
   Aimee

------------------------------
Aimee Feuser
Chicago IL
United States
------------------------------

Aimee,
Yes, there are a lot of terms thrown around with respect to user needs, design inputs, etc.

My best advice is to refer to what is stated in FDA regulations and  ISO 13485:2016 requirements.

21 CFR Part 820.30(c) - Design Input:
(c) Design input. Each manufacturer shall establish and maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient. The procedures shall include a mechanism for addressing incomplete, ambiguous, or conflicting requirements. The design input requirements shall be documented and shall be reviewed and approved by a designated individual(s). The approval, including the date and signature of the individual(s) approving the requirements, shall be documented. 

ISO 13485:2016 Section 7.3.3 - Design and development inputs:
Inputs relating to product requirements shall be determined and records maintained (see 4.2.5). These
inputs shall include:
a) functional, performance, usability and safety requirements, according to the intended use;
b) applicable regulatory requirements and standards;
c) applicable output(s) of risk management;
d) as appropriate, information derived from previous similar designs;
e) other requirements essential for design and development of the product and processes.
These inputs shall be reviewed for adequacy and approved.
Requirements shall be complete, unambiguous, able to be verified or validated, and not in conflict with
each other.

Of course refer to the entire 820.30 and ISO 13485 section 7.3 for explanation on relationship of all design controls.

With respect to your questions, let me address those items.

(1) How are Design Input Requirements related to System Requirement Specifications and Subsystem Requirement Specifications? --> These are all under "design inputs". (Note that sometimes the term "specification" can be used to describe design outputs. Confusing, I know.)

(2) How many layers of requirement specifications do you tend to use (i.e., do you have a single System Requirement Specification that contains all of the subsystem specifications as well, do you go straight to subsystem requirement specifications and skip the comprehensive document, or do you have a higher-level System Requirements Specification that is then broken down into more detailed Sub-system Requirement Specifications?). --> There is no "one size fits all" response to this. Some like to add several levels to design inputs. Doing so will mean that each and every level will require traceability to design outputs and design verification. In my experience, most medical device product development projects do not require these multiple levels. 

Traceability is key. Keeping all design controls information organized and traced can be a very challenging thing.

If you would like to discuss further, reach out to me any time.

------------------------------
Jon Speer
Greenlight.Guru
Indianapolis IN
United States
------------------------------

Original Message:
Sent: 07-Aug-2017 19:49
From: Aimee Feuser
Subject: Terminology confusion: Design Input Requirements

Hi all,
 I was hoping someone could help me understand the relationship between the terms "Design Input Requirements" and "System (or Subsystem) Requirements Specifications."

My understanding is that User Needs and Intended Uses are first determined at the beginning of a development effort, and then these are translated into Design Input Requirements along with regulatory requirements, outputs of risk management, etc (per ISO 13485:2016 7.3.3). These Design Input Requirements, written to an engineering level of detail, can take the form of system-level requirements, such as System Requirements Specifications and/or subsystem-level requirements, such as Software Requirements Specifications, Hardware Requirements Specifications, Labeling Requirements, etc.

However, I was recently told that Design Input Requirements are typically different than System Requirement Specifications, that they are more general and high-level, and contain User Needs as a subsection. So the process would go User Needs -> DIR -> System Requirement Specifications.  Now I'm totally confused.

So I have two questions:
(1) How are Design Input Requirements related to System Requirement Specifications and Subsystem Requirement Specifications?
(2) How many layers of requirement specifications do you tend to use (i.e., do you have a single System Requirement Specification that contains all of the subsystem specifications as well, do you go straight to subsystem requirement specifications and skip the comprehensive document, or do you have a higher-level System Requirements Specification that is then broken down into more detailed Sub-system Requirement Specifications?).

Thanks in advance!
   Aimee

------------------------------
Aimee Feuser
Chicago IL
United States
------------------------------

Yes, it is confusing, mainly because every company uses terms like "specification," "user/customer requirements" etc differently. It did not help that the QSR goes partly to "Design for Six Sigma" concepts, but not all the way, and uses different terms for the same things "classical" DfSS includes.

That said, at a minimum I would generally expect that you have a high level, general, list of customer/user requirements, whatever you call it. Then there would be at least one detail level where that is broken down into engineering level of detail. If only having two levels, most people call this an "engineering specification" or something similar.

However, a best practice is really to include the number of levels that you need. At the top level, that might include customer needs, business requirements, a use risk analysis etc. The next level would be system level "detailed" requirements. These then get deconstructed into sub-system level requirements, which get deconstructed into the requirements for various components. There can be multiple levels of this.

Also design teams need to remember to add to the lower level requirements as they make design decisions - requirements creation is really an iterative process when done right - and too many companies seem to think it is a single "deliverable" at the beginning of a project.

For an example, a top level user requirement might be "must be used in the sterile field of an OR." A system level requirement might be "must be sterile with an SAL of 10^-6." At some point, EtO is chosen as the method of sterilization. This leads to derived requirements not only that come from the ISO standard on EtO, but ALSO to requirements at the sub-system and component level that the materials must withstand heat and humidity levels found during EtO cycles. It obviously also leads to requirements for the packaging components related to EtO transmission, porosity etc. And, depending on the device, it could lead to design requirements relating to channel sizes etc.

All of these requirements should sit at some level of your heirarchy. Though it can all be at one level, generally that is very confusing to follow and trace, and can lead to misses in future product revisions and updates. At least that has been my experience.

Ginger

------------------------------
Ginger Glaser RAC
Vice-President, Engineering
Monteris Medical
------------------------------

Original Message:
Sent: 07-Aug-2017 19:49
From: Aimee Feuser
Subject: Terminology confusion: Design Input Requirements

Hi all,
 I was hoping someone could help me understand the relationship between the terms "Design Input Requirements" and "System (or Subsystem) Requirements Specifications."

My understanding is that User Needs and Intended Uses are first determined at the beginning of a development effort, and then these are translated into Design Input Requirements along with regulatory requirements, outputs of risk management, etc (per ISO 13485:2016 7.3.3). These Design Input Requirements, written to an engineering level of detail, can take the form of system-level requirements, such as System Requirements Specifications and/or subsystem-level requirements, such as Software Requirements Specifications, Hardware Requirements Specifications, Labeling Requirements, etc.

However, I was recently told that Design Input Requirements are typically different than System Requirement Specifications, that they are more general and high-level, and contain User Needs as a subsection. So the process would go User Needs -> DIR -> System Requirement Specifications.  Now I'm totally confused.

So I have two questions:
(1) How are Design Input Requirements related to System Requirement Specifications and Subsystem Requirement Specifications?
(2) How many layers of requirement specifications do you tend to use (i.e., do you have a single System Requirement Specification that contains all of the subsystem specifications as well, do you go straight to subsystem requirement specifications and skip the comprehensive document, or do you have a higher-level System Requirements Specification that is then broken down into more detailed Sub-system Requirement Specifications?).

Thanks in advance!
   Aimee

------------------------------
Aimee Feuser
Chicago IL
United States
------------------------------

Thanks so much to both of you for your responses. This is beginning to make a lot more sense.

Follow up question: when detailed system requirements are broken down into subsystem requirements, is there usually a verification process that goes with this? (I.e., are the subsystem-level requirement specifications considered a form of design output from the system-level requirement specifications and therefore require verification to make sure they meet them?).

Also, it seems to me that after defining system requirements, some design work is needed to determine the composition of subsystems that will fulfill the system-level design requirements. Is this correct? Would this be called a "System Design Specification" or something similar?

Finally, what "phase" of the Design Controls process would these fall into? We've defined five phases:
(1) Planning & Requirements (I'm guessing high-level product requirements, including user needs and intended uses go here)
(2) Design & Development (Would System and Sub-system Requirements Specifications be defined here?)
(3) Formal Verification & Validation
(4) Design Transfer
(5) Distribution & Monitoring

I've included two diagrams of the process and I'm not sure which one is more conceptually correct. 

Thanks again!!
    Aimee



------------------------------
Aimee Feuser
Chicago IL
United States
------------------------------

Original Message:
Sent: 08-Aug-2017 08:44
From: Ginger Glaser
Subject: Terminology confusion: Design Input Requirements

Yes, it is confusing, mainly because every company uses terms like "specification," "user/customer requirements" etc differently. It did not help that the QSR goes partly to "Design for Six Sigma" concepts, but not all the way, and uses different terms for the same things "classical" DfSS includes.

That said, at a minimum I would generally expect that you have a high level, general, list of customer/user requirements, whatever you call it. Then there would be at least one detail level where that is broken down into engineering level of detail. If only having two levels, most people call this an "engineering specification" or something similar.

However, a best practice is really to include the number of levels that you need. At the top level, that might include customer needs, business requirements, a use risk analysis etc. The next level would be system level "detailed" requirements. These then get deconstructed into sub-system level requirements, which get deconstructed into the requirements for various components. There can be multiple levels of this.

Also design teams need to remember to add to the lower level requirements as they make design decisions - requirements creation is really an iterative process when done right - and too many companies seem to think it is a single "deliverable" at the beginning of a project.

For an example, a top level user requirement might be "must be used in the sterile field of an OR." A system level requirement might be "must be sterile with an SAL of 10^-6." At some point, EtO is chosen as the method of sterilization. This leads to derived requirements not only that come from the ISO standard on EtO, but ALSO to requirements at the sub-system and component level that the materials must withstand heat and humidity levels found during EtO cycles. It obviously also leads to requirements for the packaging components related to EtO transmission, porosity etc. And, depending on the device, it could lead to design requirements relating to channel sizes etc.

All of these requirements should sit at some level of your heirarchy. Though it can all be at one level, generally that is very confusing to follow and trace, and can lead to misses in future product revisions and updates. At least that has been my experience.

Ginger

------------------------------
Ginger Glaser RAC
Vice-President, Engineering
Monteris Medical

Original Message:
Sent: 07-Aug-2017 19:49
From: Aimee Feuser
Subject: Terminology confusion: Design Input Requirements

Hi all,
 I was hoping someone could help me understand the relationship between the terms "Design Input Requirements" and "System (or Subsystem) Requirements Specifications."

My understanding is that User Needs and Intended Uses are first determined at the beginning of a development effort, and then these are translated into Design Input Requirements along with regulatory requirements, outputs of risk management, etc (per ISO 13485:2016 7.3.3). These Design Input Requirements, written to an engineering level of detail, can take the form of system-level requirements, such as System Requirements Specifications and/or subsystem-level requirements, such as Software Requirements Specifications, Hardware Requirements Specifications, Labeling Requirements, etc.

However, I was recently told that Design Input Requirements are typically different than System Requirement Specifications, that they are more general and high-level, and contain User Needs as a subsection. So the process would go User Needs -> DIR -> System Requirement Specifications.  Now I'm totally confused.

So I have two questions:
(1) How are Design Input Requirements related to System Requirement Specifications and Subsystem Requirement Specifications?
(2) How many layers of requirement specifications do you tend to use (i.e., do you have a single System Requirement Specification that contains all of the subsystem specifications as well, do you go straight to subsystem requirement specifications and skip the comprehensive document, or do you have a higher-level System Requirements Specification that is then broken down into more detailed Sub-system Requirement Specifications?).

Thanks in advance!
   Aimee

------------------------------
Aimee Feuser
Chicago IL
United States
------------------------------

AImee,

I typically have it set up closer to the first diagram you mentioned (though with a couple extra levels beneath hardware & software specifications). Though I would call all of that higher level "inputs" - there would be later documents (drawing, material specs etc) that would be the outputs. That said, either could probably work depending on how you write the definitions in your QS. Generally though, I tend to use the term "requirements" across levels of input documents and save "specifications" for outputs. I know that isn't convention in things like software though :-)

We do verify every level of requirements - though in many different ways. At the component level, for instance, we often use our inspection processes as verification.

You can link into a "Phase/Gate" system however you like, though commonly the highest level inputs are in one of the earlier stages, and most requirements are settled by a middle phase (often the one before DV is done).

Good design practices are a subject to themselves, and reach far beyond a regulatory requirements - though I do applaud FDA for attempting to integrate such practices into the regs. Unfortunately, the regs were written vaguely enough that many of those practices still get ignored.

g-

------------------------------
Ginger Glaser RAC
Vice-President, Engineering
Maplewood MN
United States
------------------------------

Original Message:
Sent: 08-Aug-2017 09:47
From: Aimee Feuser
Subject: Terminology confusion: Design Input Requirements

Thanks so much to both of you for your responses. This is beginning to make a lot more sense.

Follow up question: when detailed system requirements are broken down into subsystem requirements, is there usually a verification process that goes with this? (I.e., are the subsystem-level requirement specifications considered a form of design output from the system-level requirement specifications and therefore require verification to make sure they meet them?).

Also, it seems to me that after defining system requirements, some design work is needed to determine the composition of subsystems that will fulfill the system-level design requirements. Is this correct? Would this be called a "System Design Specification" or something similar?

Finally, what "phase" of the Design Controls process would these fall into? We've defined five phases:
(1) Planning & Requirements (I'm guessing high-level product requirements, including user needs and intended uses go here)
(2) Design & Development (Would System and Sub-system Requirements Specifications be defined here?)
(3) Formal Verification & Validation
(4) Design Transfer
(5) Distribution & Monitoring

I've included two diagrams of the process and I'm not sure which one is more conceptually correct.

Thanks again!!
    Aimee



------------------------------
Aimee Feuser
Chicago IL
United States

Original Message:
Sent: 08-Aug-2017 08:44
From: Ginger Glaser
Subject: Terminology confusion: Design Input Requirements

Yes, it is confusing, mainly because every company uses terms like "specification," "user/customer requirements" etc differently. It did not help that the QSR goes partly to "Design for Six Sigma" concepts, but not all the way, and uses different terms for the same things "classical" DfSS includes.

That said, at a minimum I would generally expect that you have a high level, general, list of customer/user requirements, whatever you call it. Then there would be at least one detail level where that is broken down into engineering level of detail. If only having two levels, most people call this an "engineering specification" or something similar.

However, a best practice is really to include the number of levels that you need. At the top level, that might include customer needs, business requirements, a use risk analysis etc. The next level would be system level "detailed" requirements. These then get deconstructed into sub-system level requirements, which get deconstructed into the requirements for various components. There can be multiple levels of this.

Also design teams need to remember to add to the lower level requirements as they make design decisions - requirements creation is really an iterative process when done right - and too many companies seem to think it is a single "deliverable" at the beginning of a project.

For an example, a top level user requirement might be "must be used in the sterile field of an OR." A system level requirement might be "must be sterile with an SAL of 10^-6." At some point, EtO is chosen as the method of sterilization. This leads to derived requirements not only that come from the ISO standard on EtO, but ALSO to requirements at the sub-system and component level that the materials must withstand heat and humidity levels found during EtO cycles. It obviously also leads to requirements for the packaging components related to EtO transmission, porosity etc. And, depending on the device, it could lead to design requirements relating to channel sizes etc.

All of these requirements should sit at some level of your heirarchy. Though it can all be at one level, generally that is very confusing to follow and trace, and can lead to misses in future product revisions and updates. At least that has been my experience.

Ginger

------------------------------
Ginger Glaser RAC
Vice-President, Engineering
Monteris Medical

Original Message:
Sent: 07-Aug-2017 19:49
From: Aimee Feuser
Subject: Terminology confusion: Design Input Requirements

Hi all,
 I was hoping someone could help me understand the relationship between the terms "Design Input Requirements" and "System (or Subsystem) Requirements Specifications."

My understanding is that User Needs and Intended Uses are first determined at the beginning of a development effort, and then these are translated into Design Input Requirements along with regulatory requirements, outputs of risk management, etc (per ISO 13485:2016 7.3.3). These Design Input Requirements, written to an engineering level of detail, can take the form of system-level requirements, such as System Requirements Specifications and/or subsystem-level requirements, such as Software Requirements Specifications, Hardware Requirements Specifications, Labeling Requirements, etc.

However, I was recently told that Design Input Requirements are typically different than System Requirement Specifications, that they are more general and high-level, and contain User Needs as a subsection. So the process would go User Needs -> DIR -> System Requirement Specifications.  Now I'm totally confused.

So I have two questions:
(1) How are Design Input Requirements related to System Requirement Specifications and Subsystem Requirement Specifications?
(2) How many layers of requirement specifications do you tend to use (i.e., do you have a single System Requirement Specification that contains all of the subsystem specifications as well, do you go straight to subsystem requirement specifications and skip the comprehensive document, or do you have a higher-level System Requirements Specification that is then broken down into more detailed Sub-system Requirement Specifications?).

Thanks in advance!
   Aimee

------------------------------
Aimee Feuser
Chicago IL
United States
------------------------------

Original Message------

Yes, it is confusing, mainly because every company uses terms like "specification," "user/customer requirements" etc differently. It did not help that the QSR goes partly to "Design for Six Sigma" concepts, but not all the way, and uses different terms for the same things "classical" DfSS includes.

That said, at a minimum I would generally expect that you have a high level, general, list of customer/user requirements, whatever you call it. Then there would be at least one detail level where that is broken down into engineering level of detail. If only having two levels, most people call this an "engineering specification" or something similar.

However, a best practice is really to include the number of levels that you need. At the top level, that might include customer needs, business requirements, a use risk analysis etc. The next level would be system level "detailed" requirements. These then get deconstructed into sub-system level requirements, which get deconstructed into the requirements for various components. There can be multiple levels of this.

Also design teams need to remember to add to the lower level requirements as they make design decisions - requirements creation is really an iterative process when done right - and too many companies seem to think it is a single "deliverable" at the beginning of a project.

For an example, a top level user requirement might be "must be used in the sterile field of an OR." A system level requirement might be "must be sterile with an SAL of 10^-6." At some point, EtO is chosen as the method of sterilization. This leads to derived requirements not only that come from the ISO standard on EtO, but ALSO to requirements at the sub-system and component level that the materials must withstand heat and humidity levels found during EtO cycles. It obviously also leads to requirements for the packaging components related to EtO transmission, porosity etc. And, depending on the device, it could lead to design requirements relating to channel sizes etc.

All of these requirements should sit at some level of your heirarchy. Though it can all be at one level, generally that is very confusing to follow and trace, and can lead to misses in future product revisions and updates. At least that has been my experience.

Ginger

------------------------------
Ginger Glaser RAC
Vice-President, Engineering
Monteris Medical
------------------------------

This is a great point. We use "risk management" as one of our buckets of "requirements." Others are Voice of Customer, Voice of Business, standards & regulations.......This tends to remind people they have to go do the risk management work and include it.

g-

------------------------------
Ginger Glaser RAC
Vice-President, Engineering
Monteris Medical
MN
------------------------------

Original Message:
Sent: 09-Aug-2017 08:31
From: Ginger Cantor
Subject: Terminology confusion: Design Input Requirements

Where I have seen this really get confusing as well, is the need to consider output of risk management activities as design inputs.  Too many companies don't do a risk assessment early enough, and forget it is or should be iterative during development.

I like IEC 62304 in this regard, where for software, you are supposed to formally assess and document risks of the proposed design and then classify its safety BEFORE you do anything. I think this makes it clear you are doing an early risk assessment, and that outputs of this are design inputs and may make you reconsider your product design.

Don't forget early risk assessment (PHA) for design inputs, whether the device contains or is software or not.

Ginger Cantor, MBA, RAC

Centaur Consulting LLC centaurconsultingllc@gmail.com

(715) -306-1850

Original Message------

Yes, it is confusing, mainly because every company uses terms like "specification," "user/customer requirements" etc differently. It did not help that the QSR goes partly to "Design for Six Sigma" concepts, but not all the way, and uses different terms for the same things "classical" DfSS includes.

That said, at a minimum I would generally expect that you have a high level, general, list of customer/user requirements, whatever you call it. Then there would be at least one detail level where that is broken down into engineering level of detail. If only having two levels, most people call this an "engineering specification" or something similar.

However, a best practice is really to include the number of levels that you need. At the top level, that might include customer needs, business requirements, a use risk analysis etc. The next level would be system level "detailed" requirements. These then get deconstructed into sub-system level requirements, which get deconstructed into the requirements for various components. There can be multiple levels of this.

Also design teams need to remember to add to the lower level requirements as they make design decisions - requirements creation is really an iterative process when done right - and too many companies seem to think it is a single "deliverable" at the beginning of a project.

For an example, a top level user requirement might be "must be used in the sterile field of an OR." A system level requirement might be "must be sterile with an SAL of 10^-6." At some point, EtO is chosen as the method of sterilization. This leads to derived requirements not only that come from the ISO standard on EtO, but ALSO to requirements at the sub-system and component level that the materials must withstand heat and humidity levels found during EtO cycles. It obviously also leads to requirements for the packaging components related to EtO transmission, porosity etc. And, depending on the device, it could lead to design requirements relating to channel sizes etc.

All of these requirements should sit at some level of your heirarchy. Though it can all be at one level, generally that is very confusing to follow and trace, and can lead to misses in future product revisions and updates. At least that has been my experience.

Ginger

------------------------------
Ginger Glaser RAC
Vice-President, Engineering
Monteris Medical
------------------------------

Spot on, Ginger C.  Having the design team, including Marketing and Clinical, conduct a Potential Hazard Analysis is a great way to help focus everyone on higher risk areas early in the design requirement input stage of product development.  This makes the process more efficient in the long run.

------------------------------
John Minier, RAC
Consultant, Principal
Minier Medical Device Consulting
john@johnminier.com
1(914)850-4432
Highland Mills, NY
United States
------------------------------

Original Message:
Sent: 11-Aug-2017 08:59
From: Ginger Glaser
Subject: Terminology confusion: Design Input Requirements

This is a great point. We use "risk management" as one of our buckets of "requirements." Others are Voice of Customer, Voice of Business, standards & regulations.......This tends to remind people they have to go do the risk management work and include it.

g-

------------------------------
Ginger Glaser RAC
Vice-President, Engineering
Monteris Medical
MN

Original Message:
Sent: 09-Aug-2017 08:31
From: Ginger Cantor
Subject: Terminology confusion: Design Input Requirements

Where I have seen this really get confusing as well, is the need to consider output of risk management activities as design inputs.  Too many companies don't do a risk assessment early enough, and forget it is or should be iterative during development.

I like IEC 62304 in this regard, where for software, you are supposed to formally assess and document risks of the proposed design and then classify its safety BEFORE you do anything. I think this makes it clear you are doing an early risk assessment, and that outputs of this are design inputs and may make you reconsider your product design.

Don't forget early risk assessment (PHA) for design inputs, whether the device contains or is software or not.

Ginger Cantor, MBA, RAC

Centaur Consulting LLC centaurconsultingllc@gmail.com

(715) -306-1850

Original Message------

Yes, it is confusing, mainly because every company uses terms like "specification," "user/customer requirements" etc differently. It did not help that the QSR goes partly to "Design for Six Sigma" concepts, but not all the way, and uses different terms for the same things "classical" DfSS includes.

That said, at a minimum I would generally expect that you have a high level, general, list of customer/user requirements, whatever you call it. Then there would be at least one detail level where that is broken down into engineering level of detail. If only having two levels, most people call this an "engineering specification" or something similar.

However, a best practice is really to include the number of levels that you need. At the top level, that might include customer needs, business requirements, a use risk analysis etc. The next level would be system level "detailed" requirements. These then get deconstructed into sub-system level requirements, which get deconstructed into the requirements for various components. There can be multiple levels of this.

Also design teams need to remember to add to the lower level requirements as they make design decisions - requirements creation is really an iterative process when done right - and too many companies seem to think it is a single "deliverable" at the beginning of a project.

For an example, a top level user requirement might be "must be used in the sterile field of an OR." A system level requirement might be "must be sterile with an SAL of 10^-6." At some point, EtO is chosen as the method of sterilization. This leads to derived requirements not only that come from the ISO standard on EtO, but ALSO to requirements at the sub-system and component level that the materials must withstand heat and humidity levels found during EtO cycles. It obviously also leads to requirements for the packaging components related to EtO transmission, porosity etc. And, depending on the device, it could lead to design requirements relating to channel sizes etc.

All of these requirements should sit at some level of your heirarchy. Though it can all be at one level, generally that is very confusing to follow and trace, and can lead to misses in future product revisions and updates. At least that has been my experience.

Ginger

------------------------------
Ginger Glaser RAC
Vice-President, Engineering
Monteris Medical
------------------------------

​​​Interesting discussion, in an area where my expertise is limited.

I usually try to avoid "grammar police" types of comments, but I must say that I avoid initial caps, as they tend to suggest "a particular thing" that is better defined and more set in stone than it actually is, and often leads to this type of confusion--people looking for hard definitions and rules where there are none.

I think design input requirements are simply those inputs that a company requires for its designs.  Some companies have a longer list of the inputs they require than others.  I have generally the same attitude towards all the other "Requirements" and "Specifications" cited here and elsewhere.  But maybe there is some ISO, IEEE or other standard that spells these out as "particular things," of which I am unaware.

I'm not aware of any regulatory requirements for specific inputs or specifications, which means I think these are matters for design engineers to work out, rather than regulatory professionals.  I probably would have posted the question to Elsmar Cove, rather than to this forum.

------------------------------
Julie Omohundro, ex-RAC (US, GS), still an MBA
Principal Consultant
Class Three, LLC
Durham, North Carolina, USA
919-544-3366 (T)
434-964-1614 (C)
julie@class3devices.com
------------------------------

Original Message:
Sent: 07-Aug-2017 19:49
From: Aimee Feuser
Subject: Terminology confusion: Design Input Requirements

Hi all,
 I was hoping someone could help me understand the relationship between the terms "Design Input Requirements" and "System (or Subsystem) Requirements Specifications."

My understanding is that User Needs and Intended Uses are first determined at the beginning of a development effort, and then these are translated into Design Input Requirements along with regulatory requirements, outputs of risk management, etc (per ISO 13485:2016 7.3.3). These Design Input Requirements, written to an engineering level of detail, can take the form of system-level requirements, such as System Requirements Specifications and/or subsystem-level requirements, such as Software Requirements Specifications, Hardware Requirements Specifications, Labeling Requirements, etc.

However, I was recently told that Design Input Requirements are typically different than System Requirement Specifications, that they are more general and high-level, and contain User Needs as a subsection. So the process would go User Needs -> DIR -> System Requirement Specifications.  Now I'm totally confused.

So I have two questions:
(1) How are Design Input Requirements related to System Requirement Specifications and Subsystem Requirement Specifications?
(2) How many layers of requirement specifications do you tend to use (i.e., do you have a single System Requirement Specification that contains all of the subsystem specifications as well, do you go straight to subsystem requirement specifications and skip the comprehensive document, or do you have a higher-level System Requirements Specification that is then broken down into more detailed Sub-system Requirement Specifications?).

Thanks in advance!
   Aimee

------------------------------
Aimee Feuser
Chicago IL
United States
------------------------------