Use Cases

1

• Use Cases

2
Use-Cases an Example
3
Using use cases to describe requirements

• Use cases can show the sets of possible
  interactions between the system and the people
  who use it
• Use cases can also show interactions between
  computer systems
• Use cases can also be used at the subsystem level
  (to show interactions between subsystems)

Example use case diagram
My system
register
create new course
delete offering
actors
use cases
4
What is Requirements Engineering About?

• Effectively generating High Quality Requirements
  

• modifiable
• traceable
• verifiable

• non-ambiguous
• understandable
• annotated

• correct
• consistent
• complete

Requirements Engineering
Requirements Management
Requirements Development
Change Control
Version Control
Tracing Impact Analysis
Status Tracking
Best Practices, Methods,Tools and Processes for
Requirements Engineering
5
Use Cases Early Testing Paradigm
Requirements Validation Quality
Assurance Faster Time to Market
System Test
Requirements
System Design
Integration Test
Detailed Design
Module Test
Implementation
Build
6
Software Production Cycle
Design Specifications Models
Code Creation
Documentation
Design Specification (Design Model Generation)
Design Tools
Build
Code
SDE, SCM Tools
Documentation
Build-triggered Installation
Change Requests
Change Request
Requirements Tools Capture with Customers
Shipped Product
Requirements validation
Testable version
Test Plans, Scenarios, Cases
Test Execution
Test Creation
Test Tools
Traceability, Change Management, Impact Analysis
7
What is a Use Case?

• A Use Case captures a contract between the
  stakeholders of a system about its behavior. Use
  cases describes the systems behavior under
  various conditions as the system responds to
  requests from its users (actors) specifying how
  the actors goals get delivered or fail.
• A use case is
• a set of scenarios that describe the behavior of
  the system and its users
• at a high level of detail
• with sunny-day and rainy-day scenarios being
  defined
• A use case gathers the scenarios related to the
  (primary) actors goal
• Actors are the people and/or computer systems
  that are outside the system under development
  (SuD)and interact with it
• Primary actor a stakeholder who requests that
  the system deliver a goal
• Supporting/secondary actor an external system
  against which the SuD has a goal
• Scenarios are dialogs between actors and the
  system

8
What is a Use Case?

• A Use Case is
• a set of scenarios that describe the behavior (or
  desired behavior) of a system and its users
• at a superficial level of detail
• with sunny-day and rainy-day scenarios
• with some generalization of the roles and
  activities
• A Use Case is the set of scenarios that provides
  positive value to one or more external actors
• actors are the people and/or computer systems
  that are outside the system under development
• scenarios are dialogs between actors and the
  system
• no information about the internal design

9
Use-Case (Cont.)

• A use-case is
• a set of activities within a system
• presented from the point of view of the
  associated actors
• leading to an externally visible result
• a (simplified) part of a business process model
• WHAT is the system supposed to do
• not for functional decomposition
• simplified and limited graphical notation
• other diagrams and text templates used to support
  it
• combined with prototypes

10
Actors

• An actor is an entity that is outside of the
  system
• Actors will interact with the system
• an actor will often request the system to perform
  some actions on behalf of the actor
• an actor may also receive responses from the
  system
• An actor plays a role in the use of the system
• the name given to an actor is usually the role
  name for example, an actor who is a Person
  will usually be called a User, Operator,
  Administrator, or something like that
• each role might be treated as a different actor
  in the use cases

11
More on Actors

• Actor, entity, control, boundary, source/sink,
  ...
• An actor is
• a class that forms a system boundary,
• participates in a use-case,
• but is not within our responsibility as systems
  analyst/designer
• Examples are
• end-user (roles)
• external systems
• time related events
• external, passive objects (entities)
• Actor types
• Primary a stakeholder that calls on the system
  to deliver one of its services
• Secondary or supporting actors ia an external
  actor that provides service to the system under
  design

12
Communication between actors and the system

• In each use case, a primary actor starts things
  off that actor initiates an interaction with
  the system
• The system will then respond to messages and
  might send messages of its own to other actors
• In a use case, the primary actor is trying to
  achieve a specific goal
• the use case consists of all the possible
  interactions that take place in the attempt to
  reach the goal
• there may be many scenarios in a use case - each
  scenario shows an alternative course that is
  based on the success or failure of some of the
  intermediate steps
• the goal might not be reached (because of some of
  the failures)

13
Goals

• A goal is a result that one of the actors wants
  to achieve
• Example goals
• An administrator wants to add a new user to the
  system
• A pilot wants to land a plane
• A customer wants to file a claim on an insurance
  policy
• A service person wants to file a trouble report

14
Scenarios

• A scenario is a little story
• it is an outline of some expected sequence of
  events
• A scenario is used to convey the fundamentals of
  how things work
• It usually includes at least one actor
• Each actor can make requests of the system or
  respond to system activity

OK. Will that be all?
Yes.
That will be 7.40.
15
Different styles of use cases

• Text formats
• informal paragraph summary the paragraph will
  describe who starts the scenario, the key actions
  by the actors and the system, and how to handle
  failures
• numbered list of steps in this format, the main
  scenario is a list of sentences describing the
  sequence of actions by each actor and/or the
  system failure scenarios can be written as
  branch scenarios at the end
• Graphical formats
• UML Sequence Diagrams (also known as message
  sequence charts)

16
Identifying actors

• An Automated Teller Machine (ATM) permits
  customers to withdraw money from their accounts,
  make deposits, and check their account balances.
  The ATM machine communicates with a computer
  system in the banks central office to validate
  passwords and account information. The ATM is
  serviced on a regular basis by bank employees, to
  collect deposit envelopes and to load in more
  cash and receipt paper.
• Question who are the actors in this system?

17
Creating a simple scenario

• Draw a sequence diagram for one of the scenarios
  in the ATM system. One prominent use case in
  this system is customer performs an ATM
  transaction, and one scenario in that use case
  is customer withdraws money. Assume we are in
  the sunny-day scenario.

Customer
ATM
18
Scenario - Example

• A scenario is a little story
• It describes one possible course of events
• Customer puts ATM card into machine and types
  password
• System validates the card and password
• System prompts the customer for a transaction
  type and amount
• Customer selects withdraw 100 from checking
• System checks with the central bank make sure
  customer has sufficient funds
• System dispenses the cash, returns card, and
  prints receipt
• System asks customer if he/she would like another
  transaction

19
Representing Use cases

• Text templates
• Informal text
• informal paragraph summary the paragraph will
  describe who starts the scenario, the key actions
  by the actors and the system, and how to handle
  failures
• numbered list of steps in this format, the main
  scenario is a list of sentences describing the
  sequence of actions by each actor and/or the
  system failure scenarios can be written as
  branch scenarios at the end
• Tables informal text
• Structured templates one popular example (A.
  Cockburn)
• Structured (semi-formal) DOORS template
• Graphical formats
• UML Use Case diagrams capturing the system
  boundary, use cases(names), actors, channels and
  use case relationships
• UML Sequence Diagrams (also known as message
  sequence charts, MSC) to represent scenarios

20
Showing a scenario in text format

• A scenario can be written as a series of
  sentences
• each sentence shows one step of the scenario
• each step needs to explain
• who does the operation
• what operation is performed
• when the operation is performed
• are there any side conditions?
• one important thing that is not included in the
  description of each step of a scenario how the
  operation is performed (this is left for the
  design phase)
• Important style points
• each step in the scenario must have a subject
  (either the system or an actor is performing the
  step)
• no passive or impersonal voice allowed (e.g.,
  the results are displayed)

21
Example of a text format scenario

• Customer buys a single item
• 1. Customer asks for an item
• 2. Postal clerk acknowledges customer request,
  checks if the requested item is available
• 3. Postal clerk asks the Customer if there will
  be anything else in this transaction
• 4. Customer indicates that they dont want
  anything else
• 5. Postal clerk determines the price of the
  requested items and tells the customer
• 6. Customer pays
• 7. Postal clerk gives the Customer the items and
  change
• Note this is not yet a use case, just a single
  scenario.

22
Showing a scenario in graphical form

• Scenarios can be shown in a standard graphical
  notation this notation has many different names
• Sequence diagram, Event trace diagram,
  Interaction diagram, Fence post diagram

Ask for item
Acknowledge request
Anything else?
No
Respond with price
Give money
Give item and change
23
Writing a use case

• Step 1 Pick one of the potential goals of one
  of the actors
• Step 2 Write down the preconditions for that
  goal
• Step 3 Write the sunny-day scenario for the
  interaction between actors and system
• Step 4 Identify the possible failures at each
  step - think about the alternative scenarios that
  might result
• Step 5 For the main failure situations, either
  create entire scenarios or create extensions of
  the main scenario
• optional step Find common chunks that occur in
  several scenarios that can be factored out to
  make the scenarios simpler

24
Example use case
Use case name Ticket Buyer buys a lottery
ticket Primary actor Ticket Buyer Precondition
Ticket Buyer has 1 Main scenario 1. Ticket
Buyer tells the system (person or machine) that
he/she wants to buy a ticket 2. System asks the
Ticket Buyer for his/her choice of lucky number
3. Ticket Buyer chooses a number 4. System asks
for 1 5. Ticket Buyer supplies 1 6. System
prints a lottery ticket and gives it to the
Ticket Buyer Variations 2. Ticket Buyer
chooses a number 2a. using keypad
2b. fills in circles on card 2c. asks for a
quick pick
25
Example use case - scenario
26
Example use case (continued)

• The use case isnt finished
• still need to handle failures
• go through the steps, list the various ways that
  they could fail
• Ticket Buyer cant decide on a number, changes
  his/her mind
• Ticket Buyer fills in too many circles on the
  card
• System cant print a ticket because it is out of
  ticket paper
• from some failures, the system can recover
• from other failures, the use case will fail

27
Making scenarios more elaborate

• There are three ways to create more elaborate
  scenarios
• Variations
• Extensions
• Chunks (subfunctions)

28
Variations

• A variation is a way to avoid scenario
  explosion
• A variation is a list of alternatives that is
  tied to a specific line of a scenario
• Each variation could turn into a lower-level
  scenario
• An example variation (for the post office
  scenario)

1. Item is a. stamps b. postage on an item that
the customer is mailing c. postage due on an item
that the customer is receiving d. post office box
rental e. mugs, t-shirts, and other Postal
Service merchandise 6. Payment is a.
______________ b. ______________ c.
______________
Main scenario 1. Customer asks for an item 2.
Postal clerk acknowledges customer request,
checks if the requested item is available 3.
Postal clerk asks the Customer if there will be
anything else in this transaction 4. Customer
indicates that they dont want anything else 5.
Postal clerk determines the price of the
requested items and tells the customer 6.
Customer pays 7. Postal clerk gives the Customer
the items and change
29
Extensions

• An extension is a short scenario that branches
  off from another scenario
• Extensions are used to describe recovery actions
  when something goes wrong
• extensions might rejoin the main scenario
• or extensions might just terminate because the
  goal cant be achieved
• An example extension (for the post office
  scenario)

2a. Item is not available 2a1. Postal clerk
looks for an equivalent item 2a2. If an
equivalent item is found, the Postal clerk asks
customer if the equivalent item is OK
Main scenario 1. Customer asks for an item 2.
Postal clerk acknowledges customer request,
checks if the requested item is available 3.
Postal clerk asks the Customer if there will be
anything else in this transaction 4.
30
Chunks

• A chunk is a sub-scenario - a sequence of
  messages that appears in several scenarios for
  one or more use cases.
• A chunk is a scenario that addresses a specific
  subgoal
• for example logging in, searching for a
  specific product, etc.
• They are the subroutines of the use case family
• They may express some common user interface
  sub-scenarios
• Alistair Cockburn calls them subfunctions (but
  we dont want to think of them as associated with
  low-level code)

31
The UML Use Case Diagram

• In UML (Unified Modeling Language), it is
  possible to show a picture of the system as a
  group of use cases
• each stick figure is an actor
• each ellipse represents a use case
• The diagram is deceptively simple
• behind each ellipse, there might be a whole bunch
  of scenarios sunny-day, alternatives, failures
• the diagram is only a summary

withdraw cash
Customer
check balance
Bank Employee
service ATM
32
A simple format for a use case

• Use case 1 Employee opens door
• Goal An Employee wants to unlock a door to pass
  from one room to another.
• Preconditions The Employee has valid
  identification to open the door.
• Success end condition Employee has successfully
  opened the door.
• Failed end condition Door remains closed and
  the Security Guard on duty is notified.
• Actors Employee, Security Guard
• Main scenario
• 1. Employees identification and door
  identification is sent to system
• 2. Door is unlocked
• 3. Employee opens door, passes through the door,
  and recloses door, SUCCESS
• Extensions
• 2a. Employees identification is not valid
• 2a1. System notifies Security Guard, FAIL

33
More Notations and Examples
34
Use-Case diagrams - actors
35
Use- Case diagramms - use-cases
Representing use cases - more details

• Use-Case Number (ID) Name
• Actors
• Pre- postconditions
• Non-functional requirements
• Behavior - main scenario
• sequence diagram(s)
• decomposition in smaller UC diagrams
• Error-handling exceptions
• Other
• examples, prototypes, etc.
• open questions contacts
• other diagrams

place phone call
UC description
36
More on Use-Case diagrams

• Show use-cases actors
• connected by associations
• refined by inheritance stereotypes
• uses
• re-use of a set of activities (use-case)
• partitioning of activities
• points to the re-used use-case
• extends
• variation of a use-case
• points to the standard use-case

elicit customer needs
extends
make an interview
uses
produce a SRS
37
Use-Case diagrams Example
38
On Use Case Levels

• It is possible to write
• business-level use cases
• organizational goals (marketing, finance, systems
  engineering, installation)
• or system-level use cases
• goals of specific users
• or subsystem-level use cases
• goals of the other subsystems

39
Levels of scope (A. Cockburn)

• Summary-level goals
• cloud-level

Upgrade all customers

• User goals
• sea-level
• usually 2 to 20 minutes

Add new service

• Sub-functions
• under water
• not a real user goal these scenarios describe
  common sub-operations

Find list of services
40
Goals Sub-goals

• Each use case represents a goal of one of the
  actors
• the use case is the set of all scenarios that
  might happen in trying to reach that goal
  success or failure scenarios
• each scenario is a series of smaller sub-goals
• if you can succeed in each step, you will reach
  the goal
• if a step fails, then there might be an
  alternative series of steps that get to the goal
• the substeps might be lower-level use cases, or
  they might just be things implemented in the
  design

41
Use Case diagram decomposition
Use- Case diagrams Hiearachies
diagram name anything
Diagram name anything-level2-for-uc4
42
Use Case Process
43
Use Case Process (Cont.)
44
Use Case Tips

• When you do use case brainstorming
• try to create a list of actors write down a
  definition of the actor that everyone can agree
  on
• actors are roles, not job titles
• in the scenarios, start each step with the name
  of an actor or the system
• not the lucky number is entered
• better the Ticket Buyer enters the lucky
  number

• use strong, active verbs in the steps of the
  scenarios
• not Make, Report, Organize, Record, Retrieve,
  Search
• better Create, View, Calculate, Register, Find,
  Browse

45
How many use cases is enough?

• It depends
• make sure you cover the major goals of each actor
• dont forget OAM administrative use cases
  usually include initialization, running backups,
  diagnosing problems, and reporting current status
  to another system
• some systems might need 100-200 use cases, but
  most only have 20-40
• do some abstraction to reduce the number of
  scenarios

46
Use Cases contribute to agility

• It is important to be agile
• Requirements
• get direct customer involvement in documenting
  the requirements using scenarios and use cases
• Architecture
• make better architectural decisions use the
  high-runner, high-priority scenarios to assess
  candidate architectures
• Project management
• use cases can help to plan an iterative
  development process
• Test
• update the tests as the requirements change

47
Agile development

• Some important goals in todays software
  development
• focus on the customers needs
• adapt to changing requirements support iterative
  development
• document the core requirements faster
• The agile development approach
• everyone collects requirements using scenarios or
  stories
• project managers assign priorities (with the help
  of the customer)
• everyone plans to add variations of the
  scenarios but dont implement every variation
  in the first release
• developers use scenarios in their designs
  testers build tests from scenarios

48
Scenarios and use cases in design, coding, and
test

• The use cases are a very useful form of
  requirements
• they attempt to describe the externally visible
  behavior of the system
• they are concise enough for everyone to read
  (customers, developers, testers)
• Use cases can be kept under change control
• Design-level and code-level comments ought to
  refer to individual use cases, so that individual
  design decisions can be revisited when the use
  cases are changed
• System-level tests will use the information from
  use cases

49
Impact of Use Cases on Software Teams

• Systems engineers improve communication with
  development team
• SEs will write the key functional requirements as
  use cases (typically, 20 to 200 use cases for a
  system)
• the set of system-level use cases (a subset of
  the overall requirements) can be constructed and
  reviewed quickly
• customers can validate the main scenarios
• Architects benefit from using the most
  important failure scenarios to evaluate the
  architecture
• Development managers iterative and incremental
  development can start with the high-priority use
  cases focus on the scenarios that deliver the
  maximum value to customers
• Developers code inspections can narrow the
  focus on the most important scenarios
• Testers integration and system tests are guided
  by the use cases

50
Use cases and requirements

• Use cases are requirements
• a use case will specify the essential behavior
  that the system must deliver
• Use cases are usually about 1/3 of the total
  volume of requirements
• The use cases are supplemented by other kinds of
  requirements information
• Business Rules conditions, policies, and
  conventions
• Operational Profiles how many scenarios
• Architectural Requirements -ilities
  (reliability, usability, performance)

Business Rules
BR1. Each employee has a unique identification number.
BR2. Each open-door request is logged.
Architectural Requirements
AR1. Maximum time to process an open-door request is 15 seconds.
AR2. No more than 5 minutes downtime per year.
Operational Profiles
OP1. During the busy hour (8-9am), the system should be able to handle 500 open-door requests (UC1 sunny-day).
OP2. The test alarm use case will be executed every weekend.
51
Why use cases?

• Why write use cases instead of normal
  functional requirements?
• Use cases hold functional requirements in an
  easy-to-read, easy-to-track format
• Each use case gives information on how the system
  will deliver a goal to one of the users of the
  system
• a use case explains how a goal succeeds/fails
  using scenarios
• the scenarios provide context traditional
  requirements are often too ambiguous
• If you have a requirement that doesnt help meet
  any of the users goals, why do you have the
  requirement in the system?
• also need to look at the goals of the
  stakeholders
• Use cases show only the Functional requirements
• the use cases are a framework to attach
  non-functional requirements and other project
  details

52
Use Cases and Requirements

• The use cases are not all of the requirements
  some requirements do not fit into scenarios, for
  examples
• Constraints, e.g., Business Rules (structural
  facts, computation rules, action restricting
  rules, action triggering rules)
• Non-functional Requirements security,
  reliability, performance, usability, flexibility
  (all of the -ilities)
• Links to use cases
• Constraints and Non-functional Requirements are
  written in text, and they are related to the use
  cases where they are pertinent
• DOORS links provide an excellent mechanism for
  this

53
After the use cases are written, what next?

• Jumpstart the OOAD CRC and models
• use cases describe the externally-visible
  behavior of the system
• an object model describes the internal behavior
• Design decisions can be linked back to a use case
• Jumpstart test cases
• Scenarios provide excellent start for early
  testing
• Test planning RTP and RSTP
• DOORS-based traceability
• Use the Use Case list to manage your project
• Use cases provide excellent basis for structuring
  and monitoring your project iterations
• It is important to be agile

54
Use Cases and other Requirements

• The use cases are not all of the requirements
  because some things dont fit into scenarios
• Business Rules (structural facts, computation
  rules, action restricting rules, action
  triggering rules)
• Non-functional Requirements security,
  reliability, performance, usability, flexibility
  (all of the -ilities)
• Links to use cases
• The Business Rules and the Non-functional
  Requirements are written in text, and they have
  links to the use cases where they are pertinent
• Some folks store these items in a spreadsheet or
  a repository tool (such as Telelogic DOORS or
  Rational RequisitePro)

55
After the use cases are written, what next?

• Object oriented modeling using CRC cards or
  other informal brainstorming techniques
• use cases describe the externally-visible
  behavior of the system
• an object model describes the internal behavior
• Design decisions can be linked back to a use case
• just put comments in your code or model
• search for the comments whenever the use cases
  are modified
• Test planning
• each use case needs to be converted into test
  scenarios and test cases

create archive
56
Use cases and CRC cards

• Use cases are written to describe the external
  view of a system
• Use cases may describe the high-level physical
  architecture of a system
• but they leave out most of the details about
  how the system will perform most of its
  functions
• CRC cards are created to describe the high-level
  classes of a system they describe the first
  internal view of a system
• CRC cards are another informal modeling
  technique that is widely used for the initial
  brainstorming process
• CRC cards attempt to identify the high-level
  classes by describing their behavior and
  principal interactions
• For more information on CRC cards, see Nancy
  Wilkinsons book Using CRC Cards (SIGS Books,
  1995)

57
Iteration management with use cases

• A use case model can be very useful in a project
  with rapid iteration
• for each iteration, identify which use cases are
  in the iteration
• that is, will some or all of the use cases
  scenarios work?
• track progress by counting scenarios (with
  priority weighting)
• typical iteration scheme
• first iteration highest priority use cases,
  sunny-day scenarios only
• second iteration add a few second-tier use
  cases, start implementing the failure scenarios
  that fail completely
• later iterations add a few more use cases,
  start filling in the recovery scenarios
• you might choose certain use cases as
  high-priority because they help validate key
  parts of the architecture

58
References

• Books
• Alistair Cockburn, Writing Effective Use Cases
• Daryl Kulak and Eamonn Guiney, Use Cases
  Requirements in Context
• Steve Adolph and Paul Bramble, Patterns for
  Effective Use Cases
• Kurt Bittner and Ian Spence, Use Case Modeling
• Web sites
• http//www.usecases.org
• http//agilealliance.org
• http//members.aol.com/acockburn
• http//members.aol.com/acockburn/papers/usecases.h
  tm

59
Extra ....

• Use Cases and Tools

60
Use cases and RM Tools
61
Storing Use Cases in DOORS
A Use Case is stored in the DOORS hierarchical
object structure
entire DOORS module
a Use Case object in DOORS
62
(No Transcript)
63
(No Transcript)
64
(No Transcript)
65
(No Transcript)
66
Extra ....

• Modeling

67
Why build models?

• To organize the work
• Building software is a time-consuming and complex
  operation
• Good quality software can have a long lifetime
• To improve communication among team members
• Software is very labor-intensive many people
  play a part in the construction of a software
  product
• Ordinary text documentation is inherently
  imprecise and ambiguous
• To aid in the thinking process
• In most software development projects, the actual
  form of the thing to be built is initially very
  vague
• Iterative and incremental development will focus
  on changes to the models - it is easier to
  rebuild the model than to rebuild the system

68
Some traditional modeling techniques

• Data modeling (using Entity-Relationship
  Diagrams)
• the system is viewed as a set of data entities
  and relationships
• the model includes the transactions that are
  applied to the system
• Data flow
• the system is viewed as a group of data sources,
  data stores, and active processes that exchange
  data messages on a regular basis
• the model emphasizes the frequency and data
  content of the messages
• State machines
• each element of the system has a internal state
• there can be transitions from one state to
  another when certain key events are received by
  an element

69
System-level static data model

• In the process of creating a set of use cases for
  a system, it is useful to think about the major
  data entities in the system
• these data entities and their connections can be
  drawn using Entity-Relationship diagrams or Class
  diagrams
• the names of the entities are often used in the
  descriptions of the actions in the use case
  scenarios
• Be careful not to over-specify the data
  entities
• you should only specify the key data attributes
  (not all of the attributes)
• it is sometimes useful to describe some of the
  fundamental responsibilities of the data entities
  (using CRC cards or other OO techniques)

1
1
1
0..
70
Extra ...

• Example

71
Exercise

• What are the main actors and use cases for an
  Online Banking System?
• Actors
• Use cases

72
Lottery system exercise

• The system to be built is a distributed computer
  system for a state lottery.
• The system will be used by three kinds of users
  ticket buyers, lottery ticket agents, and lottery
  staff people.
• Ticket buyers use the system to buy lottery
  tickets. Each ticket costs 1.
• Lottery ticket agents pay prizes to ticket buyers
  who turn in winning lottery tickets.
• A lottery staff person will post the winning
  number of the day on the computer system, check
  on the days revenue, and disable ticket sales
  one minute before the drawing.

• List the actors for the whole system
• Ticket buyer
• List the actors for the lottery ticket machine
  subsystem
• Ticket buyer

73
A lottery system use case

• Use case for the ticket buyer buys a ticket
  situation (assume that we are considering the
  whole system and not just the lottery ticket
  machine subsystem)

Use case nameTicket buyer buys a ticket Actors
(a list of all the actors involved in this use
case) ???? Authors of this use case
me Summary Preconditions (what has to be true
before this use case can be initiated?)
???? Frequency (how often will this use case
happen? once per week, once per hour, )
???? Description (in words or as one or more
sequence diagrams use more pages if needed)
1. 2. Exceptions, Variations, Extensions,
and Chunks
74
Sample list of actors

• Actors for the whole system
• Ticket buyer
• Lottery ticket agent
• Lottery staff person
• Actors for the ticket machine subsystem
• Ticket buyer
• Central computer
• Machine service person

75
Sample lottery system use case
76
Extra ...

• Summary

77
Better Requirements and Product Quality through
Use Cases (UC)

• Summary of Characteristics and Benefits
• UCs capture a contract between the stakeholders
  of a system about its behavior
• UCs specify systems behavior under various
  conditions (success failure modes) in a way
  that is concise and easy to understand, track,
  and validate
• UCs are collections of scenarios scenarios
  provide context traditional requirements are
  often too ambiguous
• UCs are a key to the creation/ generation of
  quality test cases and system verification

• Industry data
• Use cases improved developer productivity by 40
  (DaimlerChrysler)
• 35 increase in developer productivity at Merrill
  Lynch achieved through Tool-based Requirements
  Management and Use cases

78
Vocabulary in this section

• use case collection of scenarios related to a
  goal
• goal what the actor is trying to accomplish when
  using the system (this might succeed or fail)
• scenario a sequence of interactions
• sunny-day scenario a scenario where everything
  works
• failure scenario a scenario that explains what
  happens when something goes wrong
• variation a set of choices for a single scenario
  step

• extension a branch scenario that starts with an
  extension condition
• actor a person or system outside of the system
  under development
• precondition one of the conditions that must be
  true when a scenario of the use case is triggered
• chunk or subfunction a set of scenario steps
  that are repeated in several different use cases
• business rule one of the rules that describes
  how the business is run
• operational profile description of which use
  cases will be run at the same time

79
Useful books

• Writing Effective Use Cases by Alistair Cockburn
• Patterns for Effective Use Cases by Steve Adolph
  and Paul Bramble
• Use Case Modeling by Kurt Bittner and Ian Spence