Scenario Types and Their Usage

In Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle, Ian F. Alexander and Neil Maiden write about the types of scenarios and when to use them in software development.

Scenario Types and Their Uses
Alexander and Maiden write the following:

• 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.
• 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.
• 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.
• 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.

Key Take Aways
My key take aways are:

• Expand the options in your toolbelt. If you only have a hammer, everything's a nail. A one-size fits all doesn't cut it. Having a wider range of techniques, means you can choose the most effective technique for the task at hand.
• Some techniques are more effective than others. While this is an obvious statement, consider how you can test and experiment with the different techniques to improve your current product development results.
• Focus is key. Some techniques are optimized for a particular focus. For example, Misuse Cases and Exception Scenarios force you to consider, how you will capture and share unexpected or abusive situations.
• Use the right tool for the job. I think it's important to know the flavors of scenario types and when to use them. In practice, you may only end up using a few of the various options, but the key is to use the right tool for the job. For example, while a detailed use case can help a developer turn requirements into work items, a story might be a better tool for engaging the customer and figuring our their needs. In another example, using a Swimlanes diagram can help show the interplay across roles in a system.