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

7. BAD USECASESGOOD USECASES PROCESS TICKET ORDERORDER TICKETS DISPLAY SCHEDULEVIEW SCHEDULE CURE : Focus on what the system needs to do in order to accomplish the actors goal. EXAMPLE :

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

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. Baseball Ticket Ordering System Select Select Game Date wDate Swipe Credit Card Select Stadium Section Happy Kiosk customer Sad Kiosk Customer Order Tickets

11. System Actor A Actor B Actor C

13. 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. View Schedule Order Tickets View Daily sales Report View Schedule Order Tickets View Daily sales Report Ticketer Kiosk customer Phone Clerk Kiosk Customer

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

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

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

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