CMPT 275
Software Engineering
Requirements Analysis activity
(use case diagrams, Class activity)
Janice Regan, 2008-2014
1
Class Project: Requirements Analysis
 Object Oriented paradigm
 Requirements Gathering Activity: Develop
informal scenarios to help you derive your
software requirements specifications
 Requirement specification Activity: Build an
‘analysis model’ representing the user’s/client’s
view of the system

‘analysis model’ includes a list of functional and nonfunctional requirements. Each functional requirement
represent all or part of at least one function/activity

Functional requirements are not dependent on specific
methods of implementation
Janice Regan, 2008-2014
2
Class Project: Requirements Analysis
 Next you will proceed using use case
centered development (UCCD) to analyze
that model
 System Context Diagram
 Identifying Actors and developing Use Cases
 Use case Diagrams
 Primary classes
 Use cases and Scenarios (formal and informal)
 Class (object) Diagram
 State Diagrams
Janice Regan, 2008-2014
3
Requirements
Analysis
Activities
Software
Client/User
Developer
Update SRS
Use Case Centered Development (UCCD)
Use Case
Diagram
Questions
Class
Diagram
Scenarios
Use Cases
Primary
Classes
System
Context
Diagram
State
Diagram
Janice Regan, 2008-2014
4
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
5
UML: Unified Modeling Language
 Object-Oriented Paradigm modelling
notation
 Clear and effective way to model many
aspects of a software system using a
commonly understood language
 Programming language independent
 Enables a variety or analysis and design
techniques
 A subset of UML will be used in this course
Janice Regan, 2008-2014
6
UML: Unified Modeling Language
 Used in this course for analysis models of
 System functionality (use case diagrams, use
cases and scenarios)
 Objects and their static relationships (class
diagrams)
 Dynamic behavior (state diagrams,
collaboration diagrams sequence diagrams)
Janice Regan, 2008-2014
7
Use Case Diagrams
 Depicts overall behavior of s/w system
 Models the context of a system (what is
part of the system what external entities
interact with the system)
AND
 Models the requirements of a system, the
desired behavior of the system (what the
system should do from an external
viewpoint, not how it should do it)
Janice Regan, 2008-2014
8
Use Case Diagrams
 Depicts overall behavior of software
system
 Depicts interaction between
 use cases and actors
 use cases and use cases
 actors and actors
 Depicts a set of use cases, a set of
actors, and the relationships between the
use cases and actors
Janice Regan, 2008-2014
9
UML: Use Case Diagrams
Actor
Use case
Use case
name
Relationships:
Dependency
(extension and inclusion)
Janice Regan, 2008-2014
Association
Generalization
(communication)
10
Use Case Diagrams
 Relation between actor and use case is a
communication if
 Actor initiates use case
 Actor supplies information to use case
 Actor receives information from use case
 Use case initiates another use case
Use Case
Janice Regan, 2008-2014
Part of Use Case
Diagram: Shows
Communication
11
Relationships: Dependency
 Dependency: Class A is said to depend on
class B if
 A uses at least one feature of B, e.g., it
accesses one of B’s data fields or invokes one
of its methods.
 Changing the specification of B may change A
(A uses or depends on B) but not necessarily
the reverse
A
Janice Regan, 2008-2014
B
12
Use Case Diagrams
 Dependency Relationship: <<include>>
 Encapsulates common logic required by
several use cases into one included use case
 Used for factoring out common behaviour
(promote “reuse”)
 Can also be used to break a large and
complicated used case into smaller more
manageable parts
Source Use Case
or Base Use Case
Janice Regan, 2008-2014
<<include>>
inclusion use case
or target use case
13
Use Case Diagrams
 Dependency Relationship: <<include>>
Make Meat Pie
Make Apple Pie
<<include>>
<<include>>
Make Pie Crust
<<include>>
Make Cherry Pie
Janice Regan, 2008-2014
14
LMS: Partial Use Case Diagram
BrowseResource
Check out resource
<<include>>
Verify Patron
ReserveResource <<include>>
Patron
CheckInResource
<<include>>
Determine Overdue
Charge
Janice Regan, 2008-2014
Librarian
15
Use Case Diagrams
 Dependency Relationship: <<extend>>
 Extension use case defines logic that may be
required during a base use case
 Exceptional logic that is not always needed
 Can be a conditionally executed separate
subflow (label with condition)
 One of several possible flows that may be
inserted at a given point governed by
interaction with the actor
Janice Regan, 2008-2014
16
Use Case Diagrams
 Dependency Relationship: <<extend>>
 Source use case extends the behavior of the
target use case
 Allows options to be extension cases
Source Use Case
or Extension Use Case
Janice Regan, 2008-2014
<<extend>>
Target Use Case
Or Base Use Case
17
Use Case Diagrams
 Dependency Relationship: <<extend>>
Make optional cherry
crème topping
<<extend>>
Make cherry
pie
<<extend>>
Baking in Microwave
<<extend>>
Baking in Convection oven
Janice Regan, 2008-2014
18
Use Case: overlapping roles
(good practice indicates 1 initiating actor per use case)
Recording Grades
Design Course
Regular Faculty
Record Grades
Registrar
Sessional Lecturer
Janice Regan, 2008-2014
19
Relationship
 Generalization: book, music CD, videos
are resources
Resource
general
specific
Book
Janice Regan, 2008-2014
Video
Music CD
20
Use Case: overlapping roles
(1 initiating actor per use case)
Recording Grades
Instructor
Record Grades
Registrar
Design Course
Sessional
Lecturer
Regular
Lecturer
Janice Regan, 2008-2014
21
Modeling the context of a system
From: Booch, Rumbaugh, Jacobson
Credit Card Validation System
Perform Transaction
Customer
Retail
Institution
Process Customer
Bill
Reconcile
Transactions
Individual Corporate
Customer Customer
Janice Regan, 2008-2014
Manage Customer
Account
Financial
Institution
22
Constructing a Use Case Diagram
 Identify all actors (primary and secondary)
 For each actor
 Identify each function the actor expects from
the system (can consider the whole system or a
few requirements at a time)
 Name each of these functions, and consider it to
be a use case
Janice Regan, 2008-2014
23
Constructing a Use Case Diagram
 Analyze the use cases
 Determine which actor (one only) or which use
case initiates each use case
 Find any actions common to multiple use cases.

Use the <<include>> dependency to connect the use
case for the common action to the original use cases
 Find any actions that are done rarely/sometimes

Use the <<extend>> dependency to factor out use
cases that are extensions
Janice Regan, 2008-2014
24
Validation & Verification
 Validation
 Are we building the right product?
 To facilitate validation we number our
functional requirements and propagate these
numbers throughout our models and source
code, validating that all functional
requirements are parts of the system.
 Verification:
 Are we building the product right?
Janice Regan, 2008-2014
25