Chapter 5 Modeling System Requirements

1. Chapter 5Modeling 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

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”

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.

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.

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

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

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.

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.

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

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

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

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 usecase diagram for the system. • Step3: Write a use case narrative describing the system’s response to each business event.

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.

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

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:

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:

22. User Goal Technique:

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.

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.

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

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

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

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

30. What elements they consists of?

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?

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?

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.

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

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

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.

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

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.

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

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

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