Use Cases - PowerPoint PPT Presentation


PPT – Use Cases PowerPoint presentation | free to download - id: 415f36-NDQzO


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

Use Cases


Use Cases Use-Case diagrams: example What is Requirements Engineering About? Effectively generating High Quality Requirements: Use Cases & Early Testing Paradigm ... – PowerPoint PPT presentation

Number of Views:30
Avg rating:3.0/5.0
Slides: 50
Provided by: kir82
Learn more at:
Tags: ooad | cases | use


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

Title: Use Cases

  • Use Cases

Use-Case diagrams example
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
Use Cases Early Testing Paradigm
Requirements Validation Quality
Assurance Faster Time to Market
System Test
System Design
Integration Test
Detailed Design
Module Test
Software Production Cycle
Design Specifications Models
Code Creation
Design Specification (Design Model Generation)
Design Tools
SDE, SCM Tools
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
Software Production Cycle
Design Specifications Models
Code Creation
Design Specification (Design Model Generation)
Design Tools
SDE, SCM Tools
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
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
  • 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
  • no information about the internal design

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
  • combined with prototypes

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
  • 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

More on Scenarios
  • A scenario is a little story
  • It describes one possible course of events
  • Customer puts ATM card into machine and types
  • 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

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
check balance
Bank Employee
service ATM
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
  • 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)

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
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
  • System cant print a ticket because it is out of
    ticket paper
  • for some failures, the system can recover
  • for other failures, the use case will fail

(No Transcript)
Example use case
A bit on Use Case Theory
  • Each use case represents a goal of one of the
  • 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 subgoals
  • 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
  • It is possible to write business-level use
  • 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

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
  • 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
  • use strong, active verbs in the steps of the
  • not Make, Report, Organize, Record, Retrieve,
  • better Create, View, Calculate, Register, Find,

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

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

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
  • 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
  • Use cases show only the Functional requirements
  • the use cases are a framework to attach
    non-functional requirements and other project

Use Cases and 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)

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

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
Use-Case diagrams - actors
actor cellular network
Textual stereotype (class)
Visual stereotypes (classes)
entity passive objects data stores
actor persons roles
Use-Case diagrams (1)
  • 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
make an interview
produce a SRS
A typical Use-Case diagram
diagram name anydiag
Use- Case diagrams (2)
  • Focus of the diagram is the part of the business
    process that is going to be supported by the IT
  • It is the end-user perspective that is modeled.
  • It is goal driven
  • UC diagrams help to identify system services.
  • UC diagrams are NOT used as DFDs.
  • Sequences, branching, loops, rules, etc. cannot
    (and should not!) be directly expressed.
  • UC diagrams are often combined with activity
  • UC diagrams can be further decomposed.

Use Case diagram decomposition
diagram name anything
Diagram name anything-level2-for-uc4
Use-Case diagrams example (2)
actor flight res-sys
actor credit-card sys
Use Case Fundamentals
Step 1 Create a list of Actors
Step 3 Write simple use cases with only
sunny-day scenarios
UC1 Customer downloads a song Precondition Song
file is on a server Main scenario 1. Customer
chooses song 2. System checks availability and
price prompts Customer for payment 3. Customer
enters credit card info 4. System sends credit
card transaction to Bank 5. Bank returns
transaction number 6. System transmits the
song to Customers computer
Step 2 Create a list of Goals
Web-based music distribution system UC1
Customer downloads a song UC2 Customer searches
music directory UC3 Administrator adds a new
user UC4 Administrator updates directory UC5
Support hotline person investigates a Customer
problem UC6 Support hotline person authorizes
Customer refund UC7 Repair person runs
Step 4 Review the use cases with customer (or
customer surrogate)
Use Case Fundamentals
Step 5 Identify failure conditions
  • Step 7 Internal review
  • review the scenarios and failure branches with
    testers, developers, project managers
  • Ongoing make links to other requirements, update
    use case model as needed
  • define the business rules and non-functional
    requirements (in text documents, with links to
    the use case model)
  • add new use cases and new scenarios for new
    actors and goals new variations for existing use

2a. Song is not available 3a. Customer quits
without entering credit card info 4a. Link to
Bank is down 5a. Credit card is rejected by
Bank 6a. Server fails during transmission 6b.
Customer cancels during transmission
Step 6 Write a selected set of failure scenarios
and alternatives
5a. Credit card is rejected by Bank 5a1.
System reports failure to the Customer, prompts
Customer for a different credit card 5a2.
Customer enters card info 5a3. go to step 4
To describe your use cases use the template in
this section or see a detailed template
at http//
  • 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
  • Web sites
  • http//
  • http//
  • http//
  • http//

Agile development
  • Some important goals in todays software
  • focus on the customers needs
  • adapt to changing requirements support iterative
  • document the core requirements faster
  • The agile development approach
  • everyone collects requirements using scenarios or
  • 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

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

Use cases and RM Tools
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
(No Transcript)
Storing Use Cases in DOORS
  • In DOORS, a use case will be represented as a
    simple hierarchical document

Storing Use Cases in DOORS
  • Continuation of the previous page

Storing Use Cases in DOORS
  • Continuation of the previous page

Different styles of use cases
  • Graphical format
  • UML Sequence Diagram (also known as message
    sequence chart)
  • Text formats
  • informal paragraph summary who starts the
    scenario, the key actions by the actors and the
    system, and how to handle failures
  • numbered list of steps a list of sentences
    describing the actions of each actor and/or the
    system failure scenarios can be written as
    branch scenarios at the end
  • The previous example shows two different
    representations for the same sunny-day scenario
    a sequence diagram and a text-based numbered list
    of steps
  • either the text format or the graphical format
    can be used to drive the generation of test

Extensions in DOORS
  • Here is an example of two extensions with the
    extension scenarios filled in.

Actors in DOORS
  • The Actors are described in one section of the
    DOORS module

Storing Use Cases in DOORS Summary
  • Need 1 OK to have a partially completed use
    case model
  • with some of the use cases completely done but
    others with just a goal and preconditions
  • sunny-day scenario and extensions can be added
  • Need 2 text or graphics
  • use either text or graphics to represent the main
    success scenario and/or failure scenarios
  • Need 3 links to other requirements (in the
    same module or in other modules)
  • links between other non-use case requirements and
    specific steps of a use case or the entire use