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.