User needs, intended use, etc

[smtka]

hi, hello, i am new to regulatory compliance business and i desperately need your help

I've been tasked with setting up a ISO 13485/ 62304/14971 compliant SDLC for a small software company that has been in business for decades, but somehow they managed to wing their audits without really having compliant processes in place.

My question (to start, one of many) is: what exactly is a user need?
i went through IEC 82304 but still don't really get it; what's the correlation to intended use, context of use, product use requirements, user requirements, etc?

My best guess is that an intended user is performing some task in some context of use and he has a goal, and in order to perform this task, he has some needs that need to be fulfilled. These tasks are broken down into use scenarios that are then used for risk analysis, and the needs are broken down into user requirements (which are more granular and specific), and then later translated into product use and then system and then software requirements.

please tell me if i am on the right track, i know my question is pretty basic and dumb, but eh
i'd also be really happy if i got this answer as soon as possible, since, ofcourse, we're on an MDR audit deadline
thanks a lot in advance!

 

[Ed Panek]

User requirements are implicit and explicit requirements for (In your case SaMD) to meet its intended use. Some are things the user is aware of (how to view data, navigate menus and usability, how alerts work, configuring the software) Some are more difficult (Cybersecurity, data privacy, Hippa)

 

[smtka]

yes, thanks, so are you making a distinction between user needs and requirements in your explanation or not?
i understand user requirements can be functional and non-f (i.e. quality), but i am not sure i understand what a user _need_ exactly is

thanks a lot for your reply, btw!

 

[EmiliaBedelia]

User needs are usually a little bit more high-level than requirements, and they are needs from the user's side (not from the device side). At least in my experience, a user need is basically the first step in the process and usually, it comes from marketing. For example, "User needs to be able to access custom settings. User needs to view vital information. User needs information to be accurate for clinical use". The system requirements are decomposed from those needs into the things that the device needs to do - eg, "Software will include a login. Software will save user settings. Software will not allow access to information without logging in." (highly simple but that's the idea).

Note that all these standards do not necessarily align in terminology, and they are not "linear" - so you might not have a clear "starting point". But the more you can keep things relatively harmonized across all the different documents/processes, the better.

 

[yodon]

To piggy-back a little on the excellent post from @EmiliaBedelia, consider the 'V' model. User needs are what get validated. User needs are translated into "engineering's answers" (system requirements) to those needs. You need to maintain linkage (traceability) between the user needs and system requirements. If it's just a software-only product, you may replace system requirements with software; otherwise, software requirements are then derived from the system requirements (and you need to maintain linkage - traceability - between the system requirements and software requirements).

I generally like to frame user needs in terms of "The user needs the system to..." That helps keep the focus off of design.

To further muddy the waters, you should be implementing a risk management process (compliant with 14971) and risk controls need to factor into your requirements tree. We generally derive system (or software) requirements from risk controls.

You should also look into IEC 62366 (Usability Engineering). That helps define who all the stakeholders are and there may well be some user need level requirements based on the different stakeholders!

 

[QuinnM]

Hi Smtka,

User Needs is part of design controls. Each company may structure these controls a little different. In general for a medical device there would be some type of concept, business case, for a medical device. The information from the concept helps to develop the user needs document (which is a high level document). This is the starting point for design documentation: concept, then user Needs.

Quinn

 

[Miner]

This is a good explanation of user needs by the government of Australia.