7/17/12

ADVANTAGES

Accessible informal format. Graphical notation is trivial.

But writing good use cases is a skillful process.

7/17/12

1A: System Boundary is Undefined or Inconsistent

7/17/12

CURE: Be explicit about the scope and label it accordingly.

7/17/12

#1B: System Boundary is not clear

7/17/12

CURE: Draw an imaginary boundary in your head

7/17/12

#2: Use cases written with systems (not actors) point of view.
EXAMPLE :
BAD USECASES PROCESS TICKET ORDER DISPLAY SCHEDULE GOOD USECASES ORDER TICKETS VIEW SCHEDULE

CURE : Focus on what the system needs to do in order to accomplish the actors goal.
7/17/12

#3: Actors names are inconsistent

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.

7/17/12

#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.

7/17/12

Real Use Cases vs. Incidental Actions

Baseball Ticket Ordering System
Order Tickets

Happy Kiosk customer

Game Date Select wDate Stadium Section Swipe Credit Card

Selec t Select

Sad Kiosk Custo 7/17/12 mer

Model Needs Partitioning

Syst em

Actor A

Actor C

Actor B

7/17/12

Model with Packages

7/17/12

#5:The actor-to-use case relationships resemble a spiders 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.
7/17/12

Actor Generalization
View Schedul e Order Tickets

View Schedul e Order Tickets

Kiosk Custo mer

View Daily sales Report

Ticket er

View Daily sales Report

Phone Clerk

Kiosk custo mer

Phone Clerk
7/17/12

#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/17/12

#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 dont specify implementation. 7/17/12

# 8: Use case doesnt correctly describe functional entitlement

Symptom: Association between actors and use cases doesnt 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.

7/17/12

Example: Process game schedule

7/17/12

URE: Each actor associated with use case is entitled perform it

Use case: 1)View Game Schedule 2)Update Game Schedule

7/17/12

#9: The customer doesn't understand the use cases

Symptom: The customer doesnt know anything about use cases. Cure: 1. Includes the small explanation in the use case document. 2. Short training section.
7/17/12

Symptom: The use case organization doesnt match the way the customer thinks of the problem. Cure: Determining what strategy is easily adopted by the customer 1. Partition the use case into packages 2. Ordering the use cases in chronologically.
7/17/12

#10: The use cases are never finished

Symptom: Use case is written in computer terminology Cure: written in normal language Symptom: Symptom: The customer hates time the user Use cases have to change every the use case interface changes. Cure : Deliver what customer wants

Cure: The user interface design is likely to change and it is not dependent on the requirement system design.

7/17/12

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.

7/17/12

rt

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.

7/17/12

7/17/12