How to write design and development inputs to meet ISO 13485 requirements

Q&A's from the session

Do I need to verify or validate marketing or business needs? Or just “User Needs” or “Design Inputs”?

Clause Number 9 in the MDR talks about claims. So that means that you are not allowed to say something about your product, that you cannot objectively prove. If there are marketing or business requirements that you want to communicate externally. Yes, you need to have proof. However, a lot of marketing or business needs are internal. For example, your cost of goods sold, or a requirement to say that you need to use the branding colors of the corporation. Those things will never be communicated externally. Thus, they don't need to be verified or validated in any other way than what you have agreed upon internally in your company.

So basically, it depends. If it's a claim used externally, yes, you need to verify or validate them. If it's something you use only internally, you just validate it or verify it as you see fit.

How detailed should the DIR be? where to draw the line between requirements and specifications?

The basic principle is that you should have enough design input requirements to construct the system. This is something I would believe that comes with experience. One way that I address it is to say, “what desirable outputs and desirable inputs do we have?”, and “what undesirable inputs and undesirable outputs do we have?”. And try to check if you have things in all those categories, and make sure that there is now sufficient requirements to perform the design and development properly. 

Another way you can do it is to start at the other end and think of what tests do you want to do, or what verifications do you want to do on the product? That could also guide you a little bit. It can help you realize that if you have a test you want to perform but don’t have a requirement, you need one.

How do we make a precise requirement when we do not know the precise value at the beginning of the design (e.g. tensile strength of 28MPa)?

So let me tell you first what not to do. Don't write a requirement, think it's right and then fail the verification. And also don't write a requirement “TBD”, then do the verification and use the result in your requirement. 

The right way of doing that is to do what I refer to as engineering tests or exploratory tests before. Use your early prototypes to try to quantify the requirement, and when you have that, then replace the “TBD” in your requirement traceability matrix. And when you start the design verification, you have a proper value for that requirement. Then you basically repeat your engineering test, but with probably larger sample size and more formalized process. You can have “TBD” for a while, but then eventually, you're going to have to decide. And you should do that before you start your design verification.

What do you think about using flow charts for simplifying wordy requirements?

Sometimes when requirements become really advanced, it does make sense to use other types of means to communicate them which could be

various types of diagrams. There are flowcharts and diagrams and such that can explain it, and there's nothing preventing the use of them. 

One should just be careful so that you don't sketch up the solution, because still the inputs should be as abstract as possible.

Are there tools available to review requirements towards the desired characteristics of the requirements? 

There are at least 2 software products that I'm aware of, that will use software to gage and evaluate the requirements and provide feedback. It's usually a horrible experience in the sense that you realize how bad your requirements are. But if you want to improve, it's great. They are not perfect, you certainly need a little bit of human touch as well, but they can take it far, for sure.

In a medical device that involves a hardware, firmware and an interface application (smartphone app), how would the requirements be specified?

This comes back a little bit to requirements, engineering skill, because there are different situations. Let’s say that you're making an app with a color screen and everything. When you give that to those that are going to make a sketch of what this user interface is going to be like, you want the requirements to be as abstract as possible. So that you don't restrict people in the design, but you achieve a design that is as efficient as possible. In this case you want them to be abstract and maybe slightly more high level. 

Now let's say that you did all the wireframes, and you drew this up, and you know exactly how you want it to work, and then you're going to outsource the implementation of those requirements to a third party. Well, then they are going to be less abstract, and you are going to be much more like “there shall be a button there”, which is much more of a design solution. Which is generally frowned upon, but in that setting it makes sense, because you know what you want, and you're going to give it away to someone, so they should just implement the code.

This is a question with many different types of answers depending on the context and situation. But the basic underlying principle is that you should have sufficient amount of requirements to ensure that the product that comes out, meets the stakeholder needs or expectations.

I've always understood that user needs are the beginning of the process and based on the user needs, we are preparing design input, and all requirements should start from user need. Am I understanding it wrong?

It's quite right. But I would say that the starting point is the intended purpose.

With that addition, I believe this is completely correct. 

Intended purpose would answer, “who is going to be using the device?” “For what?”, “when?”, and “where?”, which is really the input to the user needs. So one more step needs to be added, but other than that, the user needs should be transformed into design input requirements. So, you go from user needs to design input requirements.

If I understand it correctly, you advice that we shouldn't include risk controls in the requirement traceability matrix, but only in the hazard traceability matrix. Is that correct? This makes sense to prevent duplication of information. I assume, then, that the relevant procedures should mention that design inputs are recorded in multiple places and list them, e.g. both the RTM. As well as the HTM. 

Firstly, I never want to have duplicate information. I always try to steer clear of that. And the thing is, a lot of manufacturers are putting in the risk controls in the requirement traceability matrix because the ISO 13485 says that risk management outputs shall be part of your design and development inputs. That is not to be taken literally. It doesn't mean that you have to write your risk controls among your design input requirements. It means that they are an input, to the development effort, which they should always be. 

We don't want to have the R&D engineers think “we don't look at the risks”. We want it to be an integral part. If you say in your procedure “we consider the risk control measures to be part of the design and development inputs, and the engineers shall take that into account”, you have satisfied that required.

And I could argue that you should do both ways. Because I appreciate the fact that you, gather all the requirements that apply to the product for the engineers to read in one place. That's the argument for having them together. But I could also argue that you shouldn't do that because some of the risk controls are not going to apply to the device. They will apply, for example, to the production process or to the training or the in service… and that means that they are not requirements on the device. And they should therefore not be in the requirement traceability, matrix. 

In this case you start having different categories again, like they should be treated the same, but they go into different places, and that creates a system that is challenging to follow or understand. So you could argue both ways, and one just needs to find a way where you meet all the requirements where it works practically for you. I can appreciate both models.

What would be the most important requirements engineering characteristics that are relevant especially for medical devices?

Whenever I write a user need or a design input requirement, I always write a short text in the design verification and design validation columns. And if I have a hard time writing a sentence or 2 about how I'm going to go about that verification of validation, then most likely there is something wrong with my user need or design input requirement in terms of being able to be verified or validated.

If you're worried about auditors, make sure acceptance criteria are there always. That's the highest risk of getting a nonconformity. 

How do you make sure that a set of requirements is complete? 

With experience, good systems engineers and looking at all the inputs and outputs and making sure that you've covered them. Careful reviews are also important regarding this topic.

Are clinical functionality requirements in a product requirement list fine, or should they be labeled as user needs? (e.g. covering medical indications)

I would tend to say that they should be user needs, unless you have a really good explanation of what it means and communicate that successfully in the organization. Because if you turn to standards or the MDR, I do not believe you will find that clinical functionality term. It needs to be properly defined if you're going to use it, but I, personally, would not introduce it. I would stick to “user needs”, or may be sometimes used to term “claims” as that one is in the MDR.

How to validate user needs before the product goes to market or before submitting it to certification?

You need to do it before submission, obviously. And usually you would use the product in the simulated environment. But keep in mind that the second you include patients, then it's no longer only design validation, then it becomes a clinical investigation with everything that comes with it. So be careful there when you cross the line from “regular design validation” to “clinical investigation”. Clinical investigation is, you could say, a subset of design validation actually.

What's the difference between verification and validation?

Verification is to show that the design output, meaning the medical device you created, meets the design input. You are showing that a specific requirement

is met with the design output. 

The design validation is about showing that the user needs have been met. They say, “Design Validation is to answer the question: did we develop the right product?

 Design Verification is to answer the question; did we develop the product right?”. But I think it's easier to say: 

• Design verification is about showing that we met the technical requirements.
• Design validation is to put it in the real environment, making sure it works also in a real setting.

Is a "Design Output" a "Development Input"?

Sometimes a design output becomes a design input. For example, the system level design inputs will lead to a system design, which is a design output, which in turn is a design input on the sub-system level.

How can I integrate compatibility between different components versions and variants of the product, aka product line engineering, into the design input requirements?

I would work with some kind of matrix to document which versions must function with what. And then use the matrix as an input to design verification and design validation.

How do you define adequate in the design input?

I typically don't define it. This word is not used in requirements engineering in general, but is the "cover it all" word in ISO 13485.

I understood that User Needs start whole process and they are the beginning of the whole story. Based on them design input requirements are prepared. The baskets idea shows that they are parallel to the des. inputs. Am i understanding it properly?

Intended use/purpose is the starting point, then user needs are defined based on the intended use/purpose and then the user needs are transformed into design input requirements. When I showed the buckets, it was not supposed to imply that there are no relationships between the categories; the metaphor is used to recognise different categories of requirement and try to make sure they end up in the right process, regardless of sequence.

How/to which extend is the Design Input verification activity different from Risk Measure proof of effectiveness and implementation?

Design input verification answers if the design output meets the design input requirements. Verification of effectiveness of risk controls should adress whether the risk has been reduced according to the risk estimates. And the verification of implementation should answer if the risk control measure has been implemented. These are somewhat different things.

Is there any guide to differentiate between stakeholder ,user needs and product requirement

There are clear definitions of the difference between stakeholder needs, user needs and product requirements in the INCOSE guidelines.

If you’re intended user is not defined, how would you recommend to build design inputs and design outputs at preliminary stages? After this, at what stage of the process would you recommend as a cut off stage for introducing a defined User into the requirements document?

I would make a guess what the user would be, and then change the user and downstreams information if we learn that the user is different. It will be really difficult to write user needs and a lot of other things if you hvaen't defined the intended user.

Should Software requirements be documented in an own Traceability Matrix or together with the Hardware requirements in one traceability matrix? (Medical device with SW and HW)

This depends on so many different things, for example, how many requirements you have? Do you use a database? Are the same teams/people accessing the requirements at the same time? And so on. I cannot give a recommendation without knowing a lot more than what can be conveyed in this channel.

Following up on the hardware, firmware and app based medical device, can the DIR be maintained separately? If so, there might be some confusing testing/verification process

You can do this anyway you like as long as you meet the requirements from the standards and regulations. So can you have them separate? It is practical? Maybe. It is up to you.

Is a rationale about sample size of verification activities for the Design inouts always mandatory?

Statistical methods should be used where appropriate. So if you don't use statistical methods, you should justify it.

Should all design inputs come from User Needs? For example, requirements from GSPR, in my opinion the don't come from user needs.

Not all design input requirements should come from user needs, some will, for example, come from standards. But all design input requirements should have a source or a parent. Regarding the GSPR, I would not refer to them as design input requirements as they are high level and broad. And to connect the previous sentence, GSPRs are often fulfilled by implementing the more detailed design input requirements from standards. GSPR withou more details, represent an odd type of requirements that are part of design and development inputs, but they do not qualify as design input requirements (with some few exceptions).

Can product requirements and user needs exist in one overall product requirements list?

I think this comes back to what you mean by product requirements. But I typically document user needs and design input requirements in one requirement traceability matrix. There is nothing preventing that.

Could you give some notes on difference of "intended use"/ intended purpose" / "indication for use"? 

"Intended use" is mostly used in a US context. "Intended purpose" is more common in the MDR/IVDR, but also they use the term "intended use". I would use "intended use" and "intended purpose" interchangeably. Indications for use is more focused on the medical purpose of the medical device. There are a lot of different views on this topic, and even an FDA guidance document on the differences I think.

Can validation ensure that there are no unconsidered risks?

No, but it helps. If you identify things that go wrong in the design validation, those observations should be used to update the risk management file.