Scenarios and Use Cases

In the engineering, technology and system development world, a model is anything used in any way to represent something. Some models are physical objects, for instance, a toy model which may be assembled, and may even be made to work like the object it represents. Other models are conceptual models, and are used to represent concepts and/or processes which are part of a system.  Each of these types of model is used to help us know and understand the subject matter we are trying to represent.

There are a number of visual and descriptive techniques used by software engineers and business analysts to model the “as is” and “to be” nature of the system they are analyzing.  Over the course of my posts here on this blog, I’ll delve into a number of these popular modeling techniques. 

Scenario and Use Cases

Scenarios and use cases are written to describe how an actor interacts with a solution to accomplish one or more of that actor’s goals, or to respond to an event.

A Scenario is generally understood to describe just one way that an actor can accomplish a particular goal, while a use case describes all the possible outcomes of an attempt to accomplish a particular goal that the solution will support.  Scenarios are written as a series of steps performed by actors or by the solution that enable an actor to achieve a goal.

A use case describes several scenarios in the form of primary and alternate flows. The primary or basic flow represents the simplest way to accomplish the goal of the use case. Special circumstances and exceptions that result in a failure to complete the goal of the use case are documented in alternate flows.

Scenarios and use cases involve:

1. Name - the scenario or use case must have a unique name within the project, and should describe which goal or event it will deal with, and generally includes a verb (describing the action taken by the actor) and a noun (describing what is being done or the target of the action)
2. Actor - any person, system, or event external to the system under design that interacts with that system through a use case
3. Pre-conditions - any fact that the solution can assume to be true when the use case begins
4. Flow of events - Describes what the actor and the system do during the execution of the scenario or use case
5. Post-conditions - Any fact that must be true when the use case is complete
6. Associations - relationships between actors and use cases are called associations