Systems Analysis II Use Cases

1
Systems Analysis IIUse Cases

• INFO 355
• Glenn Booker

2
Use Cases

• As part of the activity to define functional
  requirements, we can capture those requirements
  in use cases
• A use case is an activity the system performs,
  usually in response to a request by the user
  (text, 69)

3
Use Cases and OO

• Though use cases are often associated with object
  oriented analysis, use cases are not object
  oriented
• They could be used to help capture functional
  requirements for any type of system

4
Finding use cases

• Two methods (at least) for finding use cases for
  a system
• User goal technique
• Event decomposition technique
• To validate a draft list of use cases, the CRUD
  technique can be used

5
User goal technique

• The main idea behind this technique is to
  identify the types of users of a system, then
  determine what goals or assigned tasks each type
  of user has when using the system
• Those goals often correspond to use cases

6
User goal technique

• The user goal technique is
• Identify all potential users for a system
• (Optional) Classify users by functional role
  (shipping, marketing, sales) and operational
  level (operational, management, executive)
• Interview each user and determine what goals they
  have when using the system

7
User goal technique

• Make a preliminary list of use cases for each
  type of user
• Look for duplicates and inconsistencies across
  users
• Identify when multiple users need the same use
  case
• Review completed list with users and other
  stakeholders for validation

8
Event Decomposition

• This approach looks for all events that would
  lead to the information system being used
• Each event typically leads to a use case
• Simplify events to ones that have a clearly
  defined start and end, and achieve a clear
  business purpose
• Those are Elementary Business Processes (EBPs)
  use cases

9
Event Decomposition

• Focusing on events keeps attention on the macro
  scale purpose of the system, not internal details
• Events can be
• External caused by an actor
• Temporal done at fixed time intervals
• State triggered by an internal condition, e.g.
  low inventory

10
Event Decomposition

• Focus on events that directly cause the system to
  be used
• Not prior conditions that are invisible to the
  system
• Many important business processes do not involve
  the system directly!
• Avoid trivial use cases (logging on) but DO
  include system controls (admin functions such as
  backup)

The last point differs from the text!
11
Event Decomposition

• The event decomposition process is
• Identify relevant external events
• For each, name a use case
• Identify relevant temporal events
• For each, name a use case and define when it
  occurs
• Identify relevant state events
• For each, name a use case
• Omit trivial use cases, but keep system controls

12
CRUD technique

• Use this technique for verifying an existing list
  of use cases
• Recall CRUD create, read, update, or delete
  data
• The goal of this technique is to verify at least
  one use case has been identified to perform all
  relevant aspects of CRUD
• Relevant aspects?

13
CRUD technique steps

• Identify major data entities for your system
• For each, verify that at least one use case does
  each of CRUD, as appropriate to your system
• Add use cases if needed
• Make sure data ownership is clear if more than
  one application interacts

14
Naming use cases

• Give use cases a short name (2-4 words), starting
  with an action verb
• Track shipment
• Create new user
• Produce monthly sales report
• The reason for brevity is so we can put them on a
  use case diagram

15
Use Case Diagram

• A use case diagram summarizes all the major use
  cases for a system
• To define a use case diagram, need
• List of Use Cases
• Actors
• External Systems (if any)
• System Boundary (automation boundary)

16
Actors

• Actors are types of users of the system the
  role of someone who uses the system
• Actors must interact directly with the system
• Interaction could be through any mechanism
  keyboard, mouse, touch screen, card reader,
  voice, biometric,

17
Actors

• Examples of actors include
• Customer/Client/Patient/Patron/Donor/Subscriber
  (if they interact directly)
• Manager (should be more specific)
• System Administrator
• Clerk
• Foreman

18
External Systems

• External systems are any non-human (generally
  computerized) actor which your system needs to
  perform one or more use cases
• Can be a Timer, to initiate automatically
  repeating use cases
• Are systems you dont control, and are outside
  the scope of your system development

19
External Systems

• Could include systems owned by vendors
• E.g. a service to maintain your online catalog
• Could be a custom legacy system which isnt being
  replaced
• E.g. an existing human resource system, or
  accounting system

20
System Boundary

• The use case diagram includes a box to show the
  boundaries of your system
• Actors are not within the boundary
• External systems are not within the boundary
• Box is labeled with your systems name (not just
  System)
• The use case diagram acts like a context diagram

21
Naming Use Cases

• Each use case should have a brief name, typically
  2-4 words
• Start with a verb, and end with a noun
• Cancel Customer Order
• Place Order
• Validate New Customer
• Number use cases sequentially

?
22
Use Case Diagram Notation

• Actors are represented by stick people, with
  their role below them
• Use cases are represented by ovals
• External systems are represented by rectangles,
  with ltltactorgtgt before the system name
• ltltactorgtgt is a stereotype
• The ltlt gtgt should be guillemets

23
Sample Use Case Diagram
Tip Straight lines are easier to use!
24
Use Case Diagram Notation

• Lines connect actors to the use cases they can
  perform
• Hence a major purpose of the use case diagram is
  to show what functions the system can perform,
  and who can use them
• Notice there is no indication of when use cases
  are performed, or any of the logic behind them

25
Generalization

• A common concept for the use case diagram is when
  one actor has some special use cases, but also
  can do everything some other actors can
• A manager or supervisor can do everything their
  staff can do, plus additional functions
• Show this using generalization

26
Generalization

• Notice the triangle at the top of the line
  between Manager and Staff
• This means that Manager inherits all use cases
  which Staff can do
• (Also can use generalization in Class diagrams)
• Helps keep use case diagram simpler and easier to
  read

27
Included Use Cases

• When documenting use cases, might find a clear
  set of activities that appears in two or more
  use cases
• Can pull those activities out and make that an
  included use case
• In Visio, lines to an included use case have the
  stereotype ltltusesgtgt
• In other applications, stereotype is
  ltltincludesgtgt

28
Included Use Cases

• The included use case is documented separately
  from the use cases which use it

Use case numbering and system boundary omitted
29
Subsystem use case diagram

• Ideally all actors and use cases should fit on
  one diagram
• If not, its ok to have a separate use case
  diagram for each major subsystem
• Specify whether the diagram includes all users
  (preferred) or a limited subset of them

30
Documenting Use Cases

• Use cases can be documented to varying levels of
  detail
• Well define two of them
• Casual use case documentation
• Detailed use case documentation
• These are local terms for the level of
  documentation, not Cockburns
• (thats pronounced CO-burn)
• The text uses Brief and Fully developed

31
Casual Use Case Documentation

• Consists of
• Use case number and name
• Objective A sentence to elaborate on the main
  purpose of the use case
• Primary Actor what actor initiates the use case
• Main Success Scenario a step-by-step
  description of the events which should occur
  during this use case

32
Detailed Use Case Documentation

• Consists of
• Use case number and name
• Objective
• Primary Actor
• Secondary Actor(s) other actors who play a
  significant role in this use case
• Trigger what event forces the start of this use
  case?
• Main Success Scenario (MSS)

33
Detailed Use Case Documentation

• Extensions when performing the MSS, what other
  events could occur?
• Extensions often include alternate methods of
  processing, different ways to do the same thing,
  and error conditions
• Performance time how long it should typically
  take to perform this use case
• Frequency how often will this use case be
  performed?
• Open Issues for scope issues, if any

34
Beyond Detailed

• The MSS and/or extensions should cite included
  use cases, where appropriate
• Additional documentation is possible beyond the
  detailed template just given see Cockburns site

35
Main Success Scenario

• The Main Success Scenario describes the
  interaction between actors and the system in
  order to perform a use case
• They are critical to write well, since later
  documentation depends upon them (e.g. sequence
  diagrams)
• See Summary of UML Diagrams handout for details
  on MSS writing

36
Main Success Scenario

• Where to begin?
• For most use cases, you can assume the actor has
  logged into the system (if needed) and are
  starting at the applications Main Menu or its
  equivalent
• A MSS describes a use case in more detail than
  you would typically consider necessary

37
Main Success Scenario

• The MSS describes the most common way a use case
  will be performed successfully
• If there are multiple processing options, pick
  the most frequent one for the MSS, and describe
  the rest in the Extensions
• In the MSS, assume all actions will be
  successful describe how to handle unsuccessful
  outcomes in the Extensions
• The MSS is the Disney version of the use case
• Extensions are the Tim Burton version

38
Main Success Scenario

• Typical actor activities in a MSS are
• Navigate through the interface to a defined
  objective
• Shipping clerk navigates to the New Shipment
  Screen.
• Notice we didnt say HOW they navigate, just that
  its accomplished somehow
• Enter data onto an interface
• Shipping clerk enters the data for a new
  shipment.
• Notice every field entered is not specified

39
Main Success Scenario

• Describe when an actor selects something on an
  interface
• Dispatch manager selects the number of drivers
  needed.
• Indicate when an actor completes an activity,
  such as by submitting data
• Shipping clerk submits the new shipment data.
• This prompts the system to do something with the
  data

40
Main Success Scenario

• The only remaining type of actor action is to
  exit the application, which often isnt part of a
  MSS (assume you can always cancel or exit from
  the system)
• So there are few types of things an actor might
  do during a MSS
• System actions can be much more complex

41
Main Success Scenario

• Typical system actions include
• Create a new interface screen
• System displays Define Shipment screen.
• Change or update the contents of an existing
  screen
• System updates the screen to show the list of
  artifacts.

42
Main Success Scenario

• Communicate with an external system
• System gets current stock price from NYSE.
• System emails drivers with shipment info.
• Perform an included use case
• System performs Validate Credit Card use case.
• Perform background processing
• System validates new customer data.
• System computes the sales tax.

43
Main Success Scenario

• Notice that the MSS includes steps which arent
  visible to the actors!
• Other background processing might include
• System prioritizes the list of drivers.
• System produces weekly sales summary.
• Background processing can include any activity
  needed to prepare data for presenting the results
  to the actor

44
Main Success Scenario

• Finally, make sure a MSS achieves the overall
  objective of the use case!
• System saves new customer data.
• System updates order status.
• System deletes completed orders.
• These steps are typically performing one of the
  CRUD functions

45
Main Success Scenario

• Writing a MSS might involve making assumptions
  about where or how data is stored
• Can assume there is a place that stores Customer
  Data, or Shipment Data, etc.
• External systems should be labeled consistently
  throughout the design
• Can name interfaces (New Customer Screen), but
  dont design them (click on the submit button
  no!)

46
Main Success Scenario

• Throughout a MSS, look for actions which need to
  be repeated
• Specify in generic terms how many times steps
  need to be repeated
• For each book to be checked out,
• For each driver assigned to a shipment,
• Repeat five times, or until login is successful

47
Extensions

• Extensions, or alternate scenarios, handle when
  something doesnt go normally during a use case
• Extensions are numbered, starting with the MSS
  step from which they depart
• If an extension starts from step 5, the first
  extension is a condition called 5.a
• Then the steps to respond to that condition are
  5.a.1, 5.a.2, etc.
• A second extension from step 5 is condition 5.b
  and has steps 5.b.1, 5.b.2, 5.b.3, etc.

48
Extensions Handle

• So the lettered step (5.a) describes the
  condition under which you perform that extension
• And the steps under it (5.a.1, 5.a.2, ) are the
  actor and system actions that follow
• Optional processing steps can be an extension
  the rest of the MSS isnt affected if they
  arent used
• Adding sales tax to an order
• Adding gift wrapping to an order

49
Extensions Handle

• Failure conditions when a MSS step cant be
  performed successfully
• If a search yields no results
• If payment is insufficient
• Cant connect to an external system
• Alternate processing when a MSS step can be
  processed differently
• Handle domestic versus international orders
• Handle different forms of payment

50
Extensions

• Assume that interfaces and data transactions
  inside your system are successful, and wont
  result in an extension, e.g.
• Saving or reading data locally
• Creating or updating interfaces
• Otherwise every system step could be an extension!