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:
- 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)
- Actor - any person, system, or event external to the system under design that interacts with that system through a use case
- Pre-conditions - any fact that the solution can assume to be true when the use case begins
- Flow of events - Describes what the actor and the system do during the execution of the scenario or use case
- Post-conditions - Any fact that must be true when the use case is complete
- Associations - relationships between actors and use cases are called associations