Scenarios - General Explanation and Template

Owned by Sander de Ridder
Last updated: Dec 14, 2023 by Former user (Deleted)
2 min read

Scenarios describe how a user could interact with a system to achieve a goal. It breaks this interaction down into simple steps. Scenarios are meant to be practical and anyone should be able to read them and understand them. They will provide insight, show us what is missing from a practical point of view and help us to decide which metroline pages should be prioritised.

Template

Scenario <NAME>

Give the scenario a name which explains what it’s about

Actors

Who and which systems are involved? Make actors “real”, since details matter. Some example actors:

  • Researcher Alice, a PhD student doing a small single-center KWF project at the NKI (shares dataset)

  • Health-RI Servicedesk

Keep in mind:

  • If it turns out a scenario is the same for NKI, Amsterdam UMC, or any other UMC, we can point that out or merge them. And if there are relevant differences it’s perfectly fine to have seperate scenarios.

  • The actors are very important. If, for example, Alice is part of a huge multi-center consortium, the steps could be very different and this may lead to a new scenario.

    • we can create a new scenario if this changes the scenario in a major way or create an Alternative Flow if the changes are minor

Description

Describe the scenario in textual fashion. What is the user trying to achieve?

Conditions

Are there any assumptions when we enter the scenario? For example, in a scenario where a user Alice wants to enter clinical data in an Electronic Data System, a condition could be “Alice can log into the system”. This condition itself could be the outcome of another scenario in which a login is created.

User perspective → (user as the one onboarding the data, and/or user who search and request the data from national catalogue)

Describe the scenario step-wise. How is the user interacting with other actors and the system? Break it down, keep it simple and make it really practical!

Number the steps, since this will make it more easy to refer to them and to define alternative flows. For example:

  1. Alice goes to the CASTOR EDC website

  2. Alice logs into CASTOR

  3. She goes to the XYZ-study

  4. She opens the eCRF

  5. She enters the data

Alternative Flow

Describe alternatives, basically when things don’t go according to your normal flow.

  1. Alice logs into CASTOR but gets a password error

    1. She resets her password

  2. The XYZ-study is not visible

    1. She contacts the study owner wait for appropriate permissions