REQUIREMENTS
ARTIFACTS –
SCENARIOS
Requirements Engineering
Framework Overview
Framework introduced by Klaus Pohl [1]
Definition
• A scenario typically documents a concrete example of
system usage.
• A scenario describes a concrete example of satisfying or
failing to satisfy a goal (or set of goals). It thereby
provides more detail about one or several goals. A
scenario typically defines a sequence of interaction steps
executed to satisfy the goal and relates these interaction
steps to the system context.
Brief Example
• “Automatic braking maneuver” example [1]:
• Carl drives his car on the motorway at a speed of 50 mph. Peter,
the driver of the car ahead of Carl, steps on the brake pedal firmly.
After recognizing that the car in front is braking, Carl pushes on the
brake pedal as well. The on-board computer of Carl’s vehicle
detects that the safety distance to Peter’s car is no longer
maintained and issues a warning to the driver. The distance
between the two cars continuously decreases. In order to support
the driver, the on-board computer initiates an automated full
braking. The computer informs Carl about the automatic braking
maneuver. After the distance between the two cars stops
decreasing, the on-board computer terminates the full braking
maneuver. The on-board computer continues controlling the speed
of Carl’s car until the safety distance to Peter’s car is maintained
and informs Carl about the end of this maneuver.
Motivation
• Goals alone do not sufficiently support the elicitation of
requirements.
• Stakeholders typically find it easier to communicate about
requirements in terms of examples rather than in terms of
abstract intentions.
• Scenarios are used as middle-level abstractions between
conceptual models and reality.
Context Information in Scenarios
• Scenarios can include context information such as:
• Actors – Persons or systems interacting with the system.
• Roles – Characterizes a specific class of actors. It is defined in terms
of relationships and responsibilities that actors occupying this role
have with regard to system.
• Goals – Scenarios illustrate the satisfaction of goals.
• Preconditions – Define conditions that must hold before executing the
scenario.
• Postconditions – Define conditions that must hold, either within the
system or in the system context, after executing the scenario.
• Resources – Special preconditions that must hold so that a scenario
can be executed. They refer to persons, information, temporal,
financial or other material resources that are needed for successful
execution of the scenario.
• Location – It can be a real or fictional place where the scenario is
executed.
Scenario Classifications
• A scenario can be classified according to multiple different
criteria, which leads to few different distinctions:
• Current state and desired state scenarios
• Positive and negative scenarios
• Misuse scenarios
• Descriptive, exploratory and explanatory scenarios
• Instance scenarios, type scenarios and mixed scenarios
• System-internal, interaction and context scenarios
• Main, alternative and exception scenarios
Current-State and Desired-State
Scenarios
• Current-state scenarios document current system
usage. Based on these usage scenarios, conceptual
models of the current system are created.
• Desired-state scenarios describe desired system usage.
They describe a desired but not yet implemented reality.
Desired-state scenarios are important drivers for change
definition.
Positive and Negative Scenarios
• Positive scenarios document a desired sequence of
interactions that satisfies a goal or set of goals associated
with the scenario.
• Negative scenarios document a sequence of interactions
that fails to satisfy a goal or set of goals associated with
the scenario. A negative scenario can be:
• Allowed – In case of allowed scenario, the system is required to
support the documented sequence of interactions even though
some goals are not satisfied when executing this sequence.
• Forbidden – In case of a forbidden scenario, the failure to satisfy
the related goals cannot be tolerated, for instance, because the
respective goals are critical for the system and/or its context.
Misuse Scenarios
• A misuse scenario documents a sequence of interactions
in which a hostile actor uses the system against the
stakeholders’ intention.
• They document the usage of a system against its
purpose.
Descriptive, Exploratory, and Explanatory
Scenarios
• Descriptive scenarios describe a process or workflow
for the purpose of understanding its operations, involved
agents, triggering events etc. They primarily support the
elicitation and refinement of goals and solution-oriented
requirements.
• Exploratory scenarios are created to explore and
evaluate possible, alternative solutions in order to support
the selection of one alternative solution.
• Explanatory scenarios are created with the aim of
explaining a goal, an alternative solution, or a sequence
of interactions. It typically includes rationales for the
individual interactions as well as the sequence of
interactions.
Instance and Type Scenarios
• This classification is made by scenario’s level of abstraction.
• Instance scenarios describe a concrete sequence of
interactions between concrete actors. For example, the actors
of instance scenarios are concrete persons such as “Carl
Miller” or concrete systems such as “the X1000 mail server”.
Scenarios at the instance level are also referred to as “user
stories” or “concrete scenarios”.
• Type scenarios abstract from the concrete actors, inputs and
outputs of a specific sequence of interactions. A type scenario
refers to types of actors such as the role of a person (e.g.
“driver” instead “Carl Miller”).
• Mixed scenarios contain content at both the instance and type
level. In practice, typically, this mixed scenarios are used.
System-Internal, Interaction, and Context
Scenarios
• System-internal scenarios document only
system-internal interactions, i.e. a sequence of
interactions among different parts of a system. [2] They do
not document any interactions between the system and
the context.
• Interaction scenarios document interactions between
the system and its actors (i.e. persons and systems in the
context of the system). [2] They describe the embedding
of the system into the context in a usage-oriented manner.
• Context scenarios document the direct interactions
between the system and its actors as well as additional
context information that is relevant for the system usage
of the system itself, e.g. interactions among the actors as
well as the indirect users of the system.
Main, Alternative, and Exception
Scenarios
• Main scenarios document the sequence of interactions
that is normally executed in order to satisfy a specific set
of goals.
• Alternative scenarios document a sequence of
interactions that can be executed instead of the main
scenario and that results in the satisfaction of the goals
that are associated with the main scenario.
• Exception scenarios document a sequence of
interactions that is executed instead of the interactions
documented in another scenario (main, alternative, or
exception scenario) when an exceptional event occurs. As
a consequence of the exceptional event, one or multiple
goals associated with the original scenario cannot be
satisfied.
Use Cases
• Use cases group a main scenario with corresponding
alternative and exception scenarios.
• It is the specification of sequences of actions, including
variant sequences and error sequences, that a system,
subsystem, or class can perform by interacting with
outside object to provide a service of value. [4]
• Use case is contained of:
• Context information
• Main scenario
• Alternative scenarios
• Exception scenarios
Documenting Scenarios
• There are different techniques for documenting scenarios
and use cases:
• Documentation of scenarios using natural language:
• Narrative scenarios, i.e. scenarios documented in natural language as
short narrations
• Structured scenarios (the tabular description of the interaction
sequences of scenarios, a reference template for the structured
documentation of scenarios, a reference template for the structured
documentation of use cases)
• Documentation of scenarios using model-based approaches:
• The utilization of UML sequence diagrams for documenting interaction
sequences of scenarios
• The utilization of UML activity diagrams for documenting the control
flows of scenarios and use cases
• Use case diagrams for documenting relationships between use cases
and between use cases and actors
Narrative Scenarios
• It documents a sequence of interactions using natural
language, in the form of short narration.
• Important for supporting the elicitation of knowledge about
the system and its context.
• They are comprehensible to all stakeholders.
Narrative Scenarios – Example [1]
The driver assistance system includes a (sub-)system for
avoiding rear-end collisions. The system comprises
distance sensors that permanently check the distance to
the vehicle driving ahead in order to avoid an imminent
rear-end collision. If the system detects that the distance
falls below the safety distance yet is still outside the critical
range, an acoustic warning signal sounds. Alternatively, a
symbol or message may be displayed on the driver display
in the cockpit of the car. If the driver has not reacted to the
warning after 2 s and the distance between the two cars
still decreases, the system reduces the speed of the car. If
the distance (in meters) falls below one quarter of the
driving speed (in km/h) at any time, the system initiates
emergency braking.
Structured Scenarios
• Structured scenarios improve the comprehensibility and
readability.
• The structured documentation of scenarios includes:
• Structured documentation of scenario steps
• Reference templates for scenarios
• Reference templates for use cases
Structured Documentation of Scenario
Steps
• There are two approaches for the structured textual
documentation of interaction sequences:
• The enumeration of scenario steps – Separates individual
interaction steps from each other and numbers them sequentially.
Each step must state at least the name of the actor.
• The tabular documentation of interaction sequences –
Individual steps are documented in separate cells of a table that
contains one column for each actor. They are numbered line by
line. Since actor is evident from the table, it doesn’t need to be
stated in the individual steps.
Structured Documentation of Scenario
Steps – Enumeration Example [1]
The driver activates the navigation system.
2. The navigation system determines the current position of the car.
3. The navigation system asks for the desired destination.
4. The driver enters the destination.
5. The navigation system identifies the relevant part of the map.
6. The navigation system displays the map of the destination area.
7. The navigation system asks for the routing options.
8. The driver selects the desired routing options.
9. The navigation system calculates the route.
10. The navigation system informs the driver that the route has been
calculated.
11. The navigation system creates a list of waypoints.
12. The navigation system displays the next waypoint of the calculated
route.
1.
Structured Documentation of Scenario
Steps – Tabular Example [1]
Driver
Navigation system
1. Activates the navigation system.
2. Determines the current position.
3. Asks for the destination.
4. Enters the destination.
5. Identifies the relevant part of the map.
6. Displays a map of the target area.
7. Asks for the routing options.
8. Enters the routing options.
9. Calculates the route.
10. Displays that the route has been calculated.
11. Creates a list of waypoints.
12. Displays the next waypoint.
Reference Template for Scenarios
No.
Section
Content/Explanation
1
Identifier
Unique identifier of the scenario
2
Name
Unique name of the scenario
3
Author
Names of the authors who have worked on the scenario description
4
Version
Current version number of the scenario
5
Change history
List of the changes applied to the scenario.
6
Priority
Indication of the importance of the described scenario
7
Criticality
Criticality of the scenario, e.g. for the success of the system
8
Source
Denomination of the source ([stakeholder | document | system]) from which the
scenario stems
9
Responsible
stakeholder
The stakeholder responsible for the scenario
10
Short description
Concise description of the scenario
11
Scenario type
Classification of the scenario
12
Goal(s)
Goal(s) that shall be satisfied by executing the scenario including identifiers
pointing to the associated goal definitions.
13
Actors
Indication of the primary actor and other actors
Reference Template for Scenarios (2)
No.
Section
Content/Explanation
14
Precondition
A list of necessary prerequisites that need to be fulfilled before the execution of
the scenario can be initiated
15
Postcondition
A list of conditions that hold after execution of the scenario
16
Result
Description of the outputs that are created during execution of the scenario
17
Scenario steps
Detailed interaction sequence of the scenario: narrative/sequentially
numbered/tabular
18
Qualities
Cross references to quality requirements
19
Relationships to
other scenarios
Relationships of the scenario to other scenarios
20
Supplementary
information
Additional information regarding this scenario
Reference Template for Use Cases
No.
Section
Content/Explanation
1
Identifier
Unique identifier of the use case
2
Name
Unique name of the use case
3
Author
Names of the authors who have worked on the use case description
4
Version
Current version number of the use case
5
Change history
List of the changes applied to the use case.
6
Priority
Indication of the importance of the described use case
7
Criticality
Criticality of the use case for the success of the system
8
Source
Denomination of the source ([stakeholder | document | system]) from which the
use case stems
9
Responsible
stakeholder
The stakeholder responsible for the use case
10
Short description
Concise description of the use case
11
Use case level
Characterization of the current level of detail of the use case
12
Goal(s)
Goal(s) that shall be satisfied by executing the use case scenarios including
identifiers pointing to the associated goal definitions.
13
Primary actor
Indication of the primary actor and other actors. Typically, the primary actor
initiates the execution of the use case.
Reference Template for Use Cases (2)
No.
Section
Content/Explanation
14
Other actors
Determination of all other actors involved in the use case
15
Precondition
A list of necessary prerequisites that need to be fulfilled before the execution of
the use case can be initiated
16
Postcondition
A list of conditions that hold after execution of the use case
17
Result
Description of the outputs that are created during execution of the use case
18
Main scenario
Description of the main scenario of a use case
19
Alternative
scenarios
Description of the alternative scenarios of the use case
20
Exception
scenarios
Description of exception scenarios of the use case
21
Qualities
Cross references to quality requirements
22
Relationships to
other use cases
Short description of the relationships of the sue case to other use cases
20
Supplementary
information
Additional information for this use case
Rules for Documenting Scenarios
• Use the present tense.
• Use the active voice.
• Use the subject-predicate-object sentence structure.
• Avoid modal verbs.
• Clearly separate each interaction from other interactions.
• Number each scenario step.
• Only one interaction sequence per scenario.
• Describe scenarios from the view of an outsider.
• Explicitly name the actors involved.
• Explicitly state the goal of the scenario.
• Focus on illustrating how the goal is satisfied by the
scenario.
Sequence Diagrams
• A sequence diagram documents a sequence of message
exchanges between a set of roles.
• Roles are shown as a vertical lines (lifelines) representing
the existence of the role over a period of time, while the
messages are modeled as a horizontal arrows between
lifelines.
Sequence Diagrams – Example [1]
Activity Diagrams
• Activity diagrams allow emphasis of the control flow
between multiple scenarios such as the scenarios of a
use case.
• The main focus of an activity diagram is the control flow,
i.e. the activities of the different actors and the possible
orders of these activities.
Activity Diagrams – Example [1]
Use Case Diagrams
• Use cases are suitable for documenting and visualizing
the relationships between the different use cases of a
system as well as the relationships between the actors
and the use cases.
• Modeling constructs in use case diagrams are:
• Actors – Systems or persons outside the system boundary that
•
•
•
•
interact with the system to be developed.
Use cases – A use case of the system to be developed.
System boundary – Delimits the system from its environment.
Relationships between actors and use cases – Expresses that
this actor interacts with the system during the execution of the use
case.
Relationships between use cases - Use cases can be related to
each other by different kinds of relationships.
Relationships Between Use Cases
• There are three types of relationships that can exist
between two use cases:
• Generalization – A generalization relationship from a use case A to
a use case B expresses that use case B is a generalization of use
case A. Use case A inherits the interaction steps contained in use
case B.
• Extend – An extend relationship from a use case A to a use case B
expresses that the interaction sequence contained in use case A
extends the interaction sequence documented in use case B.
• Include – An include relationship from a use case A to a use case
B expresses that use case A includes the interaction sequence
documented in use case B. It is used if two of more use cases have
a common part in their sequences of interactions. The common
part is extracted into a separate use case and included by the other
use cases.
Use Case Diagram Notation
Use Case Diagrams – Example [1]
References
1. K. Pohl: Requirements Engineering. Fundamentals,
Principles, and Techniques. Springer, 2010.
2. K. Pohl, P. Haumer: Modelling Contextual Information
about Scenarios. Presses Universitaires de Namur,
1997.
3. I. Jacobson, M. Christerson, P. Jonsson, G.
Oevergaard: Object-Oriented Software Engineering – A
Use Case Driven Approach. Addison-Wesley, 1992.
4. J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W.
Lorensen: Object-Oriented Modeling and Design.
Prentice Hall, 1991.