Task Analysis as Requirement Management method in Medical Device Development

Requirements Management is strange. It is a well-researched area which each year yields an impressive number of articles, conferences, and known best-practices. Still, this body of knowledge remains remarkably underused by the people who would gain from it most. In many of the organisations I encounter, well-established requirements elicitation techniques are simply not undertaken.

Perhaps this has to do with the deceivingly simple task at hand. "I just need to write down what the device should be able to do. How hard can it be?". Hard enough it seems, if one considers the many reports stating how mismanaged requirements lead to enormous costs down the line.

This is exactly what Prof. Dr. Samuel Fricker and his team have established in their paper "Requirements Engineering: Best Practices" (2015).

He concludes that although each and every one of the 419 participating organisations "...elicited, planned, analysed, specified, checked, and managed requirements...", very few of them apply formal requirement elicitation techniques.

For those who did "...only three techniques correlated with requirements engineering success: scenarios of system use, business cases, and stakeholder workshops."

The common idea with these techniques is to:

1. bring structure into the elicitation process
2. involve many people in the discussion

Both parts are essential to success. Doing 1) without 2) misses out on critical knowledge in the organisation. Doing 2) without 1) is just wasteful. Personally, I have particularly good results from applying a variant of Use Scenarios called "Task Analysis / Task Risk Management" described by Andy Brisk. In short, this is a basic Task Analysis method, where processes are analysed step by step for requirements and risks.

Opposing the natural inclination of engineers to decompose a system into parts for analysis, this method focus on how you use the device, i.e. the system is decomposed into the scenarios where the user interacts with the system.

In other words, we let use drive design.

Mr. Brisk lists a number of process examples that coincides well with those applied to a generic medical device, such as:

• Unpacking
• Setup / Installation
• Calibration
• Startup
• Daily Operation
• Shutdown
• Maintenance
• Service
• Alarms and Alerts
• Decommission

If the found processes are too large to analyse, Mr. Brisk advises decomposing them further into manageable sizes.

Once the processes are identified, Mr. Brisk prioritizes the processes according to risk, in terms of:

• Are there significant damaging consequences if the task is performed incorrectly? (High Severity of potential Harms)
• Is there a reasonable likelihood that tasks will be performed incorrectly? (High Probability of Use Errors)

The idea of this risk-based prioritization is to focus on high-risk processes and analyse them early and thoroughly.

The processes are now analysed step-by-step, preferably by a group of people. They imagine and discuss the steps an imaginary user goes through to perform a task. How is the system accessed? How does the user communicate his intentions to the system and vice versa? What potential errors might the users make?

Coloured post-it notes can be used to describe the steps on a wall. A tip is to use different colours for process steps and identified potential use errors. This approach manages to create both a common vocabulary of describing the system and its use, as well as creating a common understanding of how the device is meant to be used. It also tends to highlight areas where people had a different understanding of how the system should be used (by simply measuring the loudness of the discussion).

The Task Analysis described above is an easy and straight-forward way of eliciting requirements AND uncover high-level risks in a usage context. What makes it particularly suitable for Medical Device manufacturers is that it combines risk- and requirement elicitation in a single, common activity. Much too often, these two tasks are performed by separate groups in separate contexts.

A further bonus is that it intrinsically produces both Use Scenarios and Use Errors, which are substantial and essential parts of the Usability Management File.

Some important lessons learned using this method include:

• Try to use a similar step granularity in all processes
• Before starting, try to agree on what shall be considered "known" about the system
• Define a clear Goal as well as Start and Endpoint for each process in order to declare the scope
• Be generous with risks, rather too many than too few
• Do not forget to write down the elicitated Scenarios and Risks before you leave the room

Aligned Elements supports the documentation of Use Scenarios and their associated Use Errors as described above in our IEC 62366 Configuration. The Use Errors are applied in the overall High-Level Risk Assessment to drive further design decisions.