CMPT 275
Software Engineering
Requirements Analysis Phase
Requirements Analysis Activity
(use cases)
Janice Regan, 2008-2014
1
Class Project: Requirements Analysis
 Next you will proceed using use case
centered development (UCCD) to your
requirements model
 System Context Diagram
 Identifying Actors and developing Use Cases
 Primary classes
 Use cases and Scenarios (formal and informal)
 Use case Diagram
 Class (object) Diagram
 State Diagrams
Janice Regan, 2008-2014
2
Requirements Analysis Activity
Software
Developer
Client/User
Update SRS
Use Case Centered Development (UCCD)
Use Case
Diagram
Questions
Class
Diagram
Use Cases
Scenarios
Primary
Classes
System
Context
Diagram
State
Diagram
Janice Regan, 2008-2014
3
Actor
 Entity outside the software system
 interacts with the system
 Operates on objects in the system but cannot
be operated upon by objects in the system.
 Human, hardware device, another software
system
 Represents coherent role played by users
 e.g.: In an automated registration system
teacher, student, registrations data base
Janice Regan, 2008-2014
4
Actor
 A user of software system may take on
more than 1 role, usually at different
times
 e.g.: Eva interacts with the system not only
as a student actor but also as a teacher actor
 Eva teaches math, but is a student of French
 An actor may represent more than one
user
 e.g.: Both Eva and John may take the role of
a student
Janice Regan, 2008-2014
5
Primary and Secondary Actors
 Primary Actors
 Actors who initiate a scenario (use case)
causing the system to achieve a goal
 automated registration system example the
student or teacher is a primary actor
 Secondary Actors
 Actors supporting the system so primary users
goals can be completed (do not initiate the use
case or scenario)
 automated registration system example the
registration data base is a secondary actor
Janice Regan, 2008-2014
6
System Context Diagram: LMS
Show how the software system interacts with its environment
Librarian
Resources
(Books, CDs ..)
Patron
Web Libraries
Software System
Being created
Resource Information
Repository (DB)
Janice Regan, 2008-2014
Employee Information
Repository (DB)
Online Journals
Student Information
Repository (DB)
7
Use Cases
 Specify the behaviour of the system from the
user’s perspective
 Provides value to at least one user of the system
 Describe a sequence of actions, performed by
the system, to yield a result desired by that user
 The behavior of the system is expressed without
specifying how the behavior is implemented
(What is behavior, not how is it done)
 To get started generalize an informal scenario
(or closely related set of informal scenarios)

Informal scenarios are a good starting point
Janice Regan, 2008-2014
8
Use Case Format
A. Use Case Name (+ Functional
Requirement #s)
 Usually short active verb phrase related to
behavior modelled by the use case
B. Participating actors
C. Preconditions
 What conditions must be true at the beginning
of the use case?
D. Main flow of events
Janice Regan, 2008-2014
9
Use Case Format
D. Main flow of events
 Indicate how and when use case starts
 Describe the essential behavior associated with
the use case
E. Post conditions
 What occurs as a result of the use case
executing
 Describe state of system
F. Exceptional flow of events (zero to many)
 Enumerate possible erroneous flow of events
Janice Regan, 2008-2014
10
Building a use case

Start with your informal scenario for a basic function of the
system

As an example use the Check in resource case for the LMS,
using an example scenario illustrating the most common
case. (Book checked in, no extra problems)

Build a first draft of your use case based on this use case

Consider other related use cases, add the exceptional
conditions that may occur in related informal scenarios

Revise your use case to include actions needed to also
model the related informal scenarios.
Janice Regan, 2008-2014
11
Sample LMS use case: 1
A. Use case name: CheckInResource
(Functional Requirement #7)
B. Participating actors: Librarian and Patron
C. Preconditions
 Librarian and patron validated to LMS
 Library DB initialized
Janice Regan, 2008-2014
12
Sample LMS use case: 2
A. Main flow of events
 Librarian enters resource’s call number
 The status of the resource is changed to
"reshelve“
 Return date is reset
 Librarian indicates that he is done
Janice Regan, 2008-2014
13
Sample LMS use case: 3
E. Postconditions
 Patron DB entry updated to reflect returned
resource
 Resource DB entry updated to reflect changed
status: reshelve
F. Exceptional flow of events (some examples)
 Resource call number not valid
 Resource is overdue
 There is a hold on the resource
Janice Regan, 2008-2014
14
Building Use Cases
 Building your use cases is an iterative
process
 When you have a use case like the one we
just built read through it carefully and identify
exceptional (special) cases
 The exceptional cases we have identified are
shown in part F of the previous slide
 Determine what needs to be done in each of
these exceptional cases and add the
information to the use case
Janice Regan, 2008-2014
15
Revised Check in Use Case: 1
A. Use case name: CheckInResource
(Functional Requirement #7)
B. Participating actors: Librarian
(Patron does not directly interact with the
system so is not a participating actor unless
they are doing the check out themselves)
Janice Regan, 2008-2014
16
Revised Check in Use Case: 2
C. Preconditions:
 Librarian is a valid librarian
 LMS is ready to go (DB has been populated
and LMS has been initialized)
 Initial Option screen displayed
(your mock up should tell you what
information will be on the option screen)
D. Main flow of events:
 The use case starts when Librarian selects
CheckInResource option.
Janice Regan, 2008-2014
17
Revised Check in Use Case: 3
D. Main flow of events (cont):
 Librarian enters the Dewey call number for
the resource (HOW: either scan or type in #)
then checks and commits the entry (HOW: by
pressing the Enter key).
 The LMS checks that the Dewey call number
for the resource has been entered successfully
and it is valid (i.e., it does refer to a resource
of this library)
 The LMS finds the resource and finds its
borrower, then displays the resource and
patron information on the screen.
Janice Regan, 2008-2014
18
Revised Check in Use Case: 4
D. Main flow of events: (cont)
 The DetermineOverdueCharge use case is




initiated.
LMS verifies that there is no outstanding
request for this resource.
The LMS changes the status of the resource to
"reshelve" and cancels its "due date" and
"date of loan" and updates "date of return".
LMS updates the screen showing the newly
checked-in resource along with the updated
dates.
The use case terminates when Librarian
indicates that she/he is done.
Janice Regan, 2008-2014
19
Revised Check in Use Case: 5
E. Postconditions:
 Patron record updated to reflect the
newly checked in resource.
 Resource record updated to reflect its
checked in status and dates.
 Return to the initial Option screen.
Janice Regan, 2008-2014
20
Revised Check in Use Case: 6
F. Exceptional flow of events:
 Exceptional flow of events #1
 If the Dewey call number was entered
incorrectly, LMS states so and the use case
terminates.
 Exceptional flow of events #2
 If the Dewey call number entered is invalid
(does not exists in LMS DB), LMS states so
and the use case terminates.
Janice Regan, 2008-2014
21
Revised Check in Use Case: 7
F. Exceptional flow of events:
 Exceptional flow of events #3
 If there is an outstanding request for this
resource, LMS changes the status of the
resource to “requested“, cancels its "due
date" and "date of loan" (perhaps updates
"date of return"), updates the screen
showing the new state of the resource and
the use case terminates.
Janice Regan, 2008-2014
22
Building Use Cases
 Remember that building your use cases is
an iterative process
 When you have a use case like the one we
just built read through it carefully and look
for more possibilities
 E.G. what happens if the resource the patron
is trying to check in has not been checked out
 Add these additional possibilities and
integrate them into the use case.
 Continue iterating till you cannot see any
other possibilities
Janice Regan, 2008-2014
23
Characteristics of Use Cases
 Use cases are more abstract than
informal scenarios, because …
 A single use case may encompass
multiple informal scenarios
 Use cases avoid redundancy
 Use cases are more formally structured
than informal scenarios
 Use cases seek to capture complete
breadth of system behavior
Janice Regan, 2008-2014
24
Use case modeling
 Identify actors
 Define the scope of the system (context
diagram)
 Use scenarios, along with mock ups for visual
support, to help you validate requirements with
the client
 Build a set of use cases that encapsulates the
requirements

How do we verify that our use cases are complete,
consistent, and unambiguous? Use a use case diagram
Janice Regan, 2008-2014
25