Scenarios describe how a user could interact with a system to achieve a goal. The approach It 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 and understand them should be able to 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
...
Who and which systems are involved? Make actors “real” if this helps the scoping, for example, 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?
...
Are there any assumptions when we enter the scenario? For example, in a scenario where a user Alice want 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.
Researcher perspectiveUser 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!
...