Accessible informal format. Graphical notation is trivial.

2. ADVANTAGES • Accessible informal format. • Graphical notation is trivial. But writing good use cases is a skillful process.

3. 1A: System Boundary is Undefined or Inconsistent

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

5. #1B: System Boundary is not clear

6. CURE: Draw an imaginary boundary in your head

7. #2: Use cases written with system’s (not actor’s) point of view. EXAMPLE : CURE : Focus on what the system needs to do in order to accomplish the actors goal.

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

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

10. Real Use Cases vs. Incidental Actions Baseball Ticket Ordering System Order Tickets Select Select Game Date wDate Happy Kiosk customer Select Stadium Section Sad Kiosk Customer Swipe Credit Card

11. Model Needs Partitioning System Actor A Actor C Actor B

12. Model with Packages

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

14. Actor Generalization View Schedule View Schedule Order Tickets Order Tickets Ticketer Kiosk Customer View Daily sales Report View Daily sales Report Kiosk customer Phone Clerk Phone Clerk

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

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

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

18. .Example: Process game schedule

19. CURE: Each actor associated with use case is entitled to perform it Use case: 1)View Game Schedule 2)Update Game Schedule

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

21. . 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 customer 1. Partition the use case into packages 2. Ordering the use cases in chronologically.

22. . #10: The use cases are never finished • 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 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.

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

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