Cornell

University
Compu1ng and Informa1on Science

CS 5150 So(ware Engineering
Scenarios and Use Cases


William Y. Arms
 Scenarios

Scenario
A scenario is a scene that illustrates some interac>on with a proposed
system.
A scenario is a tool used during requirements analysis to describe a
specic use of a proposed system. Scenarios capture the system, as
viewed from the outside, e.g., by a user, using specic examples.
Note on terminology
Some authors restrict the word "scenario" to refer to a user's total
interac>on with the system.
Other authors use the word "scenario" to refer to parts of the
interac>on.
In this course, the term is used with both meanings.
 Describing a Scenario

Some organiza>ons have complex documenta>on standards

for describing a scenario.
At the very least, the descrip>on should include:
A statement of the purpose of the scenario
The individual user or transac>on that is being followed
through the scenario
Assump>ons about equipment or so(ware
The steps of the scenario

3
 Developing a Scenario with a Client

Example of how to develop a scenario with a client

The requirements are being developed for a system that will enable
university students to take exams online from their own rooms using a
web browser.
Create a scenario for how a typical student interacts with the system.
In the next few slides, the ques7ons in blue are typical of the
ques7ons to ask the client while developing the scenario.
 Developing a Scenario with a Client:
a Typical Student
Purpose: Scenario that describes the use of an online Exam system by a
representa>ve student
Individual: [Who is a typical student?] Student A, senior at Cornell, major in
computer science. [Where can the student be located? Do other
universi7es dier?]
Equipment: Any computer with a supported browser. [Is there a list of
supported browsers? Are there any network restric7ons?]
Scenario:
1. Student A authen>cates. [How does a Cornell student authen7cate?]
2. Student A starts browser and types URL of Exam system. [How does the
student know the URL?]
3. Exam system displays list of op>ons. [Is the list tailored to the individual
user?]
 Developing a Scenario with a Client (con>nued)

4. Student A selects CS 1234 Exam 1.

5. A list of ques>ons is displayed, each marked to indicate whether
completed or not. [Can the ques7ons be answered in any order?]
6. Student A selects a ques>on and chooses whether to submit a new
answer or edit a previous answer. [Is it always possible to edit a
previous answer? Are there other op7ons?]
7. [What types of ques7on are there: text, mul7ple choice, etc.?] The
rst ques>on requires a wri]en answer. Student A is submi^ng a
new answer. The student has a choice whether to type the solu>on
into the browser or to a]ach a separate le. Student A decides to
a]ach a le. [What types of le are accepted?]
 Developing a Scenario with a Client (con>nued)

8. For the second ques>on, the student chooses to edit a previous answer.
Student A chooses to delete a solu>on previously typed into the browser,
and to replace it with an a]ached le. [Can the student edit a previous
answer, or must it always be replaced with a new answer?]
9. As an alterna>ve to comple>ng the en>re exam in a single session, Student
A decides to saves the completed ques>ons work to con>nue later. [Is this
always permiMed?]
10. Student A logs o.
11. Later Student A log in, nishes the exam, submits the answers, and logs
out. [Is this process any dierent from the ini7al work on this exam?]
12. The Student A has now completed the exam. The student selects an op>on
that submits the exam to the grading system. [What if the student has not
aMempted every ques7on? Is the grader no7ed?]
 Developing a Scenario with a Client (con>nued)

13. Student A now wishes to change a solu>on. The system does not
permit changes once the solu>on has been submi]ed. [Can the
student s7ll see the solu7ons?]
14. Later Student A logins in to check the grades. [When are grades
made available? How does the student know?]
15. Student A requests a regrade. [What are the policies? What are the
procedures?]
 Developing a Scenario with a Client (con>nued)

Developing a scenario with a client claries many func>onal

requirements that must be agreed before a system can be built, e.g.,
policies, procedures, etc.
The scenario will o(en clarify the requirements for the user interface,
but the design of the user interface should not be part of the scenario.
Although this scenario is quite simple, many details have been le( out.

9
 Scenarios for Analyzing Special Requirements

Scenarios are very useful for analyzing special requirements.

Examples
Reversals. In a nancial system, a transac>on is credited to the wrong
account. What sequence of steps are used to reverse the transac>on?
Errors. A mail order company has several copies of its inventory database.
What happens if they become inconsistent?
Malfeasance. In a vo>ng system, a voter has houses in two ci>es. What
happens if he a]empts to vote in both of them?
Scenarios for error recovery
Murphy's Law: "If anything can go wrong, it will". Create a scenario for
everything that can go wrong and how the system is expected to handle it.
 Modeling Scenarios as Use Cases

Models
Scenarios are useful in discussing a proposed system with a client,
but requirements need to be made more precise before a system is
fully understood.
This is the purpose of requirements modeling.
A use case provides such a model.

There is a good discussion of use cases in Wikipedia. The approach

used in this course is less complex than the Wikipedia ar7cle.
 Two Simple Use Cases

Borrow Book
BookBorrower

Record Pressure

PressureSensor

12
 Actor and Use Case Diagram

An actor is a user of a system in a

par>cular role.
BookBorrower An actor can be human or an external
system.


PressureSensor

A use case is a a task that an actor

Borrow Book needs to perform with the help of the
system.

Record Pressure
 Use Cases and Actors

Actor is role, not an individual

(e.g., librarian can have many roles)
Actor must be a beneciary of the use case
(e.g., not librarian who processes book when borrowed)
In naming actors, choose names that describe the role, not generic names,
such as "user" or "client".
 Use Cases for Exam System

Take Exam

ExamTaker
Check Grades

Request
Three separate Regrade
use cases
 Describing a Use Case

Some organiza>ons have complex documenta>on standards

for describing a use case.
At the very least, the descrip>on should include:
The name of the use case, which should summarize its
purpose
The actor or actors
The ow of events
Assump>ons about entry condi>ons

 Outline of Take Exam Use Case

Name of Use Case: Take Exam

Actor(s): ExamTaker
Flow of events:
1. ExamTaker connects to the Exam server.
2. Exam server checks whether ExamTaker is already authen>cated and
runs authen>ca>on process if necessary.
3. ExamTaker selects a exam from a list of op>ons.
4. ExamTaker repeatedly selects a ques>on and either types in a
solu>on, a]aches a le with a solu>on, edits a solu>on or a]aches a
replacement le.
 Outline Specica>on of Use Case (con>nued)

Flow of events (con>nued):

5. ExamTaker either submits completed exam or saves current state.
6. When a completed exam is submi]ed, Exam server checks that all ques>ons
have been a]empted and either sends acknowledgement to ExamTaker, or
saves current state and no>es ExamTaker of incomplete submission.
7. ExamTaker logs out.
Entry condi>ons:
1. ExamTaker must have authen>ca>on creden>als.
2. Compu>ng requirements: supported browser.
 Use Cases for Exam System (con>nued)

Set Exam

Instructor
Grade
Note that actor is a role. An
individual can be an ExamTaker
on one occasion and an
Instructor at a dierent >me. Regrade
 Rela>onships Between Use Cases: <<includes>>

Take Exam <<includes>>

Authen>cate

ExamTaker Check Grades <<includes>>

The Authen>cate use case may be

used in other contexts
 Rela>onships Between Use Cases: <<extends>>

<<extends>> Connec>on
Fails
ExamTaker Take Exam

<<includes>> is used for use cases that are in the ow of events of the
main use case.
<<extends>> is used for excep>onal condi>ons, especially those that
can occur at any >me.
Scenarios and Use Cases in the Development Cycle

Scenarios and use cases are both intui>ve -- easy to discuss with
clients
Scenarios are a tool for requirements analysis.
They are useful to validate use cases and in checking the
design of a system.
They can be used as test cases for acceptance tes>ng.
Use cases are a tool for modeling requirements.
A set of use cases can provide a framework for the
requirements specica>on.
Use cases are the basis for system and program design, but are
o(en hard to translate into class models

 Use Cases with Several Actors

<<includes>>
Order Food Order Wine
Waiter

Serve Food

Chef
Diner Cook Food
Eat Food

Pay for Food

Cashier

This restaurant example is based on a use case diagram from Wikipedia.

 Use Case Diagrams

Use case diagrams

A use case diagram shows the rela1onships between actors and
and their interac>ons with a system.
It does not show the logic of those interac>ons.

24
 An Old Examina>on Ques>on

The Pizza Ordering System

The Pizza Ordering System allows the user of a web browser to order
pizza for home delivery. To place an order, a shopper searches to nd
items to purchase, adds items one at a 7me to a shopping cart, and
possibly searches again for more items.
When all items have been chosen, the shopper provides a delivery
address. If not paying with cash, the shopper also provides credit card
informa7on.
The system has an op7on for shoppers to register with the pizza shop.
They can then save their name and address informa7on, so that they do
not have to enter this informa7on every 7me that they place an order.
Develop a use case diagram, for a use case for placing an order, PlaceOrder.
The use case should show a rela>onship to two previously specied use
cases, Iden7fyCustomer, which allows a user to register and log in, and
PaybyCredit, which models credit card payments.
 An Old Examina>on Ques>on

Correct solu1on
<<includes>>
PaybyCredit
PlaceOrder

<<includes>>
Shopper

Is link is
op>onal Iden>fyCustomer
 An Old Examina>on Ques>on

Wrong Solu1on
SearchMenu

AddtoCart

Pay <<includes>>

Shopper
PaybyCredit

<<includes>>
Iden>fyCustomer