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