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.
Actor perspective
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:
Alice goes to the CASTOR EDC website
Alice logs into CASTOR
She goes to the XYZ-study
She opens the eCRF
She enters the data
Alternative Flow
Describe alternatives, basically when things don’t go according to your normal flow.
Alice logs into CASTOR but gets a password error
She resets her password
The XYZ-study is not visible
She contacts the study owner wait for appropriate permissions