Requirements Capture

using UML Use Cases

Venkat Srinivasan
Dept. of CSE
Saranathan college of Engineering, Trichy
 Contents
 Requirements Capture
 Building Blocks of a Use Case Diagram
 Actors
 Use Cases
 Relationships between Actors
 Relationships between Use Cases
 Terminology
 Flow of Events
 Scenarios
 Get more mileage from your Use Cases
 Use Case DOs and DON’Ts
veeyes -2-
 Requirements Collection
 “Requirements” are the raison-d-être of any
software development project
 Defines and delineates user-requirements
 Defines the functionality to be provided
 Identifies the goals to be achieved.
 Must be precisely and completely understood
by the team providing the solution
 User requirements (and team members) keep
changing; requirements must therefore be
well-documented
veeyes -3-
 Requirements Collection
 A thorough and unambiguous understanding
of the requirements is vital to ensure that
everyone knows what they are doing and why
 Must be reviewed, reviewed again and
reviewed yet again before the design and
implementation begins
 Involves the participation of domain-experts to
ensure that the requirements have been
correctly understood
 captures the “WHAT” of the problem-domain.

veeyes -4-
 Requirements Capture with UML
 Use Case Diagrams
 Captures the problem-domain in terms of
functionality to be provided (Use Cases), and
the “roles” (Actors) for whom these functions are
performed.
 An abstraction of the problem-domain and a
vehicle to facilitate a clear, well-articulated and
unambiguous understanding of the problem-
domain.

veeyes -5-
 Use Case
 Is an abstraction of a set of sequences that
yield some functionality.
 Represents some user-visible function.
 Is always initiated by an “actor”.
 Describes the interaction between the actors
and the system for a system function.
 Achieves a discrete goal for the actor.

Notation: Reserve Seat

veeyes -6-
 Finding Use Cases
 What functions does the system perform?
 What functions do the “actors” require?
 What input/output does the system need?
 What verbs are used to describe the system?
 The Reservation Clerk makes a booking using the
system, based on the...
 The Airport Manager can make an entry for a new
flight. He can also modify flight details, provided...

veeyes -7-
 Use Case - Example
Indian Railways provides for advance reservation on all
long-distance travel. The passenger seeking reservation
of berth or seats should purchase the tickets from
Railway Reservation Offices or Authorised Travel
Agency only. To make an advance booking, the
passenger is expected to fill in a prescribed application
form and submit it to the reservation counter with the
appropriate amount. Advanced Reservations are made
up to 60 days in advance for all trains, for all classes
exclusive of the day of departure of trains. An individual
can book only up to six passengers on one requisition
form provided all passengers are for the same
destination and for the same train.

veeyes -8-
 Use Case - Example (contd.)
Indian Railways wishes to develop a ticketing and reservation
system. This must support advance booking of tickets, cancellation
of tickets and change of class of a ticket. All these are handled by
a Reservation Clerk.
The system will also have a web-interface where users can
register themselves and purchase tickets online. They can pay
either by using their online banking account or by credit card or by
VPP. Reservations made over the internet can only be cancelled
across the counter.
The system will also have a querying facility that allows users to
check train time-tables, fares and availability of tickets.

veeyes -9-
 Use Case - Example (contd.)
Indian Railways wishes to develop a ticketing and reservation
system. This must support advance booking of tickets,
cancellation of tickets and change of class of a ticket. All these
are handled by a Reservation Clerk.
The system will also have a web-interface where users can
register themselves and purchase tickets online. They can pay
either by using their online banking account or by credit card or by
VPP. Reservations made over the internet can only be cancelled
across the counter.
The system will also have a querying facility that allows users to
check train time-tables, fares and availability of tickets.

veeyes - 10 -
 Use Case - Example (contd.)
Use Cases:

Make Cancel
Modify Class
Reservation Reservation

Query
Print Ticket Check Fare
Timetable

Register
as Member

veeyes - 11 -
 Purpose of Use Cases
 To capture functional requirements of a
system.
 To communicate with end users and domain
experts.
 To design test cases for validating system
functionality.
 To provide traceability from requirements
into actual classes and operations.
 To drive the development process.
 To plan iterations and releases

veeyes - 12 -
 Actors
 A role that interacts with the system.
 Represents a role, not individuals; can be a
person or a device or another system.
 Communicate with the system by sending
and/or receiving messages.
 An actor may participate in many use cases; a
use case may have several actors participating
in it.

Notation:
veeyes - 13 -
 Finding Actors
 Who uses the main functionality of the system?
 Which hardware devices the system needs to
handle?
 Which other systems does the system need to
interact with?
 What nouns/subjects are used to describe the
system?
 The Reservation Clerk makes a booking using the system,
based on the...
 A user must login in order to save his itinerary

veeyes - 14 -
 Actors - Example
Indian Railways wishes to develop a ticketing and
reservation system. This must support advance booking
of tickets, cancellation of tickets and change of class of
a ticket.
The system will also have a web-interface where users
can register themselves and purchase tickets online.

Actors:

Reservation Passenger
Clerk

veeyes - 15 -
 Use Case Diagram
 A graphical representation of the Use Cases of a
system, its actors, and the interaction between
them.
 It depicts the system boundary.
 Diagram Model elements
 Actors
 Use cases
 Relationships
• between Actors and Use Cases
• between Use Cases
• between Actors
veeyes - 16 -
 Use Case Diagram: Example
Modify Class

Check Fare

Query
Reservation Timetable
Passenger
Clerk
Make
Reservation

Cancel Register
Print Ticket
Reservation as Member

veeyes - 17 -
 Relationships between Use Cases
 Uses/Includes
 Extends

 “Extend” relationship : «extend»

 Use Case B extends Use Case A when Use Case B
describes the behaviour of Use Case A under a
particular condition.
 An extending Use Cases is used to describe variations
in the normal flow of events described by a general use
case

veeyes - 18 -
 Relationships between Use Cases
 “Include” relationship : «include»
 Use Case A uses (or “uses”) Use Case B when Use
Case B is a behaviour/functionality that is required by
Use Case A. That behaviour has been factored out into
a separate Use Case because it is required across
several use cases.
 Common behavior in several use cases can be factored
out into a single use case that is used by the other use
cases

veeyes - 19 -
«extend» and «include» : Example

Cancel Reservation
Reservation «include»
Clerk
Update
Seat Availability
«include»
Make Reservation
Factor out common
Passenger «extend» behaviour in a Use Case that
other Use Cases include.

Describe variations
from Normal Flow in a Generate Payment
extending Use Case Failure Notice
veeyes - 20 -
 Use Case Description
 Is a text description of the use case functionality
in the user language and terminology
 No specific UML format
 Describes WHAT and not HOW
 Typically includes:
 Objectives of the use case
 How the use case is initiated
 The flow of events
 Alternate flow in the use case
 How the use case finishes with a value to the actor
and more...

veeyes - 21 -
 Flow of Events
 Use Case is an abstraction of behaviour (set of
sequences).
 The behaviour of the Use Case can be described
by a “flow of events” - which spells out in detail
what exactly the Use Case does.
 Flow of events specifies:
 the main flow of events (what happens and in what order when
all is well).
 alternate flow(s) of events (what happens and in what order
when something goes wrong).

veeyes - 22 -
 Use Cases and Scenarios
 A Use Case actually describes a set of
sequences [of actions].
 Each sequence represents one possible flow
of actions in using the system.
 Each sequence is called a Scenario.
 A Scenario is basically one instance of a use
case.
 a Scenario is to a Use Case, what an Object is to a
Class.

veeyes - 23 -
 Use Case Description - Example
Use Case: Make Reservation
Actors: Passenger, Reservation Clerk
Purpose: Reserve a seat or berth
Overview: Allows the user to make a reservation for a
journey.
Normal Flow: 1. User logs in
2. User specifies the train and journey
details.
3. User specifies passenger details
4. User specifies payment details
5. User confirms transaction
Actual Use Case Description will vary in structure as well as content.
veeyes - 24 -
Steps in Use Case Modeling
 Establish the system boundary. Identify the
actors that use the system.
 For each actor, consider what functions the
system provides for each Actor.
 Represent each function as a Use case.
 Connect the Actor to all Use Cases initiated
by the Actor.
 If the Use Case requires participation by other
Actors, connect these actors also to the Use
Case.

veeyes - 25 -
 Steps in Use Case Modeling
 Factor optional or exceptional behavior in a
Use Case, into a separate Use Case and
connect this new Use Case with the main Use
Case with the «extend» relationship.
 Analyze all Use Cases and identify common
functions across groups of Use Cases. Factor
each such common function into a separate
Use Case and connect this common Use
Case with the other Use Cases that use it,
with the «include» relationship.

veeyes - 26 -
 Use Case Realization
 The use case diagram is an external view of
the system
 A use case is realized in a collaboration
 A collaboration shows an internal
implementation- dependent solution of a use
case in terms of:
 classes/objects
 their relationships
 their interaction

veeyes - 27 -
 Realization: Example
:UserInterface

1: parse(query)

2:optimise(postfix query)
:Parser :Optimiser

3: GenCode
(query tree)
Left Outer
:
Join Code
Generator
4: Execute(code)
:
:
Runtime
Database
Processor

veeyes - 28 -
 Use-Cases: Points to Ponder
 If I have a Use-Case that is associated with more than
one actor such that each actor has a different interest in
the same Use-Case, how do I model it?
 Model it as just one Use-Case in the top-level Use-Case Diagram.
Also examine the functionality encapsulated in the Use-Case to find
out whether some common behaviour can be factored out.
 Is it necessary to explicitly associate an actor in a
specialization with the Use-Cases that the super-type is
associated with?
 No; the generalization hierarchy implies that the specialized actor is
also associated with those Use-Cases

veeyes - 29 -
 Use-Cases: Points to Ponder
 Does every actor become a class?
 There is no such relationship. If some data/state of the actor needs to
be stored by the system, then the actor finds expression as a class.
 Is there any mapping between a Use-Case and a class
or set of classes?
 There is no direct mapping that can be established. However,
associated with each Use-Case is a Sequence Diagram and a
Collaboration Diagram. These model the classes and the interaction
between them.

veeyes - 30 -
 Getting more mileage...
 What are the different sections of a typical
Use Case description? What is the
significance of each?
 How does one use a Use Case to drive
development?
 Exactly where does the Use Case fit into the
development life-cycle?
 What other artefacts can one combine with a
Use Case to make it more effective?

veeyes - 31 -
 Use Case DOs
 Give a meaningful name to the Use Case
 Always use “business terminology” in the Use
Case - i.e., terms used by the client or by the
domain you are modeling
 Describe WHAT the functionality is about
 Document all relevant business rules and
processing logic (including validation
requirements)
 Strike a balance between the two ends of
possible granularities
veeyes - 32 -
 Use Case DON’Ts
 Don’t attempt to improvise on specific terms
used by the client - they almost always have
special significance
 Don’t make the Use Case a design document
- describe WHAT the business rule/validation
should be; not HOW it is to be implemented

veeyes - 33 -
 Summary
 Requirements elicitation is the stepping stone
to the project.
 Requirements must clearly and completely
understood by the entire project team.
 Must be reviewed for semantic correctness
and completeness.
 Requirements elicitation must focus on the
WHAT of the system and must be documented
in the user’s vocabulary.

veeyes - 34 -
 Summary
 Use Case Diagrams are the UML mechanism
for requirements capture.
 Use Case Diagrams are a graphical
presentation of the “actors” in the domain and
the “use cases” initiated by them.
 “Use cases” are abstractions of discrete
behaviour exhibited by the system; perform a
specific goal for an “actor”.
 An “actor” is an abstraction of a role played by
anyone or anything interacting with the system.

veeyes - 35 -
 Summary
 A use case is essentially a set of sequence of
actions. A specific sequence of this set of
sequences is called a “scenario”.
 A “scenario” is documented as “Flow of
Events”; each use case has a “main flow of
events” and “alternate flow of events”.
 Common behaviour across use cases can be
factored out and is then either
“used”/“included” or “extended” by other use
cases.

veeyes - 36 -
 Summary
 Recommendations for making Use Cases
more effective in the SDLC:
 Decide on the level of granularity for your Use Cases
 Create a screen design to accompany the Use Case
 Produce a “Form Definition Matrix” for “form-
heavy” or “form-driven” applications
 Walking a client/user through a Use Case by using the
screen to explain the system’s behaviour is an effective
way of getting requirements validated by the user.

veeyes - 37 -
 References
References
 The Unified Modeling Language
User Guide
Grady Booch, James Rumbaugh, Ivar Jacobson
Addison-Wesley (International Student Edition)

 The Unified Modeling Language

Reference Guide
Grady Booch, James Rumbaugh, Ivar Jacobson
Addison-Wesley (International Student Edition)

veeyes - 38 -
 References
References
 The Unified Software
Development Process
Grady Booch, James Rumbaugh, Ivar Jacobson
Pearson Education

 UML 1.5 Specification

http://www.omg.org

veeyes - 39 -