Requirements & Requirements Management

Complying with FDA Design Control Requirements Using Requirements Management Principles

By |

Requirements Management

Complying with FDA Design Control Requirements Using Requirements Management Principles

Mercedes Massana: So agenda for today is we’re going to talk a little bit about the design controls and what they are. We’re going to talk about requirements management and what that is. And then we’re going to talk about how the two relate to each other. Then we’ll discuss how we can build a good requirements management process and how that process can help us improve compliance to design controls.

Okay. So let’s get started. All right. So by the end of this presentation, hopefully you’ll have a good general working knowledge of design controls. You’re going to understand requirements management and how to evaluate and accept requirements, how to perform bi-directional traceability, how to use requirements attributes to help manage the requirements, and how requirements metrics can help you make better decisions. We’re going to learn how to manage and control requirements changes, and then how to use attributes, especially a requirements credit quality attribute to help us on manage and identify essential requirements and requirements that are critical to quality.

FDA Design Controls

Mercedes Massana: So let’s start with design control background. So design controls have been part of the FDA QSR since 1997. So it’s been a long time. The FDA initially implemented design controls to try to help medical device manufacturers identify deficiencies with design input requirements, to identify discrepancies between proposed designs and requirements, and increase the likelihood that the design transferred to production is going to translate into a device that is appropriate for the intended use and satisfies the user needs. And they did this in relation to having a lot of issues in the field with medical devices. So they thought design controls would improve the quality of the medical devices that were being approved.

In the FDA design control guidance, they state that developing a solid foundation of requirements is the single most important design control activities. So that kind of tells you how important FDA thinks design control requirements management is. So design controls is made up of several elements. There is design and development planning, design inputs, design outputs, design review, design verification, design validation, design transfer, design changes, and design history file.

RELATED POST: Ensuring FDA Compliance for Your Digital Health Solution

Mercedes Massana: Now, most of those, even though requirements really falls under design inputs, and that’s what everybody understands by design inputs, most of these items relate to requirements in one way or another. So design outputs, we have to develop design outputs that will conform to design inputs. For design reviews, we’re going to review our design inputs to make sure that they’re appropriate and not conflicting or unambiguous. Design verification will confirm that design outputs meet the design input requirements. And design validation will confirm that the user needs and intended uses are met, which is their another form of design input.

And then design changes, obviously managing requirements changes is important. And obviously all our design inputs or all of our user needs documents or system requirements or product requirements documents will end up in the design history file. And then obviously our deliverables that user needs that we create, or system requirements, product requirements, all become part of our design history file.

Requirements Management

Mercedes Massana: So let’s talk about requirements management. So what is requirements? Why do we need requirements management? Why would we want to do this? Well, if your projects are late because you’re trying to introduce changes at the end, or if sometimes your developers can really figure out what the requirements may mean and they’re making their own interpretation, those are all issues that can be addressed through requirements management. In fact, it is said that approximately for IT projects, which encompass software obviously, that at least 50% of projects are late, or delivered with reduced functionality or over budget.

RELATED POST: The Essential Guide to Requirements Management

Mercedes Massana: If you have a good requirements management process, this will improve those statistics and make projects more successful. So what is a requirement? So for IEEE, a requirement is a property that a product must have to provide value to a stakeholder. That’s the IEEE definition. The FDA definition is a condition or capability needed by a user to solve a problem or achieve an objective. So couple of key items here is, something that is needed by somebody, right? So that tells you that anything that goes into your requirements has to have a purpose. Why is it there? And it’s needed to solve a problem. So it has to solve a problem for the user, right? So if it’s something that a software developer thinks is a cool feature, but nobody needs it, then it really shouldn’t be a requirement.

So requirements management process has four main goals. It tries to ensure that there is an understanding of requirements, but all the stakeholders, that they commit to those requirements or approve or agree that those are the requirements that need to be implemented. That we manage requirements changes. And we’ll talk what managing requirements changes means a little later. And then we identify inconsistencies between project work and requirements. And what that means is that you can’t have a project plan that says you’re going to be done in a year if you have 10,000 requirements to implement, right? So you have to have consistency between the requirements and the other deliverables of the project.

So to obtain an understanding of the requirements, first, we need to know who are we solving the problem for? Right? So we need to determine how we identify the stakeholders. So who are those requirements providers, right? Those are the stakeholders. We need to know how we’re going to evaluate the requirements, how we’re going to know if the requirements are good and complete. And then we need to know who needs to approve the requirements and when do requirements get approved. So that’s how we obtain an understanding of requirements.

Then a commitment to requirements is basically that agreement between the different stakeholders that says, if you develop these set of requirements, we’re going to have satisfied customers, that our agreement is usually made through approval of the requirements.

Managing requirements changes is, obviously the one constant in life is change. So requirements will also change. But it’s very important to manage changes so that the rest of the product reflects the impact of those changes, right? Nothing comes for free, and requirements changes usually are either going to cost more, and we’re going to have to add more resources or we’re going to have to add more scheduled, but something will have to be done in order to manage the impact of that change.

Requirements Traceability

Mercedes Massana: And then maintaining bidirectional traceability. This requires that requirements be traced forward from higher level requirements to lower level requirements and that every lower level requirement be able to be traced backwards to its parent or a higher level requirement. Additionally, other elements like design, tests and risks should also be included in our traceability. And later on, I’ll show you a fully elaborated trace matrix that shows the relationship between pretty much every deliverable that we’ll create as part of our development process.

All right. So what’s the connection between requirements management and design controls? So this table will show us a little bit of that. So these requirements management elements relate to design controls as follows. So design inputs are defined as the physical and performance requirements of the device that are used as the basis for device design. So the FDA tells us that design inputs must be appropriate. That we need to address incomplete, ambiguous or conflicting requirements. And that these requirements related to design inputs are addressed by the requirements management element and obtaining an understanding of requirements.

Design outputs are defined as the results of the design effort at each design phase and at the end of the total design effort. The FDA says that design controls must be able to evaluate the design outputs conformed to design inputs, that we must be able to establish acceptance criteria so that we can verify the design outputs conform to the design inputs. And then we identify the essential requirements or essential to proper function requirements. So again, requirements management can help us meet this part of the regulation.

FDA design controls also state that we must identify document, verify, validate and approve design changes before implementation. Additionally, the design control guidance specifies that the trace matrix is a form of verification. So both of these areas are also covered by requirements management. And here, we can see that there is definitely a relationship between FDA design controls and any requirements management process.

 

To learn more, watch the full webinar, “Complying with FDA Design Control Requirements Using RM Principles”


Jama Software
Latest posts by Jama Software (see all)