Use requirements (also called user requirements; German: Nutzungsanforderungen) describe the properties, functions, information, and interactions that a medical device must fulfill from the perspective of the intended users so that the intended use goals can be reached safely and effectively; depending on the development goal, efficiency, comprehensibility, or ease of use can additionally be taken into account.
They are derived from findings about user groups, contexts of use, workflows, use-related risks, and tasks, and serve as a traceable basis for developing the user interface. They are clearly to be distinguished from technical system requirements.
Derivation from the context of use
Use requirements do not arise in isolation. They are derived, among other sources, from the use specification, from user needs, task analyses, use-related risk analyses, and from findings from evaluations and post-market surveillance. Particularly relevant are user profiles, use scenarios, use environments, and the tasks performed with the medical device. The quality of the use requirements depends directly on the quality of the preceding context analysis. Incomplete user groups or use situations that were not considered often lead to gaps in the requirements.
Delimitation from design and system requirements
Use requirements describe the "what," not the "how." A requirement such as "The user interface must enable users of the intended user profile to correctly determine the current operating state under the specified conditions of use" is a use requirement. The later implementation through colors, symbols, or text displays, by contrast, belongs in the design or system requirements. In practice, these levels are often mixed, which makes traceability and verification harder.
| Use requirements | Design and system requirements | |
|---|---|---|
| Level | The "what" | The "how" |
| Example | "The user interface must enable users of the intended user profile to correctly determine the current operating state under the specified conditions of use" | The later implementation through colors, symbols, or text displays |
Relationship to the use-related risk analysis
In the regulatory environment for medical devices, many use requirements arise directly from identified use-related risks. If, for example, it is recognized that a dose setting is error-prone, requirements for error prevention, plausibility checks, or user feedback can be derived. Use requirements thus often act as the interface between risk management (ISO 14971) and usability engineering (IEC 62366-1).
Methods for determining use requirements
Typical methods are context analyses, contextual inquiry, field observations, interviews, workshops with stakeholders, task analysis, cognitive walkthroughs, and the analysis of complaint data or post-market surveillance findings. In human factors engineering, requirements are also often made concrete by means of use scenarios or use cases. For complex medical devices, work domain analysis or hierarchical task analysis is used in addition.
Verification and validation
Use requirements must be formulated so that they can be verified. Formative evaluations serve to investigate early on whether design solutions actually support the requirements. The summative evaluation then checks whether users can interact with the product safely and effectively under realistic conditions. Use requirements that cannot be verified or are ambiguous often lead to problems in reviewing the design inputs and in the later validation.
Typical weaknesses in practice
A frequent mistake is to document only feature requests without establishing their relationship to user tasks or risks. Requirements such as "Operation should be intuitive" are also problematic, because they can hardly be verified objectively. Requirements for exceptional cases, rare use scenarios, or users with limited abilities are also often missing. These gaps often become visible only during formative or summative studies.
Regulatory reference
In the process step "Prepare Use Specification," IEC 62366-1 requires the systematic description of the intended purpose (intended use), users, contexts of use, and use-related characteristics as the basis for further usability engineering activities. Use requirements are typically derived from this information. The usability engineering process additionally requires the identification of safety-relevant characteristics of the user interface, potential use errors, and use scenarios associated with risk, from which requirements for the design and use of the product result. According to ISO 14971, risks that can arise from use or misuse must be identified and controlled. Use requirements can specify the required effect or design of a use-related risk control measure; the actual risk reduction, however, arises only through its effective implementation and verification. In its human factors guidance, the FDA expects user needs, contexts of use, and critical tasks to be analyzed systematically and translated into design inputs.
Use requirements describe the "what," not the "how," and must be formulated so that they can be verified, otherwise they cannot be verified at all. "Intuitively operable" is not a use requirement. A better formulation names the intended users, the specific task, the relevant conditions of use, and the expected result. A blanket maximum error rate is usually not a suitable acceptance criterion, especially for safety-critical tasks.
Frequently asked questions (FAQ)
Are use requirements the same as user needs?
No. User needs often describe the needs or goals of users at a higher level of abstraction. Use requirements are more concrete requirements for the use of the product that are derived from them and, where possible, verifiable.
Do use requirements have to be safety-relevant?
No. Many use requirements concern efficiency, comprehensibility, or ease of use. In the regulatory context, however, the focus is on requirements that relate to safe use.
Where are use requirements documented?
Depending on the development process, use requirements can be maintained in a requirements management system, in design input documents, or in other specifications. Insofar as they represent results or evidence of the usability engineering process, they can be part of the usability engineering file or be referenced from it.
Can use requirements be tested directly?
Use requirements that are formulated so that they can be verified can be evaluated directly. Abstract user needs or general statements of intent must first be translated into concrete requirements and suitable test criteria.
Do you want to derive use requirements from context analysis and risk assessment cleanly and in a verifiable way? We support you throughout the usability engineering process according to IEC 62366-1.
More about our usability engineeringSources
- IEC 62366-1:2015+AMD1:2020, Medical devices, Part 1: Application of usability engineering to medical devices
- ISO 14971:2019, Medical devices, Application of risk management to medical devices