Scenarios describe how a user could interact with a system to achieve a goal. The approach breaks this interaction down into simple steps, which can then pave the way towards the solution. Scenarios are meant to be practical and anyone should be able to read them should be able to understand them.
Scenario <NAME>
Give the scenario a name which explains what it’s about
Actors
Who and which systems are involved? Make actors “real” if this helps the scoping, for example:
Researcher Alice, a PhD student doing a small single-center KWF project at the NKI (shares dataset)
If Alice is part of e.g. a huge consortium, 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 want 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.
Researcher 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