1. 1 Chapter 5 Modeling System Requirements Finding the Use Cases Page 159 - 176

2. Revision System Analysis: – SDLC – Techniques for Analysis: Gathering Information about the system The stakeholders Requirements An Extensive amount of information is required to properly define the systems functional and non-functional requirements 2

3. Introduction: To record these extensive amount of information: We use models – Activity Diagram, to document workflows – Workflow: is a sequence of processing steps that completely handles one business transaction or customer “request” 3

4. Objective: Developing techniques for documenting the functional requirement by creating models Remembering that the process is closely tied to the models developed during the process. 4

5. Background: p159-160 Waiters on Call is a meal delivery service that delivers complete meals from well-known restaurants. They pay wholesale price, and the customers pay retail price with service charge. They started off with only two restaurants and one delivery driver. The business expanded, and they needed a computer system to support the operations. 5

6. Call Meal-Delivery System: Interview with analyst: – What events happen when you are running your business? – Tell me what’s going on in your business, and why do you need a computerized system? – How do you handle the money? Revision: p.134 – 135: Question Themes: See next slide 6

7. 7

8. Need to understand: Understand the workflow What the system suppose to do 8

9. 9

10. 10

11. Requirements: The system must respond when certain events occur. Makes the system to DO something. This RESPOND is a USE CASE The system produces at specific points in time certain deliverables. To support the business operations you need to store information. The system must maintain information. 11

12. Events: (Occurrence) A customer calls and you place an order A driver finished a delivery, record a delivery completion A customer calls back to change an order, and you then update the order A driver reports to work, so you sign in a driver A driver submits the day’s receipts, so you reconcile the driver receipts. 12

13. The system produces at specific points in time: End-of-day deposit slips End-of-week restaurant payments Weekly sales report Monthly financial reports 13

14. To store information about: Restaurants Menu items Customers Orders Order payments Drivers 14

15. To maintain information: To add a new restaurant Changes of menus Drop a restaurant Hire a new driver Drop a driver 15

16. Procedure for object-oriented systems analysis: Step1: Identify the business events  and make an event table. Step2: Identify the use cases and  produce a use case diagram for the system. Step3: Write a use case narrative describing the system’s response to each business event. 16

17. Cont. Step4: Draw a system sequence diagram for each use case scenario. Step5: Produce a domain model showing the concepts, attributes, and associations in the problem domain of the system. Step6: Write a contract for each system operation. 17

18. Use Case: Is an activity the system carries out – Usually in response to a request 18

19. Example: Consider again our example of the Meal Deliver System: A customer calls to order Need to record the order, and relevant information Order-Entry subsystem: 19

20. 20

21. Use Case: Several Techniques: – List all users and think what the system must do for them – Start with the existing system and add any new functions requested by the users. – Users must describe their goals in using the system By asking users about their goals, you can focus on processes. See next slide: 21

22. User Goal Technique: USER/ACTORUser Goal and resulting Use Case Order ClerkLook up menu’s Create new Order Update Order DriverSign-in Collects Bill 22

23. Recognizing Events: Understanding system behavior in terms of events takes a stimulus-response perspective. Pattern of operation: – The system does nothing until triggered by an event. It sits and waits for an event to occur. – When an event occurs, the system responds as completely as possible. – After the response is finished, the system sits and waits until next event occurs. 23

24. Example: Vending Machine: – It sits in the hallway until someone drops money in the coin slot. – The purchaser presses a button to select the desired beverage – The machine then dispenses the beverage. When the coins are entered (trigger), the machine recognizes that an event has occurred. A customer wants to buy a beverage. 24

25. Vending Machine: The signal from the coin slot is the trigger. In order to response, the machine now needs two pieces of data: – The specification of the beverage – The amount paid Pressing the beverage selection button tells which drink is desired. The coin slot senses the amount paid 25

26. Example: See next slide, and identify all the components of the event table. 26

27. 27

28. Revision: What is a Use Case What are the elements of a Use Case Let’s create an ATM sysem!! 28

29. What is a Use Case? What are they? – Use cases capture the functional requirements of a system. What the system should do. It describes the behavior of the system. – Use cases describe the interactions between various actors and the system 29

30. What elements they consists of? 30

31. Let’s create an ATM system! Draw the system Identify who wants to interact with the system What are their goals? What do we need to complete the use case successfully? 31

32. 32

33. Written Use Case: For each use case: – Describe the steps involved in an interaction between an actor and the system, beginning with the primary actor (the one that initiates the use case) – Start with the main success scenario: happy path – Look for alternative paths: Exceptions: What could go wrong? Extensions: What other goal might come into play here? 33

34. Event Analysis: Event analysis is like a giant vending machine, waiting for buttons to be pushed or coins to be inserted before it springs into action. In order to respond to an event, the system or some object within it must be able to recognize that an event has occurred. 34

35. Level of analysis: To focus on EBP: – Elementary business processes: is a task performed by one person, – in one place, – in response to a business event, which adds measurable business value and – leaves the system and its data in a consistent state 35

36. To note: EBP occurs in a response to a business event An event occurs at a specific time and place, can be described by the system, and should be remembered by the system Events drive or trigger all processing that a system does. Analyzing events make sense when you define requirements by identifying use cases 36

37. Event Decomposition: Technique that first focuses on the events a system must respond to And then look at HOW a system must respond or the use case – “What events occur that will make the system to respond” You direct your attention to the external environment and see the system as a black box. 37

38. Types of Events: External Events – Occur outside the system – Usually caused by external agent Temporal Events – Occurs when system reaches a point (deadline) in time State Events – Asynchronous events responding to system trigger 38

39. 39

40. 40

41. State Events: An event that occurs when something happens inside the system that triggers the need for processing: – A sale causes the inventory level of a product to drop below the re-order level and activates a re- order Not the same as temporal events, because a point in time cannot be defined. 41

42. Case Study: The next few slides investigate events of RMO – External events – Temporal events – Event Table 42

43. 43

44. 44

45. 45

46. Example: Placing an order External-, Temporal- or State Event? What is the EVENT: Customer places an order HOW will this event take place? TRIGGER or entering a new order From where is this event taking place? SOURCE or ‘Customer’ How must the system re-act? USE case: Create new order 46

47. Problem Domain Classes: We need to STORE information: Identify “things” Relationships among “things” Attributes of “things” Domain Model Class Diagram: – Generalization/Specialization – Whole-Part hierarchies Aggregation Composition 47