User needs, intended use, etc

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!

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)

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!

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.

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!

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

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

hi guys, thanks a lot for your previous answers.
PLEASE be so kind to answer this too, since i seem to be losing myself (and my mind )

So, if my device is a SaMD (an .exe running on windows), i suppose "system" and "software" requirements are the same thing, so for now let's assume this is my workflow (not starting from the very beginning with user needs, obviously ):
1. state system requirements
2. the developers make an architectural solution, identifying Items and their interfaces, with the risk analysis etc
-> here is where i get lost:
a) was i supposed to state software requirements for each item's interface in software requirements that i should have derived from system requirements (so that would be step 2, and architecture would then be step 3), or
b) in parallel with making the architectural design, the developers write an interface requirements specification for Items (and then base integration tests on them) based on the system requirements (and risk analyses)?

much, much appreciated

p.s. what i've done is start with Product use requirements (from 82304, i guess that's what gets validated), and from there i derive System requirements

There's nothing prescriptive in the standards or guidance docs regarding your questions, as far as I know so I'll just relate my experience. We tend to push interface definitions down 'below' requirements; i.e., a specification type document. They get down to a lower level than you want to deal with from a requirements verification perspective (IMO). There's generally a high-level software / system requirement that identifies the interface, but the details are pushed into the spec. (I don't mean to downplay the spec - it's a critical document - it's the "contract" between the 2 sides and the only way to stay sane is to ensure that both sides comply with the contract!)

In terms of what constitutes integration tests, what you suggest is fine. We generally do lower-level testing on interfaces, confirming each side complies with the spec (low level since it often requires error injection and we strive to have our integration tests as automatic as possible).

Big picture, for SaMD, we generally have user needs, software / system requirements, and an interface control document (ICD).

What does the end-user expect from the device/SW/service to be satisfied? Those are your user needs. The engineers will address them and propose a solution to each need. These are design inputs. Once they are agreed upon, the item can be developed with those guidelines. For 510(k) submissions, your user needs better match the predicate device's user needs.