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.