Understanding User Requirements for IVD Device Development

Speak With One Of Our Experts

Successful IVD product development results in easy-to-use products that perform important user
functions. Start your IVD device development with a deep understanding of your end-user’s
requirements.

What are “User Requirements”?

User requirements for IVD devices are derived from the needs, intentions, and actions of the
users of the device. The key users of IVD devices include the operators and handlers of the
device or materials. Depending on the situation, these users may include lab workers, healthcare
providers, and even laypersons. However, those that receive the IVD results and act on behalf of
the patient—such as physicians, nurses, and ambulance workers—can also be considered users.

Understanding the requirements of each of your device’s users is the first step towards
developing system requirements. When formulating individual user requirements, it is essential
to identify the relevant user groups, tasks, conditions, and goals within the scope of the user.

IVD device-related user requirements should outline the user/system interaction parameters and
the use-related quality requirements for any task outcomes.

The FDA specifies user and system requirements as the design inputs to a medical device;
however, this requires the definition of an appropriate “intended use” by which feasible
requirements can be formulated. The FDA also specifies guidelines for intended use. Following
these definitions, system specifications can begin to be outlined and design outputs can be
considered. Therefore, it is paramount to not only define user requirements, but also the intended
use of the IVD device.

FDA Intended Use

For clinical diagnostics, the identification of user requirements relies on defining what the FDA
calls the product’s intended use: what you tell your customers the product can and cannot do, and
who it should be used for. Intended use is sometimes referred to as the “product label” or the
“product claims.”

You’ll also need to specify the indications for use, which refers to the disease or condition the
product is used for, including the type of patient. A careful analysis of what exactly your product
is used for and what the clinical question is to be addressed will help you write an intended use
statement that accurately reflects the clinical scenario and risk level.

TL;DR: the FDA’s intended use and indications of use for medical devices outline the device’s
general and specific purpose. This regulatory framework helps bring the device’s user
requirements into focus.

Types of User Requirements: Technical, Business, and Regulatory

Let’s talk about how to generate a detailed outline of user requirements for your IVD device
development project. It begins by understanding the three types of requirements: technical,
business, and regulatory.

Technical requirements are the basic needs associated with the product’s use. Does it accomplish
the primary task for which it was invented? Does it do so with appropriate performance
characteristics, (e.g., specificity, sensitivity, time to result, clarity of result)? Does it fit in the lab
space or clinic where it will be used? Does the operator’s education and experience level ensure
proper operation of the product?

Business requirements are the practical and managerial considerations customers will need to
consider when evaluating your product, particularly those with economic consequences. For your
IVD device to be adopted and have the opportunity to improve user experience compared with
the test(s) it will replace, it needs to be clear to the customer that switching to it will make
economic sense and will improve organizational efficiency. Changing the status quo is difficult
for most organizations, and more so in the healthcare industry where updating and documenting
alterations to clinical routines can represent a daunting obstacle.

Regulatory requirements are the product’s characteristics, development, and production methods,
and the company or site certifications needed to make a product that’s consistent with all legal,
regulatory, and industrial standards. The FDA’s “design control” framework for development,
ISO 9001 standards, and CLIA certification are all examples that fall into the category of
“regulatory” requirements a customer will expect you to achieve. Regulatory requirements are
important to consider as part of your IVD device development project.

The FDA provides a benefit-risk analysis for all stakeholders associated with medical devices,
which sheds light on technical, business, and regulatory considerations for manufacturers and
consumers of medical devices. The FDA also offers pre-submission consultations on the basis of
required regulation standards for manufacturers intending to submit medical devices for
approval.

However, the process of gathering and defining technical and business requirements may require
an in-depth investigation into the intended healthcare market sector at hand. Furthermore, the
CDC provides an outline on how to conduct such a market research to identify the technical and
business requirements within the scope of medical technology.

(Examples of how to form detailed lists of requirements are presented later on in this blog.)

One important thing to remember for any IVD device development project is that there are many
types of users to consider. In addition to the “primary” and “secondary” users discussed in the
beginning of this article, it’s helpful to consider the requirements of others that may be involved.
This includes those involved in purchasing the product, those who warehouse it, and so on. Each
point of interaction plays a potential role in defining the device’s user requirements.

Product Design Frameworks for IVD Device Development

For a thorough grasp of user requirements, start by thinking about how your product will be used
(e.g., by whom, and in what setting?) to establish the product design framework.

This framework incorporates traceability so that every element of the process, such as design
inputs, outputs, verification, and validation, can be traced back to a known user need. In other
words, the user requirements and desired performance of the product define its complexity. The
FDA’s “design control” framework associates closely with ISO 9001 quality management
standards in regard to medical device design. This standardized development framework ensures
that the product’s user requirements are documented and kept in mind at every step of the
development process.

The process begins with the definition of the intended use of the IVD device and is followed up
by the design inputs. These include the user and system requirements that lead into the initial
system specifications. Next, the technical requirements of the design outputs are formed and
reviewed. Verification processes are carried out to ensure that the relevant specifications are met,
such that the design outputs achieve results outlined in the design inputs. Verification examples
for IVD devices may include stability studies, temperature calibrations, and environmental
monitoring. Additionally, the needs and requirements of the users are validated to ensure that the
device satisfies such requirements to keep the user in focus. For IVD devices, validation may be
carried out in the form of a clinical evaluation, whereby competitor devices are compared and
contrasted to observe benchmark results. Finally, all documentation will be kept within a design
history file for future reference.

This framework style is beneficial for all stakeholders as it gains a measure of quality
management, such that decisions, verifications, and validations can be documented and traced
back to specific user requirements. However, this process chiefly benefits the IVD device
manufacturers in the following ways:
 The users and regulation authorities can be satisfied with a framework that
holds the strict user requirements in apparent view at every step of the
design process. Thus, the manufacturer will benefit from a streamlined
Premarket Notification submission, and greater user confidence in the IVD
device.
 All design decisions have an adequate traceability, justification, verification
and validation relating back to the defined user and their requirements. The
manufacturer can then rest assured that they are providing the correct
device to solve the correct problem.
 The device can be easily modified in the future with reference to the original
framework stored within the design history file.

Form Detailed Lists for Understanding User Requirements

Now that we have considered how the FDA interpret the intended use, potential requirements
(ranging from technical details to regulatory authorities), and even the product development
framework, we can form a detailed list of specific requirements to enable your IVD device
development project.
1. A critical first step for your IVD device development project is to determine the problem your
product will solve:
• Why is the IVD device needed?
• What will it do?
• How will it accomplish its usage goal?
• At what point in the patient’s clinical course will it be helpful (e.g., predisposition, screening,
diagnosis, prognosis, therapeutic response prediction, monitoring)?
• Where will it typically be used (e.g., provider office, hospital, in-home)?
• Who will use the product? What is the user’s expected skill level?
• To validate your initial assessments of these questions, it’s best to review and evaluate the
market. What are the trends and competitive products? What does customer research tell you?
Given your patent status, how differentiated will your offering be? Does this open up a new user
type with new requirements?
The research should be carried out within the relevant healthcare sectors and can be obtained
online or offline via surveys, interviews, focus groups, case studies, and context analyses.

2. Based on the data collected during these assessments, define your user or users:
• Will the product be used in a laboratory or in a point-of-care setting (e.g., physician office,
clinic, hospital)?
• What level of training and expertise will the user have in each relevant setting?
• Characterize the business objectives of the organizations that are your target customers. Are
they looking for a product like yours to save them time? To improve the care they can offer? To
differentiate them from other providers? To save them money?

Any of these expectations will affect the user requirements. Summarize the overall market needs,
and outline the use case for your product with as much detail as you can.

It’s vital for IVD device product managers to consolidate market research data to define the user
or users of the IVD device. The product manager should also take note of any relevant user
insights, behaviors, and opinions of similar IVD device designs and their usability outcomes.
This understanding will provide design guidance when formulating future analyses and user
requirements.

3. Perform a functional analysis. This consists of “walking through” various scenarios of product
use, imagining the steps in chronological order throughout the product’s entire life cycle. Begin
with your approach to sourcing raw materials and the manufacturing process. How will user
needs influence the choices you make, or the choices you have, at this stage? The customer
becomes directly involved during the ordering process and is naturally affected by your
distribution and customer support choices. How can you best tailor these to user requirements?
Afterwards, which steps represent the important functions critical to operation? And which steps
have the potential to cause harm or damage? These can be construed as product requirements.

4. End-user implementation of the IVD device is, of course, at the center of the experience. This
is where most of the requirements will be at play. We’ve discussed most of these factors already,
such as training for users, changes in clinical workflow, and total time and throughput. Due to
greater environmental awareness, one factor that has emerged recently is the disposition of used
devices. Diagnostics manufacturers can help their customers think through the practical
considerations involved, given the complexities involved with human biological material. Will
the product be recyclable through the conventional waste management streams or require
incineration due to a risk of contamination? What precautions does the lab or clinic need to take?
In theory, your company could carry out a recycling program of its own, with customers
returning some or part of the device to your facility. This could be a differentiator, but you would
need to carefully design and test the return-for-recycling process and develop a plan for
managing material that is shipped back. In many cases, recycling may not be practical, but
providing recommendations on safe disposal for consumable IVD products is a worthwhile
element in the launch plan.

5. Finally, evaluate whether the intersection of functional-analysis requirements and the more
general user requirements (e.g., process, performance, safety, cost) results in additional
requirements you’ll need to address. For example, if there is demand for a used product to be
returned to your company for recycling, what will that recycling program cost your company,
and how does that cost affect the overall price you’ll have to charge the customer. What’s the
interplay of price and recycling? Of testing throughput and the number of devices you ship in
each box? Look at how a small change in one part of your product’s life cycle affects everything
else downstream, and potentially even changes assumptions upstream. This may enable you to
anticipate and address problems before they arise—setting your IVD device development project
up for success.

Summary
As simple as it sounds, understanding user requirements in detail is a critical part of your IVD
device development strategy and is the foundation of your go-to-market plan. The more
thoroughly you define your anticipated users, examine their use context, and explore all the
possible needs and expectations they may have, the more completely you can prepare to provide
them with a product that not only meets but exceeds their expectations, and becomes a market
success.

TE develops and manufactures life science and diagnostic products, including IVD and
companion diagnostics. We help our clients quickly turn their technologies into user-friendly,
cost-effective, and clinically validated commercial products of quality through a collaborative
approach. Our in-house usability testing group and clinical research organization ensure that
your product is optimized for the benefit of the end-user, your organization, and regulatory
stakeholders.
Proven IVD Expertise, From Concept to Market

This is How to Write a Foolproof User

Requirements Specification
Filed under Blog, Opinion and Expert Views, Technical Tips and Guides
by on 24 March 2021
Ask any group of software developers their pet peeve, and you can guarantee the topic of poorly
written user requirements specifications will make an appearance. After all, no one wants to
begin a project unsure of exactly what the client is looking for. A thoughtful and well-written
user requirements specification saves time and money, and ensures everyone is singing from the
same hymn sheet.

To put it plainly: the better the user requirements specification, the better the outcome. This is
a thought well worth keeping in mind as you embark on your project.

What is a user requirements specification (URS)?

In software engineering or systems design, a URS is a planning document that specifies what the
software or system needs to do. It is written from the point of view of the end user and does not
need to be technical or complicated. According to Intersys MD Matthew Geyman, “A well-
written URS is clear, unambiguous, well explained and concise. It helps the systems designer or
software engineer fully understand a client’s needs, and can be used to plan a timetable, estimate
costs and so on.”

Note: this is a separate document to the functional or software specification. These are
documents produced by the software developer that specify how the requirements in the URS
will be met.

Why it’s important to get it right

A poorly-written URS with vague requirements and ambiguous language can lead to confusion
between the client and the provider. In some cases it leads to the need for extensive reworking,
which in turn can lead to blown budgets and broken deadlines. “A detailed and explicit spec
reduces unknowns and produces tighter quotes, as well as better outcomes,” says Matthew.

When creating a URS, there are two things to consider: what to include in the document and how
to write it.

What to include

The exact information that needs to be included will vary from project to project. Evidently,
a complex project will have more requirements than a simple one. However, there are some
fundamental principles and important features that amount to good practice for most projects,
regardless of size.

Authors

It is a good idea to begin with a list of the people responsible for creating the user requirements
specification. This should include the name, job title, date and signature of everyone who co-
authored it. Having all responsible stakeholders ‘sign off’ on the URS ensures that all those
involved are clear that the document has been approved.
Introduction

This can be brief. The most important things to include are who you are and why the need for
this URS has arisen. It might be helpful to give a very brief background of the company. For
example, [Company Name] is a start-up organisation based in the south west of England. We
wish to develop a software app that helps hikers and walkers find trails and pathways in their
local area. This user requirements specification (URS) documents the user requirements for the
development of the app.

Objective

A good objective clearly describes the goal of the project in non-technical terms.

This should give a brief overview of the project, in non-technical terms. It should be written in
a narrative or descriptive style (ie not a checklist or abbreviated language), and outline what the
product is intended to do. To assist with writing this section, ask the following questions:

 What am I trying to achieve?

 What problems will this product solve?
 How will it streamline or improve the existing system, or similar product in the
marketplace (if one exists)?

In the case of the hiking app example above, it might be something like this: “Our goal is to
create an app for both iOS and Android phones that guides walkers and hikers to trails in their
immediate vicinity. The app should allow users to create profiles, upload photos, design trails
and write reviews. Existing hiking apps often include information that is out of date and/or
unverified. By allowing users to update trail information, they will collectively have more
reliable data with respect to the condition of a given trail at any given time.”

Requirements

This is the most important part of the URS. Take each requirement one at a time, ensuring that it
is precisely described. Remember, you should write this in narrative form, focusing on what the
product should do, rather than how it should do it. Continuing with the hiking app example,
a requirement might be: “I’d like the Welcome screen to include a link to the user’s profile, as
well as links to completed trails and suggested trails.”

It is good practice to number each requirement and also to indicate whether it is high, medium or
low priority.

Think about:

 The impact expected

 What you want to happen at each point
 What different users would expect to see. For example, ‘As an admin, I would expect to
see …’ or ‘As an end user of the app, I would expect to see…’
Supporting documents

For some projects, supporting documentation may be appropriate. This may include:

 Images, sketches or mock-ups of concepts central to the project, such as user interfaces
 Examples of software and systems that already fulfil some of the requirements you’d like
incorporated
 A site map (for a website)
 End-user personas

Glossary

If your document uses technical or non-technical jargon, abbreviations or acronyms, make sure
to explain them clearly here.

Index

If your document is particularly long, consider including an index at the end.

How to write it

The above section outlines what you should include in your document. What follows are some
notes on describing your requirements clearly. Don’t see these as ‘style points’ or ‘the icing on
the cake’. Ambiguity is the enemy of project success and expressing yourself precisely is vital:
your developer will thank you for communicating in an unambiguous way and you’re likely to
be far happier with the end results too.

1. Use SMART targets

 Specific
 Measurable
 Achievable
 Realistic
 Time-bound

SMART targets provide a good way to ensure your user requirements specification is well-
defined and verifiable.

Specific: Your requirements should be clear and specific. For example, rather than drafting
a vague requirement such as ‘improve ad latency’, think ‘reduce ad latency by 50%’.

Measurable: To be measurable, a requirement must state something that can be confirmed by

examination, test, or demonstration. Avoid subjective statements such as ‘easy’ or ‘faster’. If it
can’t be measured, there’s no way for both parties to agree that the requirement has been met.
Achievable: Your objective needs to technically feasible. If you’re not sure whether something is
technically possible, further research is needed. If you’re still not certain, word what you want as
a ‘goal’ rather than as a ‘requirement’.

Realistic: Even if something is technically achievable, it may not be realistic due to budget
constraints, time restrictions, regulatory requirements or other limitations. It’s important to be
realistic when determining your requirements.

Time-bound: What is the time-frame for the project?

2. Avoid ambiguity

A user requirements specification should be clearly written, using simple sentences, and without
ambiguity. Examples of ambiguous words are:

 improve
 fast
 slow
 user-friendly
 easy
 sufficient

What exactly is meant by user-friendly or sufficient? These terms are subjective and therefore
impossible to measure.

Similarly, avoid acronyms, abbreviations and jargon as they may lead to confusion.

3. Take one requirement at a time

This makes it easier for everyone to see how each requirement has been developed and tested.

4. Prioritise

Think carefully about word choice. Words such as ‘shall’ and ‘will’ typically define
requirements. They imply that the requirement must be met. Words like ‘may’ and ‘could’ define
goals that are desirable but not necessarily required. Do not confuse these terms, and make sure
you use them consistently in your document.

Following these general guidelines will help ensure that your brief is clear and concise. We will
follow up this post with a full user requirement specification template, which you can use when
working with Intersys or any other software developer.

Intersys designs bespoke software for a wide range of sectors including life sciences, legal,
education, renewables, TV and media, and many more.
Find out more about our software development services or get in touch now to start
a conversation.

User Requirements Specification URS Template

Last Updated on Mon, 04 Jul 2022 | Processes for Projects

The URS document describes, in business terminology, the client's project requirements. Many
failed projects have had either no or poorly documented user requirements. The client should
typically complete the URS, but this does not always happen. In any event, be prepared to
complete this template for the client, because the URS sets the entire direction of the project.
Without a URS in place, you may encounter clients asking for more than what was originally
bargained for. The URS usually precedes a system requirements specification document. To
ensure that the URS template is properly completed, engage the client in a series of discussions,
questionnaires, or workshops to obtain the requirements (see Figure 7.3).

Figure 7.3: Importance of URS on projects.

Continue reading here: Eight Essential Project Artifacts One Could Use For A 30-month Project
Was this article helpful?