10/8/2018

Case Cases: What ??

• Use cases are text stories (not diagrams!) used
to discover and record requirements

Use Cases • If a diagram clarifies the text, use it

Lecture 02
• Scenario – Specific sequence of actions and
The first step in getting what you want is to decide interactions between actors. (also called a
what you want. use-case instance)

1
• Functional Requirements 2

Use Case: Why…? Terms and Symbols

• Actor – something with a behavior, such as a
• Use cases are not part of OO Analysis but
person, an input device, etc.
these are key requirement input document

• Use Case is a collection of related success and

• Simple and easy way to ensure various non-
failure scenarios that describe an actor using a
technical stakeholders’ involvement.
system to support a goal
• Boundary
• Ensure goal based requirement specification

• Connections
3 4

1
 10/8/2018

Three Formats Scope

• Brief – Terse, one-paragraph summary, usually
the main success scenario. Create during • Defines how broad the use case is. This can
early requirements phase. be for the whole system, as in the POS
example, or narrow, as in a use case for
• Casual – Informal paragraph format. Can
creating a journal entry in an accounting
cover various scenarios (alternate flow as
system.
well) in multiple paragraphs.
• Fully-dressed – All steps and variations written
in detail. Has supporting sections, success
guarantees, main scenario, alternate
scenarios, etc.
5 6

Roles Level
• The person (or sometimes object) that calls • User-goal: Common kind of scenario.
upon system services to fulfill a goal is Actor Scenarios that let a user get something done.
Typically primary Actors’ goals are fulfilled.
• The stakeholders are people who have a
reason to want this system. The Interests are • Sub function: smaller steps required to
their reasons for wanting it and what they support a user goal. Used to factor out
expect from it. duplicate sub steps shared by several use
cases e.g. Pay by Credit.

7 8

2
 10/8/2018

Actors Primary Actors

• Anything that have behavior e.g. people,
machine, organization, software • Primary actors has user goals fulfilled through
using services of the system
• Primary Actors • Why??
• Supporting Actors
• Offstage Actors • To find user goals
• Goals derives requirements use case
• Actor name in Capital e.g. Cashier, Manager

9 10

Supporting Actors Offstage Actors

• Provides services to system e.g. information • Actors have interest in the behavior of the use
• Payment Authorization service is supporting case e.g. tax agencies
actors • Why…?
• Why..? • To ensure all necessary interests are identified
and satisfied
• To clarify external interface and protocols • Easy to miss unless explicitly named

11 12

3
 10/8/2018

Main Success Scenario Extensions or Alternate Flows

• These include all other possible outcomes,
• This satisfies the interests of the stakeholders.
both success and failure.
You get your groceries, the store gets your
money, inventory is reduced, etc. • Used mostly in fully dressed use case.
• Steps: • Complex and larger than happy path
– An interaction between actors • Usually branch out from main scenario n then
– Validation (by the system) merge back to it.
– State change to the system • Complex extensions can be a separate use
case.

13 14

Preconditions and Success

The include Relationship
Guarantee
• Don’t duplicate text. Separate it into is own • These should be non-obvious. System is on
subfunction use case and indicate its inclusion
• Paying by credit: include Handle Credit • Preconditions state what must ALWAYS be
Payment true before you can start the scenario. This
often defines the success of another use case.

• Success guarantees state what must be true

on successful completion of the use case.
15 16

4
 10/8/2018

Use Case: Scenario Performing Another Use Case

Process Sale: A customer arrives at a checkout • Use cases can branch to other use cases. For
with items to purchase. The cashier uses the example, if a POS system rejects a bar code,
POS system to record each purchased item. The the cashier can request alternate lookup.
system presents a running total and line-item • Denote this by underlining: Cashier performs
details. The customer enters payment Find Product Help to get item ID and price
information, which the system validates and
records. The system updates inventory. The
customer receives a receipt from the system and
leaves with the items.
17 18

Technology and Data Variations Write in a UI-Free Style

• Technical variations on how something must • Most programs are dependent upon a
be done: particular user interface. However, avoid
– Scan bar code constraining your program too early:
– Key item ID • “The user keys an ID and password into a
dialog box and presses the OK button.”
• Avoid early design decisions; keep things • “The user identifies himself to the system.”
general. • The latter allows for biometric ID, keyin, etc.

19 20

5
 10/8/2018

Essential Style Write Black-Box Use Cases

• Focus on the essence, or basic idea, not the • Don’t describe internal workings
details of implementation • Describe responsibilities
• Contrast with concrete style • “The system records the sale” vs. “The System
writes the sale record to a database”

21 22

Finding Use Cases Questions to Find Actors and Goals

1. Choose the system boundary • Who starts and stops the system?
2. Identify the primary actors • Who does user and security management?
3. Identify the goals for each primary actor • Who does system administration?
4. Define use cases that satisfy these goals • Is “time” an actor because the system does
something in response to a time event?
• How are software updates handled?
• Who gets notified of problems?

23 24

6
 10/8/2018

Actor-Goal List Tests

Actor Goal
• The Boss test: “What have you been doing all day?”
Cashier Process Sales
Process rentals Is this strongly related to achieving results?
Handle returns
Cash in
• The Elementary Business Process test: Task
Cash out performed by one person at one place at one time in
Manager Start up response to a business event that adds value and
Shut down
System administrator Add/Modify/Delete users
leaves data in a consistent state.
Manage security
Manage System tables
• The size test: Fully dressed is 3-10 pages.
… … • Reasonable violations: Separate sub function, or fails

25 26

A simple diagram can add clarity Requirements in Context

• Use cases organize a set of requirements in
the context of a typical use of the system
• High-level feature lists are acceptable
• Some applications need feature-driven
viewpoint; don’t create use cases for these

27 28

7
 10/8/2018

Handle Credit Payment

Level Subfunction
Main success scenario
1. Customer enters his credit account information
2. System send payment authorization request to
external system
3. System receives payment approval and signals
cashier
Extensions
2a. System cannot communicate with external system
…
29