Use Scenario - User Story - User Task: Finally understandable

IEC 62366-1 uses the concept of (hazard-related) use scenario.

The FDA uses the concept of critical (user) tasks. In development, one works with use cases and user stories.

This diversity of terms makes a common understanding difficult. However, this is necessary to create consistent and legally compliant usability files and to avoid regulatory problems. This article provides clarity.

1. Why you should deal with use scenarios and user tasks

a) Because it is required by law

Manufacturers must demonstrate the usability of their medical devices and their safe use. The FDA and laws in Europe and other markets require this.

Manufacturers should describe the use scenarios and user tasks for both the US and EU markets. Neither use cases nor user stories are required.

Overview

FDA requirements

In its guidance document Content of Human Factors Information in Medical Device Marketing Submissions, the FDA requires manufacturers to identify critical tasks and eliminate or at least reduce use-related hazards. The same requirement is found in the FDA's HFE Guidance.

In the same document, the FDA also requires to describe use scenarios:

MDR and IVDR requirements

The EU MDR and IVDR regulations only require the risks arising from use errors to be eliminated or minimized. The terms "use scenario" and "critical task" are not used in the regulations.

IEC 62366-1 requirements

As with all essential safety and performance requirements, manufacturers should use harmonized standards to demonstrate compliance with these requirements.

Regarding usability, EN IEC 62366-1 is the standard to yet to be harmonized. It requires manufacturers to

• identify and describe the hazard-related use scenarios. This assumes that manufacturers have identified and described the use scenarios as a whole,
• describe the tasks and their sequence,
• select the hazard-related use scenarios that are to be part of the summative evaluation (usually usability tests),
• justify this selection,
• specify the UI based on the use scenarios, and
• plan and conduct the summative evaluation for each selected hazard-related use scenario.

b) Because this allows to develop better devices

Products are usable if they fulfill the tasks of the users as effectively, efficiently, and to their satisfaction as possible. In fact, this is the definition of usability (according to DIN EN ISO 9241-11:2018-11).

To do so, it is necessary to identify the tasks and consider how and in what order the users should interact with the device. These are the use scenarios (as expressed by the definition).

2. Definitions and delimitations

a) Use scenario and hazard-related use scenario

IEC 62366-1 defines the term "use scenario":

The subset of hazard-related use scenarios is particularly relevant:

The standard notes that hazard-related use scenarios are often associated with a use error. In fact, in practice, this should almost always be the case.

b) (User) tasks und critical task

Although IEC 62366-1 speaks of tasks, it does not recognize any concept of "critical tasks" in the normative part. In the informative part, it writes:

"A TASK in a HAZARD-RELATED USE SCENARIO in which a USE ERROR can lead to significant HARM, can be thought of as a "critical task."

In contrast, FDA knows and defines the term "critical task":

In the same document, it also defines the terms " task " and " serious harm":

In defining the term "harm", the FDA falls back on the definition in IEC 62366-1.

The definition of "serious injury" can be found elsewhere:

d) Distinction between use scenario and use case

Definition of „use case“

Unfortunately, there is no uniform and authoritative definition of the term "use case": for example, the following can be found:

• "A use case describes a sequence of actions a system performs that yields an observable result of value to a particular actor." [Ivar Jacobson].
• "A use case is a sequence of actions or steps that typically define the interaction between a role (also called an actor in UML) and a system to achieve an objective." [Source]
• "A use case specifies a sequence of actions that the system performs in interaction with the environment." [Source]

Comparison of the definitions with use scenarios

These definitions are not congruent.

1. According to Ivar Jacobson, it is only about the system. It is NOT about the actions of a user.

2. The second definition talks about "Actors." Examples of these actors are not only users but also other systems.

3. The third definition does speak of a sequence of actions. However, these are actions that the system performs with the environment, not actions that a user performs with the system.

This makes it clear that use cases (according to Ivar Jacobson's definition) and use scenarios have nothing to do with each other directly:

This is exactly what makes use cases valuable: they allow you to translate the usage scenarios into system performance without trying too hard, quite naturally! One consistently uses use cases after having specified user requirements and scenarios beforehand.

e) Delimitation of use scenario and core task

A use scenario does not correspond to a core task. A core task is a task that a person must perform in order to achieve an objective (typically in terms of intended use).

A core task does not have to relate specifically to the use of a device. For example, a core task could be "taking a pulse," which could be done without a device. A use scenario, on the other hand, includes the technical solution, so it would describe the use of a heart rate monitor from the user's perspective.

A core task usually consists of several subtasks. Systems support some of these subtasks, sometimes all of them. The subtasks that users perform on the system form the use scenario.

Workflow in usability engineering: usage scenarios and tasks

On the other hand, the term "workflow" is used as a synonym of "usage scenario". Then a workflow describes how (individual) people interact with systems in the context of a task.

g) Delimitation of use scenario and user story

Objective and formulation templates

Many manufacturers use user stories to formulate requirements - usually for software - in the language of the customer or user. To do this, they use "natural" formulations that correspond to everyday language, but usually resort to sentence templates such as "As a <role> I can <activity> so that <business value>."

An example of a user story is:

Comparison with use scenarios

User stories do not fix sequences of activities. They are, therefore, not a substitute for use scenarios.

User stories from a regulatory perspective

There are no regulatory requirements that oblige or even suggest manufacturers to use user stories.

The Johner Institute even explicitly advises against it because user stories often lead to manufacturers not meeting regulatory requirements precisely. More on this in chapter 4 b).

3. How to document use scenarios and user tasks

a) What the regulatory documents say

Neither the FDA nor IEC 62366-1 set specific requirements for how manufacturers should document use scenarios and tasks. IEC 62366-2 only says that there are many possibilities:

A task list is often not sufficient to meet the requirement of IEC 62366-1 to describe the use scenarios. For example, the outputs to be achieved or postconditions that can be used to review whether the user has successfully completed the task are missing.

b) What the Johner Institute recommends

This is another reason why we recommend describing each use scenario as follows:

Part 1: Cross-task aspects

First, there is a description of the following aspects:

• Intended user groups

This can be a reference to the roles specified in the intended use or "use specification."

• Intended use environment

Again, such a reference is recommended if the (extended) intended use describes this information with sufficient granularity.

• Preconditions

This section should describe preconditions that must be met in the system or use environment, e.g.:

• • In the system: permissions have been granted, and data has been captured
  • In the use environment: information or additional tools are available
• Postconditions

The type of postconditions is similar to the preconditions. An example of a postcondition is that certain information must be recorded in the system.

Part 2: Tabular description of the tasks

Then follows a table, which specifies the tasks with their attributes line by line:

4. Practical tips: What you should consider

a) Choose the right granularity for use scenarios

Manufacturers should choose the right granularity when describing the use scenarios:

• Too high a granularity means unnecessary effort and leads to the use scenario changing even for the smallest changes. This increases the effort for "re-validation."
• Too low a granularity may not allow individual critical tasks to be identified, leading to the risk that these tasks have not been summatively selected and evaluated. As a result, potential usage errors in their identification may be overlooked, and an unsafe device may be placed on the market.

Therefore, especially for software UIs, the following heuristics can help:

• A core task consists of seven +/- two subtasks, and core tasks should not be confused with use scenarios (see above).
• Individual mouse clicks do not represent a task.
• For screen-based devices, a screen often represents a subtask or task within the use scenario.

b) Be careful with user stories

User stories blend the various concepts that medical device manufacturers must describe:

The regulations require "traceability" between intended use, stakeholder requirements, and system requirements or system specifications. This will not succeed if they are all mixed up in one sentence.

Working with user stories is no substitute for requirements engineering, especially for systematically deriving user requirements.

Therefore, do not use user stories. They cause more harm than benefit.

c) Use professional requirements engineering

Instead, proceed as follows:

• Formulate the intended use, and thus the medical purpose and specified users.
• Derive the requirements, the user requirements, and the core tasks using the context method.
• Based on this, specify the usage scenarios and based on these, the interactive device.
• Validate this specification.

5. Summary and conclusion

a) Variety of terms

There is a large number of terms that sound similar but should not be confused with each other:

1. use scenario and "hazard-related use scenario."
2. user tasks and critical tasks
3. core task or core task
4. use case
5. user story

Manufacturers must not confuse these terms. Otherwise, there is a risk of regulatory difficulties.

b) View through the regulatory lens

From a regulatory point of view, only the first two points are relevant. Even if the FDA places somewhat more emphasis on the concept of tasks or "critical tasks" and IEC 62366-1 places more emphasis on the concept of "use scenarios," it is essential in any case to identify use scenarios and their tasks in as much detail as possible and to describe potential hazards and the severity of any harm in great detail.

c) Procedure

The description of use scenarios does not replace requirements engineering, nor does it constitute the beginning of requirements engineering. Rather, use scenarios represent an intermediate step. This is because use scenarios are already part of the solution domain.

d) Meaning

Precisely identified use scenarios are critical for

• task analysis and risk analysis,
• safe medical devices,
• the summative evaluation of medical devices,
• a compliant usability file and hassle-free approvals,
• medical devices fit for use and sought after by customers.

Therefore, manufacturers are well positioned if they systematically identify and describe the use scenarios and evaluate them during usability tests.