I use scenarios all the time for anything from designing a user experience to evaluating architecture. Scenario is an overloaded term though. There’s lots of types of scenarios. If you know the types of scenarios, you can use the right one for the job. For example, exception scenarios are useful for assessing robustness. Misuse cases are helpful for figuring out potential threats and attacks.
Summary Table of Scenario Types
In the book Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle
| Scenario Type | Usage |
|---|---|
| Alternative World, Situation, Snapshot. | A Scenario that describes a more or less static picture of an imagined future (business) situation, often parameterized in a Simulation model to enable system options to be explored and compared. Uses: Evaluation of requirement stability, planning of business and system development. |
| Concept of Operations. | A set of Scenarios describing in more or less design-independent terms how a system such as an aircraft is expected to be used in practice. Uses: Early stages of procurement; preparation of “user requirements” for a system. |
| Exception(-handling) Scenarios. | A Scenarios that describes how to handle an undesired Event, that is, an event that interferes with progress towards a Goal. Uses: System reliability and safety-dealing acceptably with abnormal situations. |
| Negative Scenario, Misuse Case. | A Scenario (generally represented as a brief text, or as a named Goal in a bubble on a Use Case diagram) that is desired not to occur by the stakeholders responsible for a system. Uses: Identification of threats, safety hazards, security risks, exceptions, and test cases. |
| Roleplay, Playthrough (of an Acted Scene). | A Scenario acted out (in a lively, dramatic and humourous way) for example, by workshop participants to illustrate a desired behavior of or a possible problem with a (future) System. Uses: Early stages of gathering “user requirements”; getting “buy-in” and invovlement of non-technical stakeholders. |
| Scenario Sequence, Script. | A simple (straight-line) list of steps ordered by time, possibly numbered, representing a Course of Events. Each step is an action taken by a named role (Actor). Uses: Describing stakeholder needs and desired system behavior in a form suitable for both stakeholders and developers. |
| Scripted Sequence Diagram. | A UML Sequence Diagram with timelines for a human Actor and the system under design. The system’s timeline shows a sequence of activities, connected by incoming stimuli and outgoing responses to the actor’s timeline. Each such round-trip transaction is annotated with text from steps of a System Use Case. Uses: A suitable first step to designing a system to realize (part of) a System Use Case. Helpful as an overview for designing a sequence of user interaction screens. |
| Simulation, animation. | A computer-based description of the behavior of a system, often in the form of images, which narrates a Scenario. Exploring the effects of design choices; reflecting the impact of stated requirements on the design in terms that stakeholders can immediately understand |
| Story. | A text that narrates a Scenario with little or no formal structure. Uses: Describing stakeholder needs and desired system behavior quickly and informally. |
| Storyboard. | A sequence of diagrams or other images that narrates a Scenario. Uses: Making a Story easier to visualize and understand. |
| Swimlanes Diagram. | An analysis diagram such as a flowchart or UML activity diagram, arranged with a “swimming pool lane” usually vertically down the page for each Role (Actor), showing both the actions of each Role and interaction between roles over time. Uses: Translation of Scenarios and Use Cases into analytic form; early step in system design, to help identify system objects and decide which actions to automate. Suitable for validation by stakeholders. |
| Test Case. | A Sequence of steps to be run to verify that a system works as intended. uses: Verification planning. |
| Use Case. | The Scenario format used in UML, consisting of an Actor, a Goal, and a text that is typically a detailed structure containing a set of related scenarios representing different combinations of parts (Courses, Sequences) of the Use Case, depending on Events. Uses: Defining desired system behavior analytically, in a form that accurately guide system development when direct contact between stakeholders and developers is not available, but that stakeholders can still validate. |
| User Story. | A Scenario format consisting of a brief and often informal narrative text (a Story) that typically mentions an Actor and the actor’s Goal, with a description, possibly by example, of how the goal can be achieved. Uses: Guiding agile development (of tests and software) for a short period, until the next meeting of stakeholders and developers. |
Secure Your Network, Host, and Application
can you give some examples of a scenario problem to be solved?
@Brill
Sure … you can thin in terms of use cases:
* Browse product catalog
* Order products
The scenario part comes in when you have a specific instance of a use case. For example, “Customer x buys product Z.”
Having the specific instance is useful because you can now test against it. Can customer X buy product Z and does it pass the acceptance criteria? … etc.
Just wondering, do you break down a scenario into specific requirements? Similarly, do you break down a requirement into more detailed scenarios?
Thanks in advance!
@ dnise
Think of the scenarios as a way to put requirements into context.
Scenarios put the user requirements, system requirements and tech requirements into the context of a goal being performed.
I prefer to think in terms of scenarios and sub-scenarios. I also prefer to have a scannable list of requirements as well as a scannable list of the scenarios, but connected to the requirements. They support each others. If you have a requirement, but no scenario, you have to ask who’s it for or what’s it for. If you have a scenario, but you don’t know the requirements or tests for success, then you don’t know when you’re done.
A very good book on this with concrete examples is Writing Better Requirements by Ian Alexander.
Thanks for the clarification JD.. and also thanks for the reference. I’ll check that out. Happy Holidays!