2. Recall: Iterative development process
http://en.wikipedia.org/wiki/File:Iterative_development_model_V2.jpg
We are here
3. Recall: FURPS+ Classification of Requirements
• 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,
internationalization, configurability
4. Recall: UP Requirements Artifacts
• Use-case model: (we’ll discuss in a minute,
but primarily functional req.)
• Supplementary specification: non-
functional req. and functional req. that
don’t fit in UCs
• Glossary: Terms and definitions
(surprisingly important!)
• Vision: Overview of requirements focused
on the business case for the system
• Business rules: Rules and laws from the
problem domain that must be followed
http://flic.kr/p/6meLX
5. Today, we’re going to learn about
Use Cases (Ch. 6.0–6.10)
But first, we must introduce a case study…
http://flic.kr/p/anWc2v
6. Larman Case Study:
NextGen POS System
• POS = Point of Sale
• Computerized application used
(in part) to record sales and
handle payments
• Typically used in retail store
• Includes hardware
– E.g.: barcode scanner
• Interfaces with various service
applications
– E.g.: tax calculator
• Must be fault tolerant
– E.g.: handle cash as backup
http://flic.kr/p/4UtQzk
http://flic.kr/p/4UtQzk
7. Use case: text stories of some actor
using a system to meet goals
Process Sale: A customer arrives at a checkout
with items to purchase. The cashier uses the POS
system to record each purchased item. The
system presents a running total and line-item
details. The customer enters payment
information, which the system validates and
records. The system updates inventory. The
customer receives a receipt from the system and
then leaves with the items.
8. Actor: something with behavior, such as a
person, computer, organization
Scenario (or use case instance): specific
sequence of actions and interactions
between actors and the system
Use case: collection of related success and
failure scenarios that describe an
actor using a system to support a goal
Let’s push the UC definition a bit further…
9. Handle Returns:
Main success scenario: A customer arrives at a checkout with
items to return. The cashier uses the POS system to record each
returned item…
Alternative scenarios:
•If the customer paid by credit, and the reimbursement
transaction to their credit account is rejected, inform the
customer and pay them with cash.
•If the item identifier is not found in the system, notify the
cashier and suggest manual entry of the identifier code (perhaps
it is corrupted).
•If the system detects failure to communicate with the external
accounting system…
The first UC example I showed used a “brief” format;
here’s one that uses a “casual” format
10. 3 kinds of actors
• Primary actor: has user goals fulfilled through using
the system
– Identify to find user goals
• Supporting actor: provides a service to the system
– Identify to clarify external interfaces/protocols
• Offstage actor: has an interest in the behavior of the
UC, but is not directly involved (e.g., US Government)
– Identify to ensure all necessary interests are identified
11. Use-Case Model: set of all written use
cases; it is a model of system’s
functionality and environment
Yet another definition…
The UC Model is just one type of requirements artifact
12. Why create use cases?
• Easy for customers to
understand/contribute
– Help communication
• Emphasize user goals and
perspectives
– Keep the requirements focused on
the customer
http://flic.kr/p/5dFxK2
Aha!
13. Which UCs to write/refine first?
• High value
– I.e.: Represent system’s core functionality
• High risk
• Architecturally significant
http://en.wikipedia.org/wiki/File:Iterative_development_model_V2.jpg
14. Activity: Creating use cases
http://flic.kr/p/5dfuqL
http://en.wikipedia.org/wiki/File:Barclayscyclehire.jpg
16. Summary
• Use cases
• Actors and scenarios
• Styles:
– “Brief”
– “Casual”
– “Fully dressed”
• The Use Case Model
http://flic.kr/p/YSY3X
Editor's Notes
Recall the requirements you collected last time.
Write “brief” use cases
Exchange UCs with other teams
Answer questions
What actors? Primary? Supporting? Offstage?
What goals?
Critique
Now, each team member expand one UC to “casual”
Exchange UCs with other teams
Answer questions
What alternative flows?
Critique
