Use Cases:

Requirements In Context
Importance of Requirements
Analysis
❖Challenged projects : projects that did
not materialize or were not completed on
time
❖37% of the problems with such projects
were related to requirements:
– 13% - poor user input
– 12% - incomplete requirements
– 12% - changing requirements
 Types of Requirements
FURPS+
❖ Functional - features, capabilities, security
❖ Usability - human factors, help, documentation
❖ Reliability - frequency of failure, recoverability,
predictability
❖ Performance - response times, throughput,
accuracy, availability, resource usage
❖ Supportability - adaptability, maintainability,
configurability
 The + in FURPS+
❖Implementation - resource limitations,
language and tools, hardware, etc.
❖Interface - constraints imposed by
interfacing with external systems
❖Operations - system management in its
operational setting
❖Packaging - collection of programs that
perform similar functions or have similar
features.
❖Legal - licensing and so forth
What artifacts may start in inception?
❖ Vision and business case
– Describes high-level goals and constraints.
❖ Use Case model
– Describes a set of typical scenarios encountered in
using a system.
⮚ Consists mainly of behaviours (functional requirements).
❖ Supplementary specification
– Describes other requirements not in use cases
⮚ Consists mainly of non-functional requirements
 What is a Use Case?

A Use Case is a text story of some actor

using a system to meet one or more goals
(or not).
 The Use-Case Model
❖Defined within the requirements discipline
❖It is the set of all use cases
❖A model of the system’s functionality and
environment
❖Help keep the system goals and
requirements clear to all
❖Easier – especially for end-users –
contribute meaningfully.
Use Cases as Requirements
❖ Use cases are requirements
– primarily functional
– central mechanism for requirement discovery
– not all the requirements are described this way
– they are text documents not diagrams
❖ UML diagrams describes the use cases, actors and
their relationships
 Goals and Scope of a Use Case
❖ At what level and scope should use cases be
expressed?
❖ A: Focus on uses cases at the level of elementary
business process (EBP).
❖ EBP: a task performed by one person in one place at
one time which adds measurable business value and
leaves the data in a consistent state.
– Approve credit order - OK.
– Negotiate a supplier contract - not OK.
❖ It is usually useful to create separate “sub” use cases
representing subtasks within a base use case.
– e.g. Paying by credit
 Use Cases and Goals
❖ An EBP-level use case is a user-goal use case
❖ To find use cases at this level:
– find the user goals
– define a use case for each goal
❖ Don’t ask: "How will the system be used?"
ask "What are the goals of the users?"
– "Login" is not a user goal - therefore not an EBP-level
use case.
⮚ Place a refill order is a goal
⮚ Fill out a feedback form is a goal
Use cases and adding value
❖ Actor: something with behavior, such as a person,
computer system, or organization, e.g. a cashier.
❖ Scenario: specific sequence of actions and
interactions between actors and the system under
discussion, e.g. the scenario of successfully
purchasing items with cash.
❖ Use case: a collection of related success and
failure scenarios that describe actors using a
system to support a goal.
Use cases and adding value
Main success scenario: A customer arrives at a
checkout with items to return. The cashier uses the
POS system to record each returned item…
Alternate scenarios:
If the credit authorization is reject, inform customer
and ask for an alternative payment method.
If item identifier not found in the system, notify the
Cashier and suggest manual entry of the identifier
code.
…
Use case types and formats
❖ Uses cases may be written in three formality types
– Brief: one-paragraph summary, usually of the main
success scenario.
– Casual: Informal paragraph format (e.g. Handle returns)
– Fully dressed: elaborate. All steps and variations are
written in detail.
Fully Dressed Use Case Format
Use Case Name WikiName, start with verb
Scope System boundaries (corp, prog)
Level Summary, subfunction, etc
Primary Actor Primary system user
Stakeholders Who cares and what they want
Preconditions Must be true to start
Postconditions What is guaranteed by success
Main Success Scenario Typical, unconditional path scenario
Extensions Alternative success or failure scenarios
Special Requirements Related non-functional requirements (RAM)
Technology & Data Varying IO methods and data formats
Variations List
Frequency of Occurrence Is this system used often
Miscellaneous Open issues; eg unmanageable failure scenarios
 Primary Actors, Goals and
Use Cases
❖ Use Cases are define to satisfy the goals of the
primary actors - the principal actor that calls upon
the system to fulfill a goal
❖ The basic procedure is:
– choose the system boundary
– identify the primary actors
– identify their goals at the highest EBP level
– define the use cases that satisfy the user goals
 Choosing the System
Boundary
❖Defining the boundary of the system can be
done by defining what is outside the system
Finding Primary Actors and
Goals
❖Primary vs. supporting actors
❖Brainstorming
❖goals reveal actors; actors reveal goals
❖Some questions to ask:
– Who starts and stops the system?
– Who does user and security management?
– Who does system administration?
– Who evaluates system performance? logs?
– How are software updates to be handled? Pull or push?
– Is time an actor?
 Actor - Goal List
Customer add request
delete request
change request
list prescriptions
Administrator add user
delete user
modify user
manage security
Prescription Activity System analyze prescription data

Manager start up system

shut down system
 Events, Actors, Goals
External Event From Actor Goal Achieved

enter sale line item cashier process a sale

enter payment cashier or process a sale

customer
 Actors
❖ Primary actor - has user goals fulfilled through using services to
the system under development (SuD)
– Why identify - to find user goals
⮚ cashier in a POS
⮚ customer of Pharmacy
❖ Supporting Actor - provides a service to the SuD Example, credit
card check for POS. Often a computer system.
– Why identify - to clarify external interface
❖ Offstage Actor - has an interest in the SuD - a gov't tax agency
– Why identify - to ensure that all necessary interests are
identified
 Fully-dressed example:
Process Sale
Use case UC1: Process Sale
Primary Actor: Cashier
Stakeholders and Interests:
-Cashier: Wants accurate and fast entry, no payment errors, …
-Salesperson: Wants sales commissions updated.
…
Preconditions: Cashier is identified and authenticated.
Success Guarantee (Postconditions):
-Sale is saved. Tax correctly calculated.
…
Main success scenario (or basic flow): [see next slide]
Extensions (or alternative flows): [see next slide]
Special requirements: Touch screen UI, …
Technology and Data Variations List:
-Identifier entered by bar code scanner,…
Open issues: What are the tax law variations? …
 Fully dressed example:
Process Sale (cont.)
Main success scenario (or basic flow):
The Customer arrives at a POS checkout with items to purchase.
The cashier records the identifier for each item. If there is more than
one of the same item, the Cashier can enter the quantity as well.
The system determines the item price and adds the item information to
the running sales transaction. The description and the price of the current
item are presented.
On completion of item entry, the Cashier indicates to the POS system
that item entry is complete.
The System calculates and presents the sale total.
The Cashier tells the customer the total.
The Customer gives a cash payment (“cash tendered”) possibly greater
than the sale total.

Extensions (or alternative flows):

If invalid identifier entered. Indicate error.
If customer didn’t have enough cash, cancel sales transaction.
Essential vs. Concrete style
❖Essential: Focus is on intend.
– Avoid making UI decisions
❖Concrete: UI decisions are embedded in the
use case text.
– e.g. “Admin enters ID and password in the
dialog box (see picture X)”
– Concrete style not suitable during early
requirements analysis work.
 Use Case Diagrams
Primary actors to Supporting actors to
the left: have user the right: they
NextGen
goals. provide
a service.
Process Sale

Cashier Handle returns

Payment
Authorization
Process Rental Service

<<actor>>
Alternative notation Tax Calculator
for
computer system
actor