Design inputs for legacy devices

[DEA222410]

Hi,
looking for some advice on design inputs for legacy devices. We are currently trying to put together design input documentation. For some of the product features (Outputs), we dont know what the original design input would be - often we know the function it serves, but not the detail of the design requirement and no verification data to support. However, in some cases, these features are important to the function of the device, so the output is stated as the input - e.g the device must have a port. To me the original design input would have been something around what that port does or how it performs and then verification to show it meets these requirements. But having the output as the input, the verification would just be that the device does actually have a port.

Does anyone have any ideas on how to overcome this problem and assure that all the important features of the design are included in the design inputs?

Hope that makes sense.

 

[Jane Austen]

The topic at hand is generally ‘requirements engineering‘.
You can have several levels of requirements based on the complexity of the device and its users (for example stakeholder requirements, product requirements, and component requirements. There can be more even).

The requirements are defined by customer needs from the higher to the lower levels. And these requirements are essentially the Design Inputs. Later on an output is defined per input with a verification method to ensure it was implemented in the design.

What you are describing is trying to do ‘reverse requirements engineering’ - you know the design output but not the input.

You mentioned:

the output is stated as the input - e.g the device must have a port. To me the original design input would have been something around what that port does or how it performs

You have a documented output of “device has a port” - I would now ask in order to figure out what would have been the input: “WHY do we need a port in the device?” / “why does the user need a port?”.
This is where you start in my opinion because if you can’t answer this question, maybe there shouldn’t be a port.
Your questions of “what the port does and how it performs” can be questions for very detailed lower level requirements definitions (on the component level). But when you want to track back the original input I would start with the WHY. The answer might be because the port gives a functionality for user to do x, or because the port allows for this function/component to operate giving the user y. Always think how does it help the user (and you might need to go a few levels with this question: let’s say I were to do the same exercise you are doing for a cable in the device -> why does the user need a flexible cable? -> the user doesn’t care about the cable, the cable is flexible to allow the cart it is supplying energy with to be moved easily in an operating room. -> why does the cart need to move freely? -> because the USER wants to be able to position the cart around the patient in the operating room and thus needs to move it a bit. And the input is -> device must be portable in the room for a 2/3 meter area. Just as an example).

Also something that might help, if you are stuck in your reverse design input you can always ask yourself: “what would happen if I will remove this design output now? Who will scream and shout? What will not work?”.
The answer will lead you to your design input. And if the answer is “nothing would happen and no one would notice or get upset and the intended purpose of the device is still met” then I would reconsider if this output should really be part of the product, it might be redundant now (could be it served a purpose in the past and might have gotten obsolete over time with design changes or product versions).

Hope this helps!

 

[Billy Milly]

Since you are mentioning legacy devices, I assume the topic is the transition from MDD to MDR. The pragmatic approach for this scenario is to use the MDD file as a design input - "I want to develop a device just like this one". I agree there could be scenarios where this approach is not very useful, but you provided very little info on the device (class, active or not...), so this advice is very general as well.

HTH

 

[ChrisM]

Hi,
looking for some advice on design inputs for legacy devices.

Why? Because someone has asked for them or because it has been discovered in, for example, an audit as a nonconformance that there are no recorded design inputs. There must have been design inputs, otherwise how was the design transformed into a product. Start by looking at the Declaration of Design and Performance or equivalent - a Brief that sets out what the product is intended to do, from this you should be able to work out the functionality and then work out what inputs will be required to achieve them.

 

[Tidge]

Does anyone have any ideas on how to overcome this problem and assure that all the important features of the design are included in the design inputs?

Critical thinking on the part of invested stakeholders.

For legacy devices that don't have (ehem) 'engaged' engineers, the best resource for understanding what the requirements were is probably sales & marketing.

 

[Ed Panek]

Yes. Look at what sales said about the device in literature. Speed? Ease of use? Safety?