1. Lecture 5d: Systems Use Case Descriptions

2.  Review  Systems Use Case Descriptions  Systems Use Case Authoring SYS3662

3.  Draw Business Use Case Diagram to capture the Business Processes (WP1)  Write Business Use Case Descriptions (WP1)  Fact Finding ◦ Interviewing the Client for Technical, Functional, Data Requirements  Identify the functions of the new system  Draw Systems Use Case Diagrams (WP2) SYS3663

4.  Review  Systems Use Case Descriptions  Systems Use Case Authoring SYS3664

5.  Accompany the systems use case diagram  Lay out the sequence of interaction between the user and the system  Diagrams provide high-level view and textual description provides detail SYS3665

6.  Based on the dialog metaphor SYS3666

7.  The process of designing the overall sequences that users follow to interact with an information system  the sequence in which information is displayed to and obtained from the user SYS3667

8.  The (systems) use case descriptions provide the substance of the (systems) use case model and they are the basis for most of the …modeling work…More than 90% of the (systems) use-case model lies beneath the surface, in the textual use-case descriptions themselves. * *Use Case Modeling, Kurt Bittner & Ian Spence SYS3668

9.  “The use case description tells a story of how a system and its actors collaborate to achieve a specific goal  This collaboration takes the form of a dialog between the system and its actors  It is a step-by-step description of a particular way of using a system”* *Use Case Modeling, Kurt Bittner & Ian Spence SYS3669

10.  “Just like a story, every use case should have ◦ a clear beginning (how the actor starts the use case) ◦ Middle (how the system and actors work together) ◦ End how the use case is concluded”* *Use Case Modeling, Kurt Bittner & Ian Spence SYS36610

11.  Not a complete description of all possible ways that some task is performed  Does not say how the system is designed or implemented  Describes typical ways (or cases) of using the system* *Use Case Modeling, Kurt Bittner & Ian Spence SYS36611

12.  Systems use Case descriptions are required to define, in detail, the processing that needs to happen in each use case  The use case diagram provides a quick view of the goal of the use case by examining the case name and associations SYS36612

13.  The systems use case description must include: ◦ Who the actors are and how many of them are interacting with the system at any point in time ◦ What data is used and how ◦ All normal logic ◦ All exception and error logic SYS36613

14.  Preconditions ◦ State of the system at the start of use case  Postconditions ◦ State of the system at the end of use case  Can be included in the systems use case description SYS36614

15.  Precondition ◦ The user must have been authenticated ◦ The user must be authorized ◦ The system load is 10% below maximum  Postcondition ◦ The user’s account has been updated ◦ All transactions have been rolled back or committed SYS36615

16.  Review  Systems Use Case Descriptions  Systems Use Case Authoring SYS36616

17.  Systems use case descriptions do not pop into existence spontaneously  They begin by identifying the use case and create a brief description  This description is fleshed out until the final use case description is ready SYS36617

18. SYS36618 Discovered Briefly Described Bulleted Outline Essential Outline Detailed Description Systems Use Case Specification

19.  Through the Table identifying Functions  Through experience  Shown on a Systems Use Case diagram ◦ Place holder for the Systems Use Case description ◦ A visual index, providing a context for the descriptions SYS36619

20.  Once the Systems Use Case has been identified, it should be described  Example: Rent a Video Systems Use Cases This Systems Use Cases describes how a Video Rental Clerk uses the system to identify a customer, process a video, process the payment, produce a rental transaction and produce a receipt. SYS36620

21.  Focuses on only the most important behaviour of the system  Presents a “black box” view of the system in order to focus on getting right what the system must do  Emphasizes usability ◦ Helps describe user intent and actions, along with the observable response of the system ◦ Does not describe what is happening inside the system SYS36621

22. SYS36622 Action by ActorSystem Response Request Customer Information Display Customer Information Provide information on all videos to be rented Record Video information Provide payment detailsRecord payment details Complete TransactionRecord transaction and provide receipt

23.  The use case in point form  Very useful for generating user interfaces  Too much detail can limit the freedom of the user interface designers  Adding details might inadvertently suggest what the interface should look like SYS36623

24.  The detailed description fills in the details of the essential outline  Begins by expanding the details of the system response  Is changed to a narrative form that reads more like a story or a series of detailed steps SYS36624

25. Action by ActorSystem Response Request Customer Information Obtain customer name and enter it into system to display information on the customer. Provide information on all videos to be rented Get the list of videos to be rented and enter it into the displayed customer information form. Compute amount owing for rental and tell customer. Provide payment detailsGet credit card, enter into system, and obtain verification. Complete TransactionFinalize transaction, committing it to permanent storage and print receipt for customer. SYS36625

26. 1. The customer selects videos and presents them to the clerk. The clerk gets the customer’s name and accesses their customer information on the system. 2. The videos to be rented are entered into the customers information and the amount owing is calculated. The customer is told the amount owing. 3. ….. SYS36626

27.  Fully described use cases are: ◦ Testable ◦ Understandable ◦ Unambiguous ◦ Correct ◦ Complete ◦ attainable SYS36627

28.  A picture of what a user interface will look like  Drawn with a tool like PowerPoint  Gets feedback on the interface without building it  Ensures that the requirements are correctly understood SYS36628

29. SYS36629 Copy the following graphics to make screen layouts. Button Single-line Edit Box Radio Button (selected) Radio Button (not selected) Multi-line Edit Box -This changes its size according to the typing Check Box (selected) Check Box (not selected) Combo Box List Box Or Combo Box Dropdown Use it either way. Window or Dialog Box

30. SYS36630 OK Type your comment here. Halt and Catch Fire Recover Brilliantly Add manual comment to system log: System Recovery Options Recovery Method Cancel

31.  Layout the sequence of screens displayed to the user  Show how user can navigate from one screen to another  Each screen symbol contains: ◦ Screen name ◦ Reference number ◦ Numbers of screens user can return to SYS36631

32. SYS36632

33. SYS36633