Chap 04 Use Cases

7/28/2019 Chap 04 Use Cases

1/36

Chapter 4 Use Cases


2/36

Outline

Use cases

Elements of a use case

Building use cases


3/36

Previous chapter:

The process of requirements determinationresulting in the requirements definition, which

defined what the system is to do. This chapter:

How these system requirements are refined into aset of use cases---that provide more detail on:

the processes by which the system is to meet theserequirements and

the data the system needs to capture and store.


4/36

Use Case or Business Scenario

Use case is a formal way of representing

how a business system interacts with its

environment.

Illustrates the activities that are performed by the

users of the system.

an external or functional view of a business

process


5/36

Key Ideas

Use cases - are a text-based method ofdescribing and documenting complexprocesses

sometimes are called business scenarios add detail to the requirements outlined in the

requirement definition

Systems analysts and users work together to

develop use cases develop process and data models later based on

the use cases

PowerPoint Presentation for

Dennis, Wixom, & Roth

Systems Analysis andDesign, 4th Edition

Copyright 2009 John

5 - 5


6/36

Roles of Use Cases

A use case is a set of activities that produce someoutput result Describes how the system reacts to an event that

triggers the system

Anevent

can be defined as a type of signal to theprogram that something has happened.

The event is generated by external user actions such asmouse movements, mouse clicks, and keystrokes, or bythe operating system, such as a timer.

Trigger -- event that causes the use case to beexecuted Event-driven modeling everything in the

system is a response to some triggering eventPowerPoint Presentation for



Copyright 2009 John

5 - 6


7/36

Elements of a Use Case

Basic information Name, number and brief description

Trigger event that causes the use case to being External trigger some from outside the system

Temporal triggers time-based occurrences (example: The datechanges to the first day of the month)

Viewpoint of the use cases should be consistent

Major inputs and outputs Sources and destinations

Goal is to be all inclusive

Details Steps performed and the data inputs and outputs




Copyright 2009 John

5 - 7


8/36

fig_04_01


9/36

Elements of a Use Case Basic information

Name, number and brief description Trigger event that causes the use case to being

External trigger some from outside the system Temporal triggers time-based occurrences (example: The date

changes to the first day of the month)

Viewpoint of the use cases should be consistent

5 - 9


10/36

Elements of a Use Case:Basic Information

Name simple yet descriptive.

Number sequential number that serves to reference

each use case Descriptioninformation about the use cases purpose.

Importance level relative significance of the use case inthe overall system.

5 - 10


11/36

Elements of a Use Case:Basic Information

Primary actor external user that triggers the event towhich the system responds Not always refer to a person or a role

May be an organization, another IS, or a device such as an alarm or sensor

Trigger the event that causes the use case to begin External trigger such as a customer placing an order or the fire alarm ringing

Temporal trigger such as video overdue; the date changes to the first day of the month

5 - 11


12/36


Major inputs and outputs: Inputs and outputs another name is DATA FLOW

All possible inputs and outputs (even with rare occurrences)

5 - 12


13/36

Elements of a Use Case:Major Inputs and Outputs

Each step should have at least one input and at least one output. Input area give the source:

Customer provides the items to purchase as represented by the item UPC (Universal ProductCode)

Customer provides the payment and authorizes the payment (credit card or debit card) Stored data or database (called data store) details about the item such as its description,

price, sales tax

Output area give the destination: Total due the customer is informed of the amount for the purchase and is provided a receipt Receipt the customer is provided a receipt. Sales transaction the transaction is written to a sales data store. Sold item details all items purchased are recorded in a sold inventory data store.

5 - 13


14/36


Details - Steps performed

5 - 14

These steps, listed in the order in

which they are performed, are

the activities performed during

the use case, such as:

Processing all items in the cart

Accepting payment

Recording sales and inventory

data

The steps should be listed in theorder in which they are performed

Each step should be about the

same size as the others.

You might have to go back

and adjust the steps in a use

case, if the steps are of

varying size.The result of this section will give

the Information for each step

section.


15/36

Building Use Cases:

Process of Developing Use Cases

Identify the major use cases

Identify the major steps within each use case

Identify elements within steps Confirm the use case

Cycle through the above steps iteratively



Systems Analysis and

Design, 4th Edition

Copyright 2009 John

5 - 15


16/36

Confirm the use case

The users confirm that the use case is correct aswritten.

Review the use case with the users

to make sure that each step and each input andoutput are correct and that the final result of use theuse case is consistent with the final result in theevent-action list.

The most powerful approach: ask the user to role-play, or execute the use case by

using written steps in the use case.


17/36

fig_04_04


18/36


19/36

Step 1:

Identify the major use cases Begins with the requirements definition.

The process-oriented functional requirements things the systemmust do, suggest a direct action resulting from an external or temporalevent.

The information-oriented functional requirements content thesystem must have, suggest things that happen involving information ortime triggers to collect or produce information.

The top parts of the use case form should be filled --- basicinformation and inputs/outputs.

It is an iterative (repetitive) process.

Note:

A use case is a set of end-to-end activities that starts with a riggerevent and continues through many possible paths until someoutput has been produced and the system is again at rest.


20/36


21/36

fig_04_05b


22/36

fig_04_05c


23/36

Step 1:

Identify the major use cases

Activities Typical Questions Asked

Start a use case form for

each use case

If more than nine, groupinto packages

Ask who, what , and where about the tasks and their

inputs and outputs:

What are the major tasks performed?What triggers this task? What tells you to perform this

task?

What information/forms/reports do you need to perform

this task?

Who gives you these information/forms/reports?What information/forms/reports does this produce and

where do they go?

PowerPoint Presentation for Dennis,

Wixom, & Roth Systems Analysis and

Design, 4th Edition

Copyright 2009 John Wiley & Sons,

5 - 23


24/36

Step 2: Identify the major steps within

each use case

Major Steps Performed portion- Complete the detailedinformation

Focus on what an independent observer would see thesystem do in response to the event --- ex. Taking

pictures picture while performing the processes The steps should be listed in the order in which they

are performed

Each step should be about the same size as the others.

You might have to go back and adjust the steps in a usecase, if the steps are of varying size.

The result of this section will give the Information foreach step section.


25/36

Step 2: Identify the major steps within each

use case


For each use case, fill

in the major steps

needed to process theinputs and produce the

outputs

Ask how about each use case:

How do you produce this report?

How do you change the information on the report?

How do you process forms?

What tools do you use to do this step (e.g., on

paper, by email, by phone)?



Design, 4th Edition


5 - 25


26/36


27/36

fig_04_06b


28/36

fig_04_06c


29/36

Step 3:

Identify elements within steps

Information for Steps portion further define

and link the steps

Each step should have at least one input and

at least one output.

Goal: to identify the major inputs and outputs

for each step


30/36

fig_04_07a


31/36

fig_04_07b


32/36

fig_04_07c


33/36

Step 3:

Identify elements within steps


For each step, identify

its triggers and its

inputs and outputs

Ask how about each step

How does the person know when to perform this

step?What forms/reports/data does this step produce?

What forms/reports/data does this step need?

What happens when this form/report/data is not

available?



Design, 4th Edition


5 - 33


34/36

Step 4:


The users confirm that the use case is correct aswritten.

Review the use case with the users

to make sure that each step and each input andoutput are correct and that the final result of use theuse case is consistent with the final result in theevent-action list.

The most powerful approach: ask the user to role-play, or execute the use case by

using written steps in the use case.


35/36

Step 4:



For each use case,

validate that it is correct

and complete

Ask the user to execute the process using the

written steps in the use case that is, have the

user role-play the use case



Design, 4th Edition

Copyright 2009 John Wiley & Sons,5 - 35


36/36

Summary

Use cases contain all the information needed

for process modeling, but are easier for users

to comprehend

Use cases are created in an iterative cycle of

steps until they are considered accurate and

complete



Systems Analysis and

Design 4th Edition 5 36

Chap 04 Use Cases

Documents

Transcript of Chap 04 Use Cases