System Analysis and Design

©Copyright: 2019 Tutorial 06 Prepared by Ravinda Wijesinghe 25/08/2019 Version 01.2 Page 1 of 14

HS2011 Systems Analysis and Design

Week 06 Tutorial Activities

Creating Dataflow Diagrams

Before we move into Dataflow Diagrams, let us explore the key difference between structured and object-

oriented views of activities/ use cases. As I explained in week 2, structured and objected-oriented

approaches are the two main approaches that system analysts use to design new information systems.

Structured and object-oriented (OO) views of activities/use cases

The structured and OO approaches to system development differ in how a system’s response to an event

is modeled and implemented. The structured approach views a system as a collection of processes, some

performed by people and some performed by computers. Structured computer processes are much like

procedural computer programs—they contain instructions that execute in a sequence. When the process

executes, it interacts with stored data, reading data values and then writing other data values back to the

data file. The process might also interact with people, such as when an instruction asks the user to input a

value or it displays information to the user on the computer screen. The structured approach to systems,

then, involves processes, stored data, inputs, and outputs. When modeling what the system does in

response to an event, the structured approach includes processing models that emphasize these system

features.

In contrast, the OO approach views a system as a collection of interacting objects. The objects are based

on the things in the problem domain discussed in last week lecture. Objects are capable of behaviors (called

methods) that allow them to interact with each other and with people using the system. One object asks

another object to do something by sending it a message. There are no conventional computer processes

or data files per se. Objects carry out the activities and remember the data values. When modeling what

the system does in response to an event, the OO approach includes models that show objects, their

behavior, and their interactions with other objects.

Dataflow Diagrams

The structured approach to information system development describes activities as processes carried out

by people or computers. A graphical model that has proven to be quite valuable for modeling processes is

the data flow diagram. There are other process models, such as the activity diagrams used to understand

business processes, but the data flow diagram is the most commonly used process model.

A data flow diagram (DFD) is a graphical system model that shows all of the main requirements for an

information system in one diagram: inputs and outputs, processes, and data storage. Everyone working on

a development project can see all aspects of the system working together at once with the DFD. That is

©Copyright: 2019 Tutorial 06 Prepared by Ravinda Wijesinghe 25/08/2019 Version 01.2 Page 2 of 14

one reason for its popularity. The DFD is also easy to read because it is a graphical model and because

there are only five symbols to learn (see Figure 6-1). End users, management, and all information systems

workers typically can read and interpret the DFD with minimal training.

Figure 6 -1

Figure 6-2 shows an example of a data flow diagram representing a portion of the Ridgeline Mountain

Outfitters (RMO) customer support system. The square is an external agent, Customer, the source and

destination for some data outside the system. The rectangle with rounded corners is a process named

Look up item availability that can also be referred to by its number, 1. A process defines rules for

transforming inputs to outputs. The lines with arrows are data flows. Figure 6-2 shows two data flows

©Copyright: 2019 Tutorial 06 Prepared by Ravinda Wijesinghe 25/08/2019 Version 01.2 Page 3 of 14

between Customer and process 1: a process input named Item inquiry and a process output named Item

availability details. The final symbol—the flat, open-ended rectangle—is a data store (i.e. entity in entity

relationship diagram/ ERD). Each data store represents a file or part of a database that stores information

about a data entity. In this example, data flows (lines with arrows) point from the data stores to the process,

meaning that the process looks up information in the data stores named Catalog, Product item, and

Inventory item.

Figure 6 – 2: A DFD showing the process Look

up item availability (a DFD fragment from the

RMO case)

Key Terms:

External Agent: A person, organization, or another system outside the system boundary, that supplies

data inputs or accepts data outputs.

Process: a symbol on a DFD that represents an algorithm or procedure by which data inputs are

transformed into data outputs.

Data Flow: An arrow on a DFD that represents data movement among processes, data stores, and external

agents.

You might recognize that the process in Figure 6-2 corresponds to a use case in the event table for RMO

shown in Lecture 5 slides (Slide 24). The event was Customer wants to check item availability, the trigger

was Item inquiry, the source was Customer, the response was Item availability details, and the destination

for the response was Customer. Therefore, the data flow diagram shows the system use case in response

to this one event in graphical form.

But another piece of information on the DFD is not in the event table: the data stores containing information

about an item’s availability. Each data store in Figure 6-2 represents a data entity from the entity-

relationship diagram (ERD) shown in Figure 6-3. The process on the DFD uses information that we provided

by including these data entities and their attributes in the ERD for the system. Therefore, before creating

DFD diagrams we must first determine data stores required for the system. The data flow diagram

integrates processing triggered by events with the data entities modeled using the ERD.

©Copyright: 2019 Tutorial 06 Prepared by Ravinda Wijesinghe 25/08/2019 Version 01.2 Page 4 of 14

Figure 6 – 3: RMO customer support system entity relationship diagram (ERD) without attributes

Data flow diagrams and levels of abstraction

Many different types of data flow diagrams are produced to show system requirements. The example just

described is a DFD fragment, showing one process in response to one event. Other data flow diagrams

show the processing at either a higher level (a more general view of the system) or at a lower level (a more

detailed view of one process). These differing views of the system (high level versus low level) are called

levels of abstraction.

Data flow diagrams can show either higher-level or lower-level views of the system. The high-level

processes on one DFD can be decomposed into separate lower-level, detailed DFDs. Processes on the

detailed DFDs can also be decomposed into additional diagrams to provide multiple levels of abstraction.

Figure 6-4 shows how DFDs at each level of detail provide additional information about one process at the

next higher level. The topmost DFD shows the most abstract representation of the course registration

system as a single process (This is called the context diagram). The middle DFD shows internal details of

a context diagram process. The bottom DFD shows internal details of process 1 in the middle DFD. Each

DFD abstraction level is described further in the following sections.

©Copyright: 2019 Tutorial 06 Prepared by Ravinda Wijesinghe 25/08/2019 Version 01.2 Page 5 of 14

Figure 6 -4: Layers of DFD abstraction for a course registration system

Context Diagram

A context diagram is a DFD that describes the most abstract view of a system. All external agents and all

data flows into and out of the system are shown in one diagram, with the entire system represented as one

process. The topmost DFD in Figure 6-4 is a context diagram for a simple university course registration

system that interacts with three external agents: Academic department, Student, and Faculty member.

Academic departments supply information on offered courses, students request enrolment in offered

courses, and faculty members receive class lists when the registration period is complete.

A context diagram clearly shows the system boundary. The system scope is defined by what is represented

within the single process and what is represented as external agents. External agents that supply or receive

©Copyright: 2019 Tutorial 06 Prepared by Ravinda Wijesinghe 25/08/2019 Version 01.2 Page 6 of 14

data from the system are outside the system scope, and everything else is inside the system scope. The

context diagram does not usually show data stores because all of the system’s data stores are considered

to be within the system scope (that is, part of the internal implementation of the process that represents the

system). However, data stores may be shown when they are shared by the system being modeled and

another system.

The context diagram is usually created in parallel with the event table described in Lecture 5. Each trigger

for an external event becomes an input data flow, and the source becomes an external agent. Each

response becomes an output data flow, and the destination becomes an external agent. Triggers for

temporal events are not data flows, so there are no input data flows for temporal events. Note that the

context diagram DFD can be created directly from the event table. The two models provide alternative

views of the same system requirements information.

DFD Fragments

A DFD fragment is created for each use case triggered by an event in the event table. Each DFD fragment

is a self-contained model showing how the system responds to a single event. The analyst usually creates

DFD fragments one at a time, focusing attention on each part of the system. The DFD fragments are drawn

after the event table and context diagram are complete.

Figure 6-5 shows the three DFD fragments for the simple course registration system. Each DFD fragment

represents all processing for a use case triggered by an event within a single process symbol. The

fragments show details of interactions among the process, external agents, and internal data stores. The

data stores used on a DFD fragment represent entities on the ERD. Each DFD fragment shows only those

data stores that are actually needed to respond to the event.

Figure 6-5: Three DFD fragments for the course registration system

©Copyright: 2019 Tutorial 06 Prepared by Ravinda Wijesinghe 25/08/2019 Version 01.2 Page 7 of 14

The Event-Partitioned System Model (Level 0 Diagram)

All of the DFD fragments for a system or subsystem can be combined on a single DFD called the event-

partitioned system model, or diagram 0. Figure 6-6 shows how the three course registration system DFD

fragments shown in Figure 6-5 are combined to create diagram 0.

Figure 6-6: Combining DFD fragments to create the event-partitioned system model for the course

registration system

Diagram 0 is used primarily as a presentation tool. It summarizes an entire system or subsystem in greater

detail than does a context diagram. However, analysts often avoid developing diagram 0 because:

• The information content duplicates the set of DFD fragments.

• The diagram is often complex and unwieldy, particularly for large systems that respond to many

events.

As we’ll discuss in Lecture 6, redundancy and complexity are two DFD characteristics that analysts should

avoid whenever possible.

©Copyright: 2019 Tutorial 06 Prepared by Ravinda Wijesinghe 25/08/2019 Version 01.2 Page 8 of 14

Example: RMO Data flow diagrams

Normally, data flows and external agents on the context diagram are taken directly from the event table as

discussed previously, but because the RMO customer support system responds to 20 events, this figure

combines data flows for some events for simplicity. In a smaller system example with 10 to 15 events, you

should include all data flows on the context diagram.

When a system responds to many events, it is commonly divided into subsystems (as you do in your case

organization), and a context diagram is created for each subsystem. Figure 6-7 divides the RMO customer

support system into subsystems based on use case similarities, including interactions with external agents,

interactions with data stores, and similarities in required processing. Figure 6-8 shows the context diagram

for the order-entry subsystem. Note that all data flows from the event table for this subsystem are shown

on the DFD.

Figure 6-7: RMO Customer Support System

©Copyright: 2019 Tutorial 06 Prepared by Ravinda Wijesinghe 25/08/2019 Version 01.2 Page 9 of 14

Figure 6-8: A context diagram for the RMO order-entry subsystem

Figure 6-9 shows the DFD fragments for the RMO order-entry subsystem. Note that there are five DFD

fragments, one for each order-entry subsystem use case listed in Figure 6-7.

Figure 6-9: DFD fragments for the RMO order-entry subsystem

Similarly, Figure 6-10 shows the RMO order-entry subsystem diagram 0, the result of combining the DFD

fragments from Figure 6-9. To simplify the diagram and make it more readable, the seven data stores in

Figure 6-9 are collapsed into a single data store in Figure 6-10. Recall that diagram 0 is just used as a

presentation aid. The DFD fragments show which processes interact with which individual data stores.

©Copyright: 2019 Tutorial 06 Prepared by Ravinda Wijesinghe 25/08/2019 Version 01.2 Page 10 of 14

Figure 6-10: An event-partitioned model of the order-entry subsystem (diagram 0)

Decomposition to See One Activity’s Detail

Some DFD fragments involve a lot of processing that the analyst needs to explore in more detail. As with

any modeling step, further decomposition helps the analyst learn more about the requirements while also

producing needed documentation. Figure 6- 11 shows an example of a more detailed diagram for RMO

DFD fragment 2, Create new order. It is named diagram 2 because it shows the “insides” of process 2. The

subprocesses are numbered 2.1, 2.2, 2.3, and 2.4. The numbering system does not necessarily imply

sequence of subprocess execution, though.

©Copyright: 2019 Tutorial 06 Prepared by Ravinda Wijesinghe 25/08/2019 Version 01.2 Page 11 of 14

Figure 6-11: A detailed diagram for Create new order (diagram 2)

The diagram decomposes process 2 into four subprocesses: Record customer information, Record order,

Process order transaction, and Produce confirmation. These subprocesses are viewed as the four major

steps required to complete the activity. This decomposition is just one way to divide up the work. Another

analyst might arrive at a different solution.

The first step begins when the customer provides the information making up the New order data flow. The

New order data flow contains all of the information about the customer and the items the customer wants

to order. If the customer is new, process 2.1 stores the customer information in the data store named

Customer (creating a new customer record or updating existing customer information as required).

Remember that the data store represents the customer data entity on the ERD developed in Figure 6 – 3.

Process 2.1 then sends the rest of the information about the order, a data flow named Order details, on to

process 2.2.

©Copyright: 2019 Tutorial 06 Prepared by Ravinda Wijesinghe 25/08/2019 Version 01.2 Page 12 of 14

Process 2.2 takes the Order details data flow and creates a new order record by adding data to the Order

data store. Then for each item ordered, the stock on hand and the current price are looked up in the Product

item and Inventory item data stores. If adequate stock is on hand, an order item record is created for that

item, and the stock on hand for the inventory item record is changed. If three items are ordered, one order

record is created and three order item records are created.

Process 2.2 adds up the total amount due for the order (price times quantity for each item) and sends the

data flow named Transaction details to process 2.3 to record the transaction. Transaction details include

the order number, amount, and credit card information. Process 2.3 needs a real-time link to a credit bureau

to get a credit authorization for the customer’s credit card. This needs to be a real-time link rather than a

data flow because data needs to flow back and forth rapidly while the process is executing. If the credit

card is approved, a record of the transaction is created in the Order transaction data store, and a data flow

for the transaction goes directly to the bank.

The final process produces the order confirmation for the customer and the order details that go to shipping.

Using the order number, process 2.4 looks up data on the Order, the Customer, and each Order item (plus

the item description from the Product item) and produces the required outputs.

©Copyright: 2019 Tutorial 06 Prepared by Ravinda Wijesinghe 25/08/2019 Version 01.2 Page 13 of 14

Tutorial discussion question

This week’s tutorial activities will be based on ‘Acme Garage Lilydale’. Please complete the following

diagrams for Car Service Management System:

• Produce a context diagram and level 0 data flow diagram (DFD).

• Pick up a process in level 0 DFD and develop a level 1 DFD.

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 look 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 customer to collect the cars. Customers can pay when they pick up the 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 need 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 of

3, then 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 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

©Copyright: 2019 Tutorial 06 Prepared by Ravinda Wijesinghe 25/08/2019 Version 01.2 Page 14 of 14

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

look 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.

Assignment activities (individual) - Construct context diagram, level 0

diagram, and one lower-level diagrams for your subsystem

In this week you need to continue your project activities with your event table that you have created in

last week. Use your event table to construct context diagram, level 0 diagram and one lower level dfd

diagrams for your sub system.

Use Draw.io to draw your DFD diagrams. Refer to assignment marking rubric

for more information. Please also be mindful about submission due date.