Use Cases - PowerPoint PPT Presentation

Loading...

PPT – Use Cases PowerPoint presentation | free to view - id: 23fb5d-YmRkM



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Use Cases

Description:

A use case gathers the scenarios related to the (primary) actor's goal ... Primary actor a stakeholder who requests that the system deliver a goal ... – PowerPoint PPT presentation

Number of Views:120
Avg rating:3.0/5.0
Slides: 67
Provided by: kir82
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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)

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
About PowerShow.com