Requirements Capture using UML Use Cases

Requirements Capture using UML Use Cases

Venkat Srinivasan

Dept. of CSE

Saranathan college of Engineering, Trichy

veeyes - 2 -

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 - 3 -

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 - 4 -

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 - 5 -

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 - 6 -

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 - 7 -

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 - 8 -

Use Case - ExampleIndian 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 - 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.)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 - 11 -

Use Case - Example (contd.)

Make Reservation

CancelReservation

Modify Class

Print Ticket

Use Cases:

Query Timetable

Check Fare

Register as Member

veeyes - 12 -

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 - 13 -

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 - 14 -

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 - 15 -

Actors - ExampleIndian 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 Clerk

Passenger

veeyes - 16 -

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 - 17 -

Use Case Diagram: Example

Reservation Clerk

Passenger

Make Reservation

Modify Class

Print Ticket

Query Timetable

Check Fare

CancelReservation

Register as Member

veeyes - 18 -

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 - 19 -

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 - 20 -

«extend» and «include» : Example

Reservation Clerk

Passenger

Make Reservation

Cancel Reservation

Update Seat Availability

«include»

«include»

Generate PaymentFailure Notice

«extend»Factor out common

behaviour in a Use Case that other Use Cases include.

Describe variations from Normal Flow in a extending Use Case

veeyes - 21 -

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 - 22 -

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 - 23 -

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 - 24 -

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 in2. 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 - 25 -

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 - 26 -

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 - 27 -

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 - 28 -

Realization: Example

Left Outer Join

:UserInterface

:Parser

: Code Generator

:Optimiser

1: parse(query)

2:optimise(postfix query)

3: GenCode (query tree)

: Runtime Processor

4: Execute(code)

: Database

veeyes - 29 -

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 - 30 -

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 - 31 -

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 - 32 -

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 - 33 -

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 - 34 -

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 - 35 -

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 - 36 -

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 - 37 -

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 - 38 -

ReferencesReferencesReferencesReferences

The Unified Modeling Language User GuideGrady Booch, James Rumbaugh, Ivar JacobsonAddison-Wesley (International Student Edition)

The Unified Modeling Language Reference GuideGrady Booch, James Rumbaugh, Ivar JacobsonAddison-Wesley (International Student Edition)

veeyes - 39 -

ReferencesReferencesReferencesReferences

The Unified Software Development ProcessGrady Booch, James Rumbaugh, Ivar JacobsonPearson Education

UML 1.5 Specificationhttp://www.omg.org