The document outlines effective use case writing based on Cockburn's methodologies, detailing how use cases relate to software requirements. It defines classifications of requirements, differentiates functional and non-functional aspects, and provides structures for documenting use cases, including main success scenarios and extension conditions. Additionally, it emphasizes the importance of identifying actors and their goals to improve project planning and execution.

1. 1
CSE 403
Software Requirements and Use Cases
Reading:
Writing Effective Use Cases
A. Cockburn
These lecture slides are copyright (C) Marty Stepp, 2007, with significant content taken from
slides written by Valentin Razmov. They may not be rehosted, sold, or modified without
expressed permission from the author. All rights reserved.

2. 2
Lecture outline
 Requirements
 definition
 classifications
 Use cases

3. 3
Big questions
 How do use cases relate to requirements?
 What are the ways we can document a use case?
 What is an actor? A goal? A stakeholder?
 What are Cockburn's steps for creating a use case?
 What is an extension, and why are extensions useful?

4. 4
Classifying requirements
 The classic way to classify requirements:
 functional: map inputs to outputs

"The user can search either all databases or a subset."

"Every order gets an ID the user can save to account storage."
 nonfunctional: other constraints

performance, dependability, reusability, safety

"Our deliverable documents shall conform to the XYZ process."

"The system shall not disclose any personal user information."
 Another way to classify them (Faulk)
 behavioral: about implementation; can be measured

features, performance, security
 development quality attributes: part of internal construction

flexibility, maintainability, reusability (more subjective)

5. 5
Cockburn's requirements list
Requirements Outline (p13-14) - good template of all func. requirements
1. purpose and scope
2. terms / glossary
3. use cases
4. technology used
5. other
5a. development process -
participants, values (fast-good-cheap),
visibility, competition, dependencies
5b. business rules / constraints
5c. performance demands
5d. security (now a hot topic), documentation
5e. usability
5f. portability
5g. unresolved / deferred
6. human issues: legal, political, organizational, training

6. 6
Use cases
 use cases: written descriptions of user's interaction
with the software product to accomplish a goal
 helps us discover and document functional requirements
 benefits of doing use cases:
 agreement as to the system's responsibilities
 provides executives a skeleton for planning project priorities
 extension conditions provide a list of things to test for
 qualities of a good use case:
 starts with a request from an actor to the system
 ends with production of all answers to the request
 defines the interactions between system and actors
 written from actor's point of view, not system's
 3-9 clearly written steps in main success scenario

7. 7
Use cases vs. internal features
 consider software to run a cell phone:
Use Cases
 call someone
 receive a call
 send a message
 memorize a number
Point of view: user
Internal Functions
 transmit / receive data
 energy (battery)
 user I/O (display, keys, ...)
 phone-book mgmt.
Point of view: developer /
designer

8. 8
Actors, stakeholders, goals
 actor: anything with behavior (acts on the system)
 primary actor: initiates interaction to achieve goal
 supporting actor: performs sub-goals in use case
 stakeholder: anyone interested in the system
 supplier, stock agency, vendor
 stakeholder might not "act" in any scenario
 goal: action that actor wants to accomplish
 summary goals ("above sea level"): multi-
sitting
 user goals ("sea-level"): one
sitting
 subfunctions ("below sea level"): partial
Why?
How? What?

9. 9
Goals and levels, examples
 What level are these goals at?
 withdraw money from an ATM
 purchase book from online store, and have it shipped
to user (can be cancelled while in transit)
 purchase shares of stock online using a "stock trap"
 update user's balance after a deposit
Answers:
 user goal, summary goal,
summary goal, subfunction

10. 10
Do use cases capture these?
 Which of these requirements should be
represented directly in a use case?
 Special deals may not run longer than 6 months.
 Customers only become preferred after 1 year.
 A customer has one and only one sales contact.
 Database response time is less than 2 seconds.
 Web site uptime requirement is 99.8%.
 Number of simultaneous users will be 200 max.
Answer: NONE. Most of these requirements are non-
functional, so the use cases wouldn't explicitly mention
them. The user doesn't see them directly in the
success scenario.

11. 11
Styles of use cases
1. Actor / goal list,
UML use case summary diagram
 shows all use cases in system
2. Informal use case
3. Formal use case
Let's examine each of these in detail...

12. 12
1a. Actor / goal list
 It can be useful to create a list or table of
actors and their "goals" (use cases they start):
ACTOR USE CASES INITIATED
Club Member Submit Promotion Order
Submit Regular Order
Potential Member Submit New Subscription
Past Member Submit Subscription Renewal
Membership Services Dept. Request Membership
Marketing Department Create New Monthly Promotion
Create New Seasonal
Promotion
Create New Subscription
Program
Request Promotion Reports
Request Sales Reports
Membership Services System Send New Subscription Offer

13. 13
1b. Use case summary diagram
Control System
Set limits
Calibrate
Take profile
Scan
Liaison Physicist
Hardware Specialist
Experimental
Physicist
 actor: stick-man
 use cases: ellipses name inside
 actor-case association: line
 use cases can be connected to other cases that they use

14. 14
Use case summary diagram 2

15. 15
2. Informal use case
 informal use case: a paragraph describing the
scenario
 Example:
 Customer Loses a Tape
The customer reports to the clerk that he has lost a
tape. The clerk prints out the rental record and asks
customer to speak with the manager, who will
arrange for the customer to pay a fee. The system
will be updated to reflect lost tape, and customer's
record is updated as well. The manager may
authorize purchase of a replacement tape.

16. 16
3. Formal use case
"Place an order" (User goal / Clerk)
Main scenario:
1. Clerk identifies customer, item and quantity.
2. System accepts and queues the order.
Extensions:
1a. Low credit & Customer is 'Preferred':
1a1. System gives them credit anyway.
1b. Low credit & not 'Preferred' customer:
1b1. Clerk performs Sign Up Preferred Customer
scenario and accepts only prepayment.
2a. Low on stock: Customer accepts rain-check:
2a1. Clerk reduces order to available stock level.
(goal of primary actor) (level of goal [summary, user, subfunction])
(action steps:
full sentences showing
who takes the action!
3 - 9 steps long.)
(condition causing different actions)
(action step(s)
handling those conditions)
(primary actor)
(calling another use case)

17. 17
Formal use case example

18. 18
Example use case
Use Case 12. Buy stocks over the web
Primary Actor: Purchaser (user) Scope: PAF
Level: user goal Precondition: User already has PAF open.
Guarantees: sufficient log information exists that PAF can detect what went wrong.
Success Guarantees: remote web site acknowledged purchase, user's portfolio
updated.
Main success scenario:
1. User selects to buy stocks over the web.
2. PAF gets name of web site to use (E*Trade, Schwabb, etc.)
3. PAF opens web connection to the site, retaining control.
4. User browses and buys stock from the web site.
5. PAF intercepts responses from the web site, and updates the user's portfolio.
6. PAF shows the user the new portfolio standing.
Extensions:
2a. User wants a web site PAF does not support:
2a1. System gets new suggestion from user, with option to cancel use case.
3a. ...

19. 19
Cockburn's 4 use case steps
1. Identify actors and goals
 What computers, subsystems, people will drive our system?
 What does each actor need our system to do?
 result: a list of use cases, a sketch of the system
2. Write the main success scenario
 easiest to read; everything else is a complication on this
 capture each actor's intent and responsibility
3. List the failure extensions
 usually almost every step can fail (bad credit, out of stock...)
 note failure condition separately, after main success scenario
4. Describe failure-handling
 recoverable: back to main course (low stock + reduce quantity)
 non-recoverable: fails (out of stock, or not a valued customer)
 each scenario goes from trigger to completion

20. 20
Identify actors/goals example
 Consider software for a video store kiosk that takes the
place of human clerks.
 A customer with an account can use their membership and
credit card at the kiosk to check out a video.
 The software can look up movies and actors by keywords.
 A customer can check out up to 3 movies, for 5 days each.
 Late fees can be paid at the time of return or at next checkout.
 Exercises:
 Come up with 4 use case names for such software, and draw a
UML use case summary diagram of the cases and their actors.
 Write a formal (complete) use case for the Customer Checks
Out a Movie scenario.