A textual description of a set of actions defining interactions betweeen an actor and the system to achieve a goal
flow of events
any error conditon and/or alternative flow
Use cases go hand-in-hand with requirements
flow = a sequence of steps describing an interaction between a user and a system
A use case describes a set of flows that together accomplish a specific user “goal”
a flow pin right
a flow pin wrong -> pin wrong 3times
Types of flows:
Basic flow -> "happy day" scenario 所有操作都合法
alternative flow -> the goal is achieved, but in an alternative way
exception flow -> the goal is not achieved
3. Why Use case
Map well to design and implementation constructs
Make it easy to verify/validate ad design and implementation against user goals
4. Why not use case
Not good for specifying
Represent external entities that interact with the system
Another software system
A use case is initiated by an actor (primary actor) to invoke a certain functionality in the system
A use case is a dialogue between actors and the system
actor -> posts on facebook
actor -> text through SNS
6. Indentifying Actors
Actors are discovered
by reading system documents
by talking with customers and domain experts
Useful questions for identifying actors:
Who uses the system?
Who installs the system?
Who starts up the system?
Who shuts down the system?
What other devices and external systems work directly with the system?
Who gets information from this system?
Who provides information to the system?
Does anything happen automatically at a preset time?
Who is interested in a certain requirement?
Where in the organization is the system used?
Who will benefit from the use of the system?
Who will support and maintain the system?
Does the system use an external resource?
Does one person play several different roles?
Do several people play the same role?
Does the system interact with a legacy system
United Airline apps
2. How to identify use cases
What functions will the actor want from the system?
What are the tasks of each actor?
Does the system store information? What actors will create, read, update, or delete (CRUD) that information?
What use cases will support and maintain the system?
Can all functional requirements be performed by the use cases?
Scope of a use case
use audience-friendly terminology
what not how
How the use case starts and ends
The interactions (in sequence) between use case and actors
What data is needed by/exchanged during the use case
Alternative/exception flows (if applicable)
3. How to Build a Use Case
Name use case
Describe Basic Flow
Add variations, if applicable
Use Case Template
4. Use case diagram
A graphical view of actors, use cases, and their interactions
There is generally one use case model per system, consisting of:
Use case diagrams (one or more)
Textual descriptions of use cases
Use cases are used as a unifying thread throughout development
Use cases are used as a communication/understanding tool among diverse stakeholders
A Variety of Readers:
Marketing personnel, human factors engineers, specialty engineers