1. Lecture 4 :Use cases III (UC description) 1

2. Outline CT 1414 * Nouf Aljaffan2  Concept of Use Case Description  Levels of Use Case Description  Reading and writing Use Case Descriptions

3. Use Case Diagram of the Customer Support System CT 1414 * Nouf Aljaffan3 Use Cases grouped into system modules Note: Same actor interacts with different modules

4. Use Case Description CT 1414 * Nouf Aljaffan4  Complements Use Case Diagram  A breakdown of a single use case (e.g., sequence of steps included in the function “Look up item availability”); process logic included  In contrast to Use Case Diagram, Use Case Description captures variations of a Use Case  Example: “Create new order” can be done via phone+clerk and via Internet ordering – 2 scenarios

5. Level of Use Case Description CT 1414 * Nouf Aljaffan5  Three levels of detail:  UC* Brief description  Summary of what system does in response to actor’s actions  UC Intermediate description  Shows steps in use case, if-then  UC Full description  Includes Brief description, expands intermediate description, shows scenarios * UC=Use Case

6. Brief Description of Create New Order Use Case CT 1414 * Nouf Aljaffan6 Same description that is usually captured in initial Use Case Diagrams

7. Intermediate Use Case Description CT 1414 * Nouf Aljaffan7 Telephone Order Scenario for Create New Order Use Case

8. Full Use Case Description CT 1414 * Nouf Aljaffan8  Shows steps (“Flow of Events”) broken down to the actor and the system side – useful!

9. Full Use Case Description Telephone Order Scenario for Create New Order Use Case CT 1414 * Nouf Aljaffan9

10. Use-Cases – Common Mistakes 10  Complex diagram  No system  No actor  Too many user interface details  “User types ID and password, clicks OK or hits Enter”  Very low goal details  User provides name  User provides address  User provides telephone number  …

11. Writing Use Case Descriptions CT 1414 * Nouf Aljaffan11 1. Select a use case 2. Write abbreviated full description (Use case name, Scenario (if any), Business Event, Actors, Flow of steps, Exception conditions) 3. For figuring Flow of steps, - Keep in mind general system model: Input-Processing-Output - Steps should be at nearly the same level of abstraction (each makes nearly same progress toward use case completion) 4. For figuring exception conditions, focus on if-then logic.

12. Combining Processes CT 1414 * Nouf Aljaffan12  Number Limit:  The diagram should have between 3 to 10 base use-case. No more than 15 use cases (base + included + extending).  Abstraction:  All use-cases should be in similar abstraction levels.  Size:  Use cases should be described in half a page or more.  Interaction:  Use-cases which are carried out as part of the same interaction.

13. Dividing Processes CT 1414 * Nouf Aljaffan13  Size:  If a use-cases takes more than a page, consider include/extend  Weak dependency:  If the dependency between two parts of a use-case is weak, they should be divided.

14. More Guidelines CT 1414 * Nouf Aljaffan14  Factor out common usages that are required by multiple use cases  If the usage is required use >  If the base use case is complete and the usage may be optional, consider use >  A use case diagram should:  contain only use cases at the same level of abstraction  include only actors who are required