Project Name: XXXX
Scope
This document defines the foundation of the design and development of [Device Name], with a particular focus on the User Needs—also referred to as User Requirements (UR) that establish the project’s user-related criteria, specifications, and constraints.
Project description
Project identification
Include the DHF number
Device Description
Provide the current description of the product with pictures if relevant. Outline any constraints applicable to the product or in production.
Proposed intended use
Describe a proposed indication for use, provide the intended users, intended patients, etc.
Markets of interest
Describe the primary markets of interest to determine the applicable regulatory constraints of the projects.
Project framework
Describe the technical context of the project with reference to a specification agreement if applicable, tests performed, prototype selected, etc.
Project timeline
Provide an estimated schedule from design to release on the market
User requirements
This section outlines the user requirements that serve as the foundation for the design and development of the medical device.
User requirements refer to the expectations and needs expressed by the intended users—whether patients, healthcare professionals, or laypersons—in terms of performance, safety, usability, functionality, and overall benefit of the device.
The objective of this section is to identify, categorize, and document those requirements in a clear and traceable manner to ensure that the final product adequately addresses the intended use, user profile, and operating environment. These user needs also form the basis for subsequent design input, risk management activities, and ultimately, for the verification and validation of the device.
The following subsections provide the different types of user requirements that may apply to the device, grouped by relevant domains.
These categories are provided for information and must be reviewed and customized to fit the specific context, use environment, and risk profile of the product under development.
Applicable legal framework
relate to the applicable regulations for which compliance with device-specific requirements need to be demonstrated (e.g., MDR GSPR requirements)
User training and competency
relate to the level of knowledge, skills, and training needed to use the device safely and effectively. Users may need clear IFU, access to training programs or intuitive workflows. Devices intended for laypersons or minimally trained personnel may require simplified interfaces or decision-support features.
Functions
relate to the core purpose and performance expectations of the device (e.g., precision, response time, range of measurement, operating modes).
Labeling & Packaging
Relate to the regulatory and standards requirements applicable to the labels, IFU, leaflet, packaging, shipping containers, etc.
Software & Cybersecurity
relate to software interface, software performance, protection from data breaches, secure login, software updates, system compatibility, backup functionalities, etc.
Usability
relate to ergonomic design, intuitive interfaces, feedback signals (visual, tactile, auditory), and ease of use.
Biocompatibility
relate to compatibility with human tissue and duration of use to avoid adverse reaction
Environmental and infrastructure constraints
relate to environmental conditions of use (e.g., temperature, humidity, magnetic field, portability), production constraints (e.g., cleaning, sterilization, etc.)
Installation and maintenance
relate to constraints to facilitate the process of installation or maintenance
Safety
relate to protection from foreseeable safety events such as misuse, electrical hazards, mechanical failures, unintentional exposure, etc. or safety standards (e.g., electrical safety)
Claims & clinical benefits
relate to the performance or clinical benefits claimed by the manufacturer.
XXX Describe additional topics as necessary
Summary of user requirements
The following table provides a structured summary of the user requirements identified for this project. Each requirement is described in measurable terms, associated with a clear acceptance criterion, and linked to its rationale or source. The selected validation method ensures that each requirement can be objectively verified during the design validation phase. This table supports traceability throughout the design control process and is intended to be used as a foundational reference for further design and development activities.
Based on the descriptions provided above, the specific user needs relevant to this project must be clearly defined in the table below.
This table must be completed with the understanding that the description of each user requirement will directly guide its validation. Therefore, the wording must be precise and unambiguous to ensure the requirement can be effectively validated.
|
#UR
|
Description
|
Acceptance Criteria
|
Source of AC
|
Design Validation Method
|
|
|
Needs to be measurable (e.g. <X, within X-Y) and based on state of the art/standards/user survey, etc.
|
Include the traceability how the acceptance criteria has been defined
|
Include the validation method that is planned to be applied.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This table will serve as the foundation for establishing the traceability matrix for the design and development of [Device Name].
Market analysis
This section is optional and is used to document the rationale for selecting the target markets and present the competitors. The information is derived from the business plan.
Design & Industrialization methods
This section is optional and is intended to document the industrialization methods that have been selected and/or evaluated. It may also identify the party responsible for the product design of the device under development.
This section further describes the potential industrial partners, the design developer, and key suppliers.
Regulatory Context
Based on the target markets, this section draws on the corresponding regulatory strategies (see FORM-RR-020) to describe the regulatory context and constraints applicable to each market.
Approval
Upon approval, I confirm that the project may be initiated and that the customer requirements review has concluded the requirements are objective, unambiguous, and free of conflicting requirements.
|
Project Approval for Initiation Yes No
Reason if no:
|
|
Name
|
|
|
Position
|
|
|
Date
|
|
|
Signature
|
|
|
Project Approval for Initiation Yes No
Reason if no:
|
|
Name
|
|
|
Position
|
|
|
Date
|
|
|
Signature
|
|
|
Project Approval for Initiation Yes No
Reason if no:
|
|
Name
|
|
|
Position
|
|
|
Date
|
|
|
Signature
|
|
|
Project Approval for Initiation Yes No
Reason if no:
|
|
Name
|
|
|
Position
|
|
|
Date
|
|
|
Signature
|
|
History
|
Revision
|
Date
|
Change History
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
