• Embed Doc
  • Readcast
  • Collections
  • CommentGo Back
Download
 
More notes available at: http://www.computer‐science‐notes.blogspot.com Page 1
Use Cases
Introduction
Means of capturing system functionality as seen by users
user-focusedtechnique
By recording all the ways the system can be used, we accumulate all therequirements for the system (e.g. software system or a business process)
Specify WHAT and not HOW
Identified in early stages of development by Analysts & domain experts
NOT an Object-Oriented technique BUT process driven
An informal and imprecise modeling technique
Actors
An external entity (person or other system) that interacts with the target system.
Actors can be:
o
Primary Actors: Actor using the system to achieve a goal but in aparticular role
o
Secondary Actors: Assist system to achieve the goal of primary actor.Often other system communicating with the target system
o
Abstract concepts, Date, Time
Identifying Actors 
Who starts up and shutdown the system?
Who will benefit from the use of the system?
Does system use any external resources?
Who will maintain the system?
Does anything happen automatically at the set time?
Use Cases
Represent goal (meaningful and measurable objective for primary actor;something of value) of an interaction between an actor and the target system
Pattern of behavior the system exhibits = Sequence of transactions betweenactor and system
Describe processes
Should be named in VERB-NOUN form
Should document the system behavior from user point of view
Is a complete sequence of steps that provides an actor with a result of value
 
More notes available at: http://www.computer‐science‐notes.blogspot.com Page 2
User-stories about functional requirements of a software system or businessprocess to be written from software or processes’ point of view; more preciselyfrom view of system user’s
Identifying Use Cases 
Talk to the user how/who will use the system
What are the tasks of each actor like how they behave with information in thesystem?
Will any actor need to inform the system about sudden external changes?
Does actor need to be informed about certain occurrence in the system?
What use-cases will maintain the system?
Use Case Diagrams
Created to visualize the (communicates) relationship between the actors anduse-cases
Navigation arrow shows who initiate the communication
Often, navigation direction is not shown
Show boundary of the target system
Advanced Use Case Relationships
Include (Uses Relationship): 
Shows behavior that is common to one or more use cases
Allows modeling ofre-use
Extract commonality to avoid duplicating effort
‘Included Use Case’ must be included by more than one use case as otherwisethere is no use
Communication
 
Association
 
More notes available at: http://www.computer‐science‐notes.blogspot.com Page 3
Use-case3(Sign Insurance Policy)<<include>><<include>>Use-case 1 use-case 2(Buy Car Insurance) (Buy Life Insurance)
Extend: 
Shows how a variant of behavior is possible on a mainstream use-case byextending it
May model optional behavior (seldom occurring alternate courses) like exceptionhandlingUse-case 1 (Sign car insurance contract)<<extend>>Use-case 2 (Sign insurance policy)When use-case 1 occurs, sometimes (but rarely) use-case 2 also occurs
Checking Use-Cases
Is use-case complete? Are there any details that need to be added?
Are there any procedural or requirement changes that would simplify the processdepicted in the use-case?
Are there any additional goals of actors that are not addressed?
of 00

Leave a Comment

You must be to leave a comment.
Submit
Characters: ...
You must be to leave a comment.
Submit
Characters: ...