View
217
Download
0
Category
Preview:
Citation preview
Accessible informal format.
Graphical notation is trivial.
But writing good use cases is a skillfulprocess.
ADVANTAGES
1A: System Boundary is Undefined or Inconsistent
CURE: Be explicit about the scope and label it accordingly.
#1B: System Boundary is not clear
CURE: Draw an imaginary boundary in your head
BAD USECASES GOOD USECASES
PROCESS TICKET ORDER
ORDER TICKETS
DISPLAY SCHEDULE VIEW SCHEDULE
CURE : Focus on what the system needs to do in order to accomplish the actors goal.
EXAMPLE :
#2: Use cases written with system’s (not actor’s) point of view.
Ex: Person who manages the online baseball schedule is denoted as: Schedule manager, Schedule administrator, Scheduler.
Cure:Early in the process decide and specific about the names of actors to be used.
#3: Actors names are inconsistent
#4: Too Many Use Cases
Symptom: The use case model has a very large number of use cases.
Cure: Combine use cases that describe trivial behavior that are actually fragments of the real use cases.
Example: Using “Order tickets” instead of select game date, select stadium section and swipe credit card.
Real Use Cases vs. Incidental Actions
Baseball Ticket Ordering System
Select Select Game Date
wDate
Swipe Credit Card
Select Stadium Section
HappyKiosk customer
Sad Kiosk Customer
Order Tickets
Model Needs PartitioningSystem
Actor A
Actor B
Actor C
Model with Packages
#5:The actor-to-use case relationships resemble a spider’s web.
Symptoms:◦Too many relationships between actors and use
cases.◦An actor interacts with every use case.◦A use case interacts with every actor.
Cure: Examine actors to determine whether there are more explicit actor roles, each of which would participate in a limited set of use cases.
Example: Using “Ticketer” instead of “Kiosk customer and “Phone Clerk”.
Actor Generalization
View
Schedule
Order Tickets
View Daily sales
Report
View Schedul
e
Order Tickets
View Daily sales
Report
Ticketer
Kiosk customer
Phone ClerkPhone
Clerk
Kiosk Customer
#6:Use Case Specifications Are Too Long.
Symptom: A use case specification goes on for pages.
Cure: Narrowly-Defined and Specific Use cases.
Example: Using “Create Schedule” and “View Schedule” instead of “Use Schedule”.
#7: The use case specifications are confusing
Symptom: steps in normal flow look like a computer program.
Cure: • Rewrite the steps.• Break out conditional behavior into alternate flows.• Use effective techniques to describe complex
algorithms.• Make sure the steps don’t specify implementation.
# 8: Use case doesn’t correctly describe functional entitlement
Symptom: Association between actors and use cases doesn’t describe who can do what.
This occurs for two reasons:• Use case modelers were trying to be object
oriented.• Modelers were trying to match up use cases to
user interface screen.
. Example: Process game schedule
CURE: Each actor associated with use case is entitled to perform it
Use case: 1)View Game Schedule 2)Update Game Schedule
#9: The customer doesn't understand the use cases
Symptom: The customer doesn’t know anything about
use cases.
Cure: 1. Includes the small explanation in the use
case document.2. Short training section.
.
Symptom: The use case organization doesn’t match the way the customer thinks of the problem.
Cure: Determining what strategy is easily adopted
by the customer1. Partition the use case into packages2. Ordering the use cases in chronologically.
.
Symptom: Use case is written in computer terminology
Cure: written in normal language Symptom: The customer hates the use
case Cure : Deliver what customer wants
#10: The use cases are never finished
Symptom:Use cases have to change every time the user interface changes.
Cure: The user interface design is likely to change and it is not dependent on the requirement system design.
rt
Symptom: The use cases require change every time the design
changes.Cure: Put design information in separate guidance document.
Symptom:The requirement are unknown.Cure:The use case look like simple, informal, and accessible
format this not mean that the use case is a easy.
Conclusion:
Use case is a new technique to organize the inexperienced members.
The use case is simple, easy to understand.
Use case highlights the problems before the development of model.
Recommended