No: 1

USE CASES Use case

Way of using the system

No: 2

Objectives

• Identifying Actors• Defining System boundary• Identify and write use cases.• Draw use case diagrams.• Contrast high – level and expanded use cases.• Contrast essential and real use cases.

No: 3

Actor :

• An actor instance is someone or something outside the system that interacts with the system.

An actor class defines a set of actor instances, in which each actor instance plays the same role in relation to the system.

• An actor typically stimulates the system with input events, or receives something from it.

• Actors are represented by the “ role” they play in the use case, such as Customer, Manager,Cashier in Post system and so on.

No: 4How to Find Actors?

• The following set of questions is useful to have in mind when you are identifying actors:

Who will supply, use, or remove information?

Who will use this functionality?

Who is interested in a certain requirement?

Where in the organization is the system used?

Who will support and maintain the system?

What are the system’s external resources?

What other systems will need to interact with this one?

No: 5

Kinds of actors include:

• roles that users play• computer systems & software electrical or mechanical devices

Actors are usually the roles that humans play, but may be any kind of system also.

• External hardware like security card reader• Software like firewalls

External System as Actors:External System as Actors:

In Retail Store Domain Customer initiates the BuyItem UseCase Cashier and Electronic payment system are participating actors.

No: 6

Initiating Actor v/s Participating Actors:

For a use case, there is one initiator actor who generates the starting stimulus, and possibly several other participating actors; it is necessary to indicate “who is initiating”.

Participating actorInitiating actor

Example: In case of Departmental Sale System the customer initiate the sale by getting all the item to purchase and the Cashier uses the system to complete the Sale.

No: 7

Actors Help Define System Boundaries:

• Finding the actors also means that you establish the boundaries of the system, which helps in understanding the purpose and extent of the system.

• Example :

>> In an Departmental Stores if you consider Customer, Cashier, Manager etc. as actors then the system being developed will be Like a POST ( Point Of Sale Terminal )

>> In above case if you consider Customer only as actor then the system being developed will be STORE . Cashier, Manager are all the part of the STORE system.

POST as System

No: 8

Actors of POST :

• Customer

• Cashier

• Manager

• System Admin

No: 9

Introduction to Use Case:

An excellent technique to improve understanding of requirements is the creation of use case – narrative descriptions of domain processes.

Activities and Dependencies

Uses cases are dependent on having at least partial understanding of the requirements of the system, ideally expressed in a SRS [Software Requirements specifications] document.

No: 10

Use Cases:

• A use case is a narrative document that describes the sequence of events of an actor, using a system - to complete a specific process - that is written in the language of the domain

• They are stories or cases of using a system.

• Use case are not exactly requirements or functional specifications, but they illustrate and simplify requirements in the stories they tell.

No: 11

Use Cases are end - to - end Process:

A use case is a relatively large end – to – end process description

that typically includes many steps or transactions; it is not

normally an individual step or activity in a process.

Figure Depicts The UML icon for a use case.

Buy ItemBuy Item

BuyItem

No: 12

• A common error in identifying use cases is to represent individual step, operation, or transaction as a Use Cases.

For example: in the point – of – sale terminal domain, one may (inappropriately) define a use case called “Printing the Receipt” When in fact the printing operation is merely a step in the much larger use case process Buy Items

Common Error in identifying use cases:

No: 13

Prevent doing this….

It is possible to break down activities or portions of a use case into sub – use cases (called abstract use cases)

– even down -- to individual steps – but this is not the norm

No: 14

Use case Identification :

System

Use Case 1 Use Case 2

Actor based : Event based :

Each of steps for identifying use cases involves brainstormingand reviewing existing requirements specification documents.

Identify the actors related to a system or organization

For each actor, identify the processes they initiate or participate in.

Identity the external eventsthat a system must respond to.Relate the events to actors and use casesif necessary

No: 15

How to Find Use Cases ?

• Following is a set of questions that are useful when identifying use cases:

For each actor you have identified, what are the tasks in which the system would be involved?

Does the actor need to be informed about certain occurrences in the system?

Will the actor need to inform the system about sudden, external changes?

Does the system supply the business with the correct behavior? Can all features be performed by the use cases you have

identified? What use cases will support and maintain the system? What information must be modified or created in the system?

No: 16

The following are some example processes:

• Withdraw cash from an ATM• Order a product • Register for courses at school• Check the spelling of a document in a word processor • Handle a telephone call

Name a use case starting with a “verb” in order to emphasize that it is a process.

Naming Use Cases :

No: 17

Use Case Diagram :

use case diagram illustrates a set of use cases for a system, the actors, and the relation between the actors and use cases.

There are lines of communication between the use cases and actors; arrows can indicate flow of information or stimulus.

The purpose of the diagram is to present a kind of context by which one can quickly understand the external actors of a system and the key ways in which they use it.

Consists Of FollowingActorsUse casesCommunication Path ( Relationship )System Boundary

No: 18

Use Case Diagrams

Sample Use case diagram for bug tracking system :

No: 19

Use Case Formats :

• In practice, use cases may be expressed with varying degrees of detail and commitment to design decisions.

Use Case Formats :

Expanded Essential Use Case

High Level Use Case

Real Expanded Use Case

Analysis Design

No: 20

High – level Use Case Format :

Use case: Name of use case.

Actors: List of actors (external agents),

indicating who initiates the use case.

Type: 1. primary, secondary or optional

(to be discussed)

2. essential or real (to be discussed)

Cross Reference: Related use cases and system

functions.

Over view: summary of the scenarios involved

It is useful to start with high – level use cases to quickly obtain some understanding of the overall processes.

No: 21

High – level Format Discussion:

• A high – level use case describes a process very briefly, usually in two or three sentences.

• It is useful to create this type of use case during the initial requirements and project scoping in order to quickly understand the degree of complexity and functionality in a system.

• High level use cases are very brief, and vague on design decisions.

No: 22

Example : High level Use Case

Use case: Buy ItemsActors: Customer(initiator), CashierType: primary Cross Ref: R1.1,R1.2,R1.3,R1.7,R1.9,R2.2,R2.3,R2.4Description: A customer arrives at a checkout with

items purchase. The Cashier records the purchase items and collects payment. On completion, the Customer leaves with the items.

No: 23

Explaining the Expanded Format :

Use case: Name of use case.

Actors: List of actors (external agents),

indicating who initiates the use case.

Purpose: Intention of the use case.

Over view: Repetition of the high – level use

case, or some similar summary.

Type: 1. primary, secondary or optional

2. essential or real

Cross Reference: Related use cases and system

functions.

Typical course of events : Actors action | System response

: Alternate paths , sections

No: 24

Pictorial representation Flow of events :

Figure :

The typical structure of the flow of events. The straight arrow represents the basic flow of events, and the curves represent alternative paths in relation to the normal. Some alternative paths return to the basic flow of events, while others end the use case.

Alternate Path :•This, describes important alternative & exceptions that may arise with respect to the typical course of events.

•If complex, these alternatives may themselves be expanded into their own use cases.

No: 25

Guidelines for the contents of the flow of events are:

• Describe how the use case starts and ends

Describe what data is exchanged between the actor and the use case

Do not describe the details of the user interface, unless it is necessary to understand the behavior of the system

Describe the flow of events, not only the functionality. To enforce this, start every action with "When the actor ... "

Describe only the events that belong to the use case, and not what happens in other use cases or outside of the system

No: 26

Guidelines for the contents of the flow of events are:…..

Avoid vague terminology such as "for example", "etc. " and "information"

Detail the flow of events—all "whats" should be answered. Remember that test designers are to use this text to identify test cases.

• If you have used certain terms in other use cases, be sure to use the exact same terms in this use case, and that their intended meaning is the same

• To manage common terms, put them in a glossary

No: 27

Essential Expanded Format : POST

Section: MainUse case: Buy ItemsActors: Customer (initiator), CashierPurpose: Capture a sale and its payments.Overview: A Customer arrives at a checkout with items to

purchase. The Cashier records the purchase items and collects a payments, which may be authorized. On completion, the Customer leaves with the items.

Type: primary and essentialCross References: Functions: R1.1, R1.2, R1.3 R1.7, R1.9, R2.1,

R2.2, R2.3, R2.4

No: 28

Essential Expanded Format : POST

No: 29

Alternate Paths : POST

No: 30

High level use cases v/s expanded use cases

High level use cases• It is a very brief description of

scenarios involved in the use case.

Expanded Use cases• It is a detailed description

between the participants and system and system’s usage

• It contain Typical Course Of Events

• Alternative Course Of Events

Optionally :- High level & expanded Use case may contain Pre- condition and post condition.

Pre-condition:- condition that must be met before this use case be performed. Must be satisfied before the use case begins.Post-condition:- Condition of the system that is attained after this use case end. Refer to a state the system must be in after UseCase end.

No: 31Primary, Secondary, and Optional Use Cases

Need is to :- Prioritize their development.

• Primary use cases represent major common processes, such as Buy Items.

• Secondary Use cases represent minor or rare processes.

• Optional use cases represent processes that may not be tackled.

PrimaryUseCase

SecondaryUseCase

OptionalUseCase

UseCase category

No: 32

Essential versus Real Use Cases :

Use case degree of Design commitment

Essential Real very abstract Very concrete

Technology independent Technology dependent

Essential versus real cases exist on a continuum.

No: 33

Who all use Use Cases? & Why ?

• User & Development Team : Capture Requirements

• Technical Writers : as the basis for the user manual as Software & User-manual are directly based on the Use case

• Testing Group : as Use cases are basis for majority of text scripts

• Every member of Development team : uses Use cases for one reason or other .

• Remember : Use Cases are central artifact of the process and drives all other aspect of the process.

No: 34

Traceability, Use Cases and System Functions :

• Cross References section :- In addition, it should be possible, via the Cross References section of the use case, to verify that all functions have been allocated.This provides a important link in terms of traceability between the artifacts.

• The system functions identified during the prior requirements specifications should all be allocated to use cases.

• All system functions and System use should be traceable through to implementation and testing.

No: 35

The purpose of establishing traceability :

• To help:

Assess the project impact of a change in a requirement

Assess the impact of a failure of a test on requirements (i.e. if test fails the requirement may not be satisfied)

Manage the scope of the project

Verify that all requirements of the system are fulfilled by the implementation.

Verify that the application does only what it was intended to do.

Manage change. By

ATOIBy

ATOI