1

Chapter 5Modeling System Requirements

Finding the Use Cases

Page 159 - 176

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

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

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

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

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

Need to understand:

Understand the workflow What the system suppose to do

8

9

10

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

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

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

To store information about:

Restaurants Menu items Customers Orders Order payments Drivers

14

To maintain information:

To add a new restaurant Changes of menus Drop a restaurant Hire a new driver Drop a driver

15

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

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

Use Case:

Is an activity the system carries out– Usually in response to a request

18

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

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

User Goal Technique:

USER/ACTOR User Goal and resulting Use Case

Order Clerk Look up menu’sCreate new OrderUpdate Order

Driver Sign-inCollects Bill

22

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

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

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

Example:

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

26

27

Revision:

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

28

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

What elements they consists of?

30

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

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

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

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

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

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

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

40

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

Case Study:

The next few slides investigate events of RMO– External events– Temporal events– Event Table

42

43

44

45

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

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