System Analysis and Design

©Copyright: 2019 CRICOS: 0011D TOID: 3059 Tutorial 05 Prepared by Ravinda Wijesinghe 18/08/2019 Version 01.2 Page 1 of 9

HS2011 Systems Analysis and Design

Week 05 Tutorial Activities

Creating Event Table (to represent Use Cases) and User Stories

Virtually all recent approaches to system development begin the requirements modeling activity with the

concept of a user story or a use case. These two concepts are similar in that they focus on the goals of

the user, and they show the list of functions at the appropriate level of detail.

Use cases

A use case is an activity the system performs, usually in response to a request by a user. The term use

case originated with the object-oriented approach, but today it is also used when modeling functional

requirements in the structured (traditional) approach. In weeks 5 and 6 we are focusing on the structured

approach so that a use case is basically the same as an activity or process in your activity diagram.

How to identify Use Cases in your subsystem? Several techniques are recommended for identifying use cases. One approach is to talk to all users to get

them to describe their goals in using the system. This approach is called the user goal technique. First,

list all users and think through what each type of user needs the system to do for their jobs. Then interview

each type of user and focus on their goals. By focusing on one type of user at a time, an analyst can

systematically address the problem of identifying use cases. In the user goal technique, the analyst might

start with the existing system and list all system functions that are currently included, adding any new

functionality requested by users. Then the current system functions and required functions can be used to

establish user goals.

The most comprehensive technique for identifying use cases is the event decomposition technique. This

technique focuses on identifying the events to which a system must respond and then determining how a

system must respond—the system’s use cases. When defining the requirements for a system, it is useful

to begin by asking, “What events occur that will require the system to respond?” By asking about the events

that affect the system, you direct your attention to the external environment and look at the system as a

black box. This initial perspective helps keep your focus on a high-level view of the system (looking at the

scope) rather than on the inner workings of the system. It also focuses your attention on the system’s

interfaces to outside people and other systems. End users—those who will actually use the system—can

readily describe system needs in terms of events that affect their work. So, the external focus on events is

appropriate when working with users. Finally, focusing on events gives you a way to divide (or decompose)

the system requirements into use cases so that you can study each separately.

©Copyright: 2019 CRICOS: 0011D TOID: 3059 Tutorial 05 Prepared by Ravinda Wijesinghe 18/08/2019 Version 01.2 Page 2 of 9

There are three types of events to consider when using the event decomposition technique to identify

use cases: external events, temporal events, and state events (also called internal events). The

analyst begins by trying to identify and list as many of these events as possible, refining the list while talking

with system users.

An external event is an event that occurs outside the system, usually initiated by an external agent or

actor. An external agent (or actor) is a person or organizational unit that supplies or receives data from the

system. To identify the key external events, the analyst first tries to identify all of the external agents that

might want something from the system. A classic example of an external agent is a customer. The customer

may want to place an order for one or more products. This event is of fundamental importance to an order-

processing system like the one needed by Ridgeline Mountain Outfitters (Lecture 01 case study). But other

events are associated with a customer. Sometimes a customer wants to return an ordered product, or a

customer needs to pay the invoice for an order. External events such as these are the types that the analyst

looks for because they begin to define what the system needs to be able to do. They are events that lead

to important transactions that the system must process. When describing external events, it is important to

name the event so that the external agent is clearly defined. The description should also include the action

that the external agent wants to pursue. So, the event Customer places an order describes the external

agent (a customer) and the action that the customer wants to take (to place an order for some products)

that directly affects the system. Again, if the system is an order-processing system, the system needs to

process the order for the customer.

Important external events can also result from the wants and needs of people or organizational units inside

the company (but their activities are outside the scope of your system) —for example, management

requests some information that your system needs to produce. A typical event in an order-processing

system might be Management checks order status. Perhaps managers want to follow up on an order for a

key customer, and the system must routinely provide that information.

Another type of external event occurs when external entities provide new information that the system simply

needs to store for later use. For example, regular customer reports a change in address, phone, or

employer. Usually, one event for each type of external agent can be described to handle updates to data,

such as Customer updates account information.

The second type of event is a temporal event, an event that occurs as a result of reaching a point in time.

Many information systems produce outputs at defined intervals, such as payroll systems that produce a

paycheck every two weeks (or each month). Sometimes the outputs are reports that management wants

to receive regularly, such as performance reports or exception reports. These events are different from

external events in that the system should automatically produce the required output without being told to

do so. In other words, no external agent or actor is making demands, but the system is supposed to

generate information or other outputs when they are needed.

The analyst begins identifying temporal events by asking about the specific deadlines that the system must

accommodate. What outputs are produced at that deadline? What other processing might be required at

that deadline? The analyst usually identifies these events by defining what the system needs to produce at

that time. The payroll example discussed previously might be named Time to produce biweekly payroll. The

©Copyright: 2019 CRICOS: 0011D TOID: 3059 Tutorial 05 Prepared by Ravinda Wijesinghe 18/08/2019 Version 01.2 Page 3 of 9

event defining the need for a monthly summary report might be named Time to produce monthly sales

summary report.

Temporal events do not have to occur on a fixed date. They can occur after a defined period of time has

elapsed. For example, a bill might be given to a customer when a sale has occurred. If the bill has not been

paid within 15 days, the system might send a late notice. The temporal event Time to send late notice might

be defined as a point 15 days after the billing date.

The third type of event is a state event, an event that occurs when something happens inside the system

that triggers the need for processing. State events are also called internal events. For example, if the sale

of a product results in an adjustment to an inventory record and the inventory in stock drops below a reorder

point, it is necessary to reorder. The state event might be named Reorder point reached. Often state events

occur as a consequence of external events. Sometimes they are similar to temporal events, except the

point in time cannot be defined. The reorder event might be named Time to reorder inventory, which sounds

like a temporal event.

Elementary Business Process (EBP)

No matter what approach they use to identify use cases, analysts must identify them at the right level of

detail. For example, one analyst might identify a use case as typing in a customer name on a form. A

second analyst might identify a use case as the entire process of adding a new customer. A third analyst

might even define a use case as working with customers all day, which could include adding new

customers, updating customer records, deleting customers, following up on late-paying customers, or

contacting former customers. The first example is too narrow to be useful. The second example defines a

complete user goal, which is the right level of analysis for a use case. Working with customers all day—the

third example—is too broad to be useful.

The appropriate level of detail for identifying use cases is one that focuses on elementary business

processes (EBPs). An EBP is a task that is performed by one person, in one place, in response to a

business event; that adds measurable business value, and that leaves the system and its data in a

consistent state. Some of the RMO customer support system goals that will become use cases are Create

a new order, Record order fulfilment, Create special promotion, and so forth. These use cases are good

examples of elementary business processes. Each is performed by one user in a set time and place, and

after it is completed, the system and its data are in a consistent state.

Looking at each event and the resulting Use Case

For each event, the most important information to identify is the use case to which the system needs to

respond. This information can be entered in an event table. An event table includes rows and columns,

representing events and their details, respectively. Each row in the event table records information about

one event and its use case. Each column in the table represents a key piece of information about that event

and use case. The information about an event Customer wants to check item availability is shown below.

©Copyright: 2019 CRICOS: 0011D TOID: 3059 Tutorial 05 Prepared by Ravinda Wijesinghe 18/08/2019 Version 01.2 Page 4 of 9

Figure 5.1

As mentioned, each event describes a condition – a piece of functionality. The system under development

must have the capability to successfully process the event. Therefore, the event table can be consider as

a catalogue of information about the use cases that make up the functional requirements of the system.

The list of events—together with the trigger, source, use case, response(s), and destination(s) for each

event—can be placed in an event table so that the analyst can keep track of them for later use. An event

table is a convenient way to record key information about the requirements for the information system.

User stories

User stories are favoured by highly Agile system development methodologies, and they are turned over to

the programmer analyst much earlier than use cases are. The programmer analyst designs and codes each

user story to discover needed details. The Agile development philosophy (Week 7 we will learn Agile

development) is to work directly with users and avoid doing too much documentation. In contrast, a use

case approach traditionally meant analyst completes much documentation for each use case, focusing on

detailed steps carried out by the user and the system. In practice, use cases can also be very brief for Agile

development.

A user story is usually one short sentence in the everyday language of the end-user that states what a

user does as part of his or her work. In other words, a user story describes a goal the user has when using

the system. User stories are a basic concept in Agile development because they focus on simplicity, value-

added, and user collaboration. They document the functional requirements quickly and less formally than

traditional requirements modelling by focusing on who, what, and why for each function. The users and

stakeholders are responsible for identifying the user stories.

In meetings with stakeholders, analysts encourage participants to write out each user story on an index

card or on a shared whiteboard app. The objective is to get a potential user to articulate what he or she

wants to do with the new system. A standard template helps users think through what they want and why

they want it. The standard template for a user story looks like this:

©Copyright: 2019 CRICOS: 0011D TOID: 3059 Tutorial 05 Prepared by Ravinda Wijesinghe 18/08/2019 Version 01.2 Page 5 of 9

“As a <role played>, I want to <goal or desire (feature/functionality)> so that <reason or

benefit>.”

1. Who is this functionality for? This is described by the first line “As a <role played>”. The more specific

the user – the better the story.

2. What we should create? This is described in the “I want to <goal or desire (feature/functionality)>”

3. Why is it value to the user? This is the third part of the story: “so that <reason or benefit>”.

For example, some user stories for a bank teller might be:

■ “As a teller, I want to make a deposit to quickly serve more customers.”

■ “As a teller, I want to balance the cash drawer to assure there were no errors.”

As a customer of the bank using an ATM machine, some user stories might be:

■ “As a bank customer, I want to withdraw cash and feel confident the stack of cash I get is the correct

amount.”

■ “As a bank customer, I want to deposit a check and feel confident the deposit is recorded correctly.”

A final part of a user story is the acceptance criteria. These indicate the features that must be present for

the user to be satisfied with the resulting implementation. They focus on functionality, not on features or

user-interface design.

For example, the following are the acceptance criteria for the user story “bank teller making a deposit”:

1. Customer lookup must be by name or by account number.

2. It would be nice to display a photo and signature of the customer.

3. Any check hold requirements must be indicated.

4. Current balance and the new balance must be displayed.

The programmer analyst uses the acceptance criteria to clarify the expectations of the user and to verify

the user is looking at the user story at an appropriate level of analysis. When the user story is implemented

and refined, the acceptance criteria are used for testing. Some consider it much like a contract between

the developers and the users that limits controversy later in the project.

What are key differences between Use Case and a User Story?

➢ User stories are about needs. When you write a user story, what you’re describing is a “raw” user

need. It’s something that the user needs to do in his day-to-day job. If you never build any software for

him, then that need will still exist!

➢ Use cases are about the behaviour you’ll build into the software to meet those needs. A

developer who needs to build working software should be able to read a use case and get a good

sense of what the software needs to do. It typically has a lot of detail and describes everything that the

developer needs to build in order to meet the user’s need. That’s why it needs to have a lot more detail

and be clear and unambiguous.

➢ User stories are easy for users to read. When you write a user story, what you’re concentrating on

is writing something that anyone can understand, in the language of the users. We all know that

developers have a lot more patience for talking about details of the software they’re building than users

do, which is why user stories have to be brief. A user story needs to express a complete thought in

©Copyright: 2019 CRICOS: 0011D TOID: 3059 Tutorial 05 Prepared by Ravinda Wijesinghe 18/08/2019 Version 01.2 Page 6 of 9

just a couple of sentences. (That’s also why it’s good to put them on index cards: somehow, that makes

it clearer that it’s self-contained and independent of the other user stories.)

➢ User cases describe a complete interaction between the software and users (and possibly other

systems). When you’re doing use case analysis, what you’re doing is designing a functional solution

that meets the users’ needs. It needs to be something that developers can implement. It’s possible

that one user story could spawn several use cases. And when you combine all of your use cases into

one use case document, you’ll end up with a complete description of every interaction between the

user and the software that you’re planning on building. And if your software has to interact with multiple

systems, you may end up treating those other systems as actors in your use case.

Tutorial discussion questions

Case studies

1. Review the procedures for course registration at Swinburne University. Think about the sequence that

goes on over an entire semester. What are the events that students trigger? What are the events that

your own department (e.g. Swinburne College) triggers? What are the temporal events that result in

information going to students? What are the temporal events that result in information going to

lecturers or departments? List all the events and the resulting use cases that should be included in the

system.

2. Construct an event table to identify the use cases for videotape checkout system based on the

following description.

• First, a patron will want to check out tapes and then later return them

• Sometimes a patron will neglect to return a tape by the due date and needs a reminder

after 5 days.

• Occasionally the tape will not be returned at all and should be considered lost. Usually

after 20 days after due date library will issue a lost tape charge notice to a patron and

send a copy to Bookkeeping section.

• New tapes will be received by the library from time to time.

• Library management will want information about tape to check out activity about once a

month.

3. Find out acceptance criteria for following user stories for an online store.

a) As a shopper, I want to view a list of products, so I can select some purchase.

Acceptance Criteria: ….

b) As a shopper, I want to review my cart, so I can make adjustments prior to checkouts.

Acceptance Criteria: ….

c) As a shopper, I want to check out, so I can get my products shipped to me.

©Copyright: 2019 CRICOS: 0011D TOID: 3059 Tutorial 05 Prepared by Ravinda Wijesinghe 18/08/2019 Version 01.2 Page 7 of 9

Acceptance Criteria: ….

d) As a shopper, I want to review my orders, so I can see what I’ve purchased in the past.

Acceptance Criteria: ….

4. The following two questions are related to ACEME garage.

a) Develop an event table for ACME garage. You can select two or three business processes in this

case study to develop an event table. Make sure that you identify external, temporal and state

events

b) For identified users, develop two or three user stories with acceptance criteria.

Acme Garage Lilydale

The Acme Garage specialises in repairing cars. The owner is Geoff who has worked in the field for many

years and owns 3 garages around Victoria. There are 30 full time and part-time employees currently

working in his business. In the Lilydale location, there is Mary and Kim, who looks after customer enquiries,

maintain (Create, Retrieve, Update, Delete) customer profiles, generate customer invoices, process

invoices and payments. Bill and Ben are car mechanics. Peter looks after the ordering processes.

When customers come to have their cars repaired, their initial contact is with Kim or Mary. Before Kim or

Mary accept their requests, they check the database system to ensure any previous work that the

customer has requested has been paid for satisfactorily. This can be generated by their current computer

system (when customer’s car registration number is entered into the computer, the system will provide

relevant feedback). If there are outstanding payment issues with the car registration number, the customer

will be required to pay all outstanding bills before their new requests are accepted. Customer details are

kept in a Customer file and details of each job are kept in a Job file under-car registration numbers. If all

is ok, Kim or Mary will accept the vehicles and pass the jobs to the mechanics: Bill and Ben.

They will check the car and identify problems, parts required and estimated completion time. They will need

to complete forms which include all relevant information and forward to Kim or Mary who will check the

lists and calculate the cost. They will then call the customer for confirmation. If customers agree, Mary or

Kim will notify the mechanics to go ahead and repair the car. After the job is completed, labour hours and

parts used are recorded in the Job file. The mechanics will notify Mary or Kim, who will prepare invoices

and call the customer to collect the cars. Customers can pay when they pick up cars or within 30 days.

Reminder emails will be sent to customers a week before the due date. If payment is not made within 30

days, the follow-up emails will be sent to customer advising of a 10% penalty. At the end of every week,

computer systems will generate reports, e.g., Jobs and used parts, Customer Payment report…

Acme needs to keep stock of frequently used parts (e.g., spark plugs, oil filters, air filters) which are

purchased regularly from suppliers. Acme’s suppliers are mainly local, however for some special parts for

expensive cars, they also purchase from overseas suppliers. The computer system will monitor the stock

level automatically. For those parts from local suppliers where the inventory level drops down to quantities

©Copyright: 2019 CRICOS: 0011D TOID: 3059 Tutorial 05 Prepared by Ravinda Wijesinghe 18/08/2019 Version 01.2 Page 8 of 9

of 3, then the notification will be sent to Peter, who supervisors the ordering processes. Peter has to

contact suppliers and lodge a replacement order. However, for those parts from overseas suppliers, the

notification will be sent when the inventory level drops to a quantity of 5. Less frequently used parts are

ordered as required. Once they have a reliable supplier, they tend to stick with them, so they only ever

have one supplier for each part. Supplier details are recorded and filed in the database. In the case where

stock is ordered, details of the order are recorded in the Order file. Peter works in the office and maintains

the ordering processes. All parts are recorded in the database ‘Parts’ file. The parts database should be

identified to the supplier allowing Peter to create, add, update, delete and modify both supplier and part

tables. If ordered parts haven’t arrived within 10 days, the system automatically notifies Peter, who will

contact suppliers immediately. The computer system will generate several reports by end of each month,

e.g., ordering parts with the suppliers, delivered orders, an unpaid invoice report and an unfilled orders

report. These reports will be sent to the Acme’s owner Geoff.

A copy of all orders is stored in an Order file, where invoices and parts are checked against the goods

received and are then attached to the order. If everything is correct, Peter will update the order and stock

details on the system. He will then pass the invoices, (including the cost of the parts) to Mary or Kim who

looks after accounting and payments.

Mary or Kim will pay the invoices within 10 days after the delivery. If invoices haven’t been paid in 10 days,

the auto-notification will be sent to their email to remind them that the orders are outstanding. At the end

of the month, the system will generate reports on invoices paid during the month, the parts list which

details the names of the parts, quantities, single costs and total costs.

Most of the data entry involves simple business transactions (recording customer information, job

information, parts information, supplier information, managing orders, receiving payments and making

payments). As mentioned previously, a variety of information is extracted from the system through

enquiries and the generation of periodic reports. This information is used by Geoff, the owner of the

garage, to manage the business.

©Copyright: 2019 CRICOS: 0011D TOID: 3059 Tutorial 05 Prepared by Ravinda Wijesinghe 18/08/2019 Version 01.2 Page 9 of 9

Assignment activities (individual)

This week you need to identify events and develop an event table for your subsystem. Also, you need to

identify users in your subsystem and develop user stories to demonstrate the functionalities required from

a user perspective. Possibly this can easily be done by going through your identified business processes

(Week 4).

Use MS Word to document Use Cases and User Stories. Refer to

assignment marking rubric for more information. Please also be mindful

about submission due date.