System Analysis and Design

©Copyright: 2017 Tutorial 07 Prepared by Ravinda Wijesinghe 1/09/2019 Version 01.3 Page 1 of 8

HS2011 Systems Analysis and Design

Week 07 Tutorial Activities

Creating Data dictionary items (Dataflow descriptions, Datastore

descriptions and process descriptions)

This week we are focusing on how to create data dictionary items for your subsystem based on structured

requirement models that you have created up to week 06.

As we discussed in weeks 5 and 6, data flow diagrams graphically summarize interactions among three

types of internal system components—processes, data flows, and data stores—but additional details about

each component need to be described as part of the data dictionary. When creating a data dictionary, first,

each lowest level process needs to be described in detail. In addition, the analyst needs to define each

data flow in terms of the data elements it contains. Datastores also need to be defined in terms of the data

elements. Finally, the analyst also needs to define each data element.

Process descriptions

Each process on a DFD must be defined formally. There are several options for process definition, including

one that has already been discussed: process decomposition. As discussed previously, in a process

decomposition, a higher-level process is formally defined by a DFD that contains lower-level processes.

These lower-level processes may, in turn, be further decomposed into even lower-level DFDs.

Eventually, a point is reached at which a process doesn’t need to be defined further by a DFD. This point

occurs when a process becomes so simple that it can be described adequately by other methods: structured

English, decision tables, or decision trees (in this course we mainly focusing on the structured English way

of process definitions). With each method, the process is described as an algorithm and an analyst chooses

the most appropriate presentation format by determining which is most compact, readable, and

unambiguous. In most cases, structured English is the preferred method.

Structured English uses brief statements to describe a process very carefully. Structured English looks a

bit like programming statements but without references to computer concepts. Rules of structured

programming are followed, and indentation is used for clarity. For example, a simple set of instructions for

processing ballots after a vote is shown in Figure 7-1. Some statements are simply instructions. Other

statements repeat instructions. Still, other statements direct the program to execute one set of instructions

or the other. The procedure always starts at the top and ends at the bottom. Therefore, the rules of

structured programming apply. Note, though, that a process described by structured English isn’t

necessarily a computer program—it might be done by a person—so it is a logical model. It is unambiguous,

so anyone following the instructions will arrive at the same result.

©Copyright: 2017 Tutorial 07 Prepared by Ravinda Wijesinghe 1/09/2019 Version 01.3 Page 2 of 8

Figure 7 – 1

An example of a process description for the RMO Customer Support Sub System (CSS) is shown in Figure

7-2. Note how the process description provides more specific details about what the process does.

Figure 7 – 2

©Copyright: 2017 Tutorial 07 Prepared by Ravinda Wijesinghe 1/09/2019 Version 01.3 Page 3 of 8

Data Flow Definitions

A data flow is a collection of data elements, so data flow definitions list all the elements. For example, a

simplified New order data flow (to process 2.1 in Figure 7-2) consists of a customer name, credit card

number, and a list of catalogue item numbers and quantities. Some of these elements are actually

structures of other elements, such as a customer name consisting of first name, middle initial, and last

name. The system stores most of these data elements, so they coincide with the attributes of data entities

included in the ERD.

Sometimes, data flow definitions contain a more complex structure. In the New order example, each data

flow consists of many catalogue items and quantities (a repeating group). It is important to document this

structure. The notations for data flow definitions vary. One approach is simply to list the data elements, as

shown in Figure 7-3. The elements that can have many values are indicated. Another approach uses

algebraic notation, such as that shown in Figure 7-4. The data flow “equals” or “consists of” one element

plus another element and so on. Groups of elements that can have many values are enclosed in curly

braces. This example shows New order “equals” the customer name “plus” customer address “plus” credit

card information “plus” “one or more” inventory item number and quantity. In this example, the customer

name can be defined separately as a structure of elements. Figure 7-5 lists notations commonly used in

data flow descriptions.

Alternative 1: Figure 7 – 3 Data flow definitions simply listing elements

Alternative 2: Figure 7 – 4 Algebraic notation for data flow definition (New-Order)

©Copyright: 2017 Tutorial 07 Prepared by Ravinda Wijesinghe 1/09/2019 Version 01.3 Page 4 of 8

Figure 7 – 5 Dataflow notations

Please refer Lecture 06 for more examples regarding algebraic notation style of dataflow definitions.

Data Store Definitions

Because a datastore on the DFD represents a data entity on the ERD, no separate definition is typically

needed (except perhaps a note referring the reader to the ERD). If data stores aren’t linked to an ERD, the

analyst simply defines the data store as a collection of elements (possibly with a structure) in the same way

data flows are defined.

Data Element Definitions

Data element definitions describe a data type, such as string, integer, floating-point, or Boolean. Each

element should also be described to indicate specifically what it represents. Sometimes these descriptions

are very specific. Date of sale might be defined as the date the payment for the order was received.

Alternately, the date of sale might be the date an order is placed. Sometimes, different departments in the

same company have different definitions for the same element, so it is very important for the analyst to

confirm exactly what the element means to users.

Other parts of a data element definition vary depending on the type of data. A length is usually defined for

a string. For example, a middle initial might be one character maximum, but how long should a first name

be? Numeric values usually have a minimum and maximum value that can be defined as a valid range.

Sometimes, specific values are allowed for the element, such as valid codes. If the element is a code, it is

important to define the valid codes and their meaning. For example, code A might mean ship immediately,

code B might mean hold for one day, and code C might mean hold shipment pending confirmation. Some

sample data element definitions are shown in Figure 7-6.

©Copyright: 2017 Tutorial 07 Prepared by Ravinda Wijesinghe 1/09/2019 Version 01.3 Page 5 of 8

Figure 7 – 6 Data element definitions

Analysts need to maintain a central store of all these definitions as a project reference and to ensure

consistency. A data dictionary is a repository for definitions of data flows, data stores, and data elements.

A data dictionary may be a simple loose-leaf notebook or word processing file in smaller development

projects. In larger projects, a project management or documentation tool usually holds the data dictionary.

The data dictionary may also hold process descriptions.

Tutorial discussion question

Q1

The following questions relate to a library. Each of the questions represents only one event. For each

event provide a dataflow dictionary description of the dataflows.

a) A new customer registers to join a library. She provides her name, date of birth, address and phone

number. These details are recorded and she is issued with a membership card which has her name

and membership number and date of membership.

b) A member borrows books from the library. She passes her membership card across a scanner

which records her membership number. She then scans the books. The system obtains the book

numbers from the labels on the books. When finished, the system records the loans and issues a

borrowing slip to the member which includes the membership number, titles of the books borrowed

and due date for each book. Each book has its own due date as this can vary from book to book.

c) A member returns her books. The librarian scans the books for the book numbers. Borrowing

records are updated. The system alerts the librarian if a book has been reserved and provides the

©Copyright: 2017 Tutorial 07 Prepared by Ravinda Wijesinghe 1/09/2019 Version 01.3 Page 6 of 8

membership number and name of the member who reserved the book. If the book was overdue

then a fine is recorded against the member.

d) A member is browsing the book catalogue. She finds a book she would like to reserve and selects

the book for reservation. If the book is available in the library the system replies with a message

“Book available” else it records a reservation for that book.

e) Each evening at midnight, the library system automatically runs a program that finds book loans

that are overdue. The system determines the member who has borrowed the book and sends an

email to the member. The email includes the member number, member name, the title of the book

borrowed and the due date of the book plus a message requesting the book be returned.

f) A member has been issued a fine. The member pays the fine and the librarian records the amount

paid. The payment is recorded and a receipt is issued which details the member number and name,

amount paid and date paid. If there is still any amount outstanding the receipt also includes the

outstanding amount.

Q2:

The following questions are based on ‘Acme Garage Lilydale’. Please complete the following for proposed

Car Service Management System:

• Provide 3 dataflow definitions based on 3 events.

• Provide one process description

• Provide 3 data store and related data element descriptions.

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.

©Copyright: 2017 Tutorial 07 Prepared by Ravinda Wijesinghe 1/09/2019 Version 01.3 Page 7 of 8

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

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.

©Copyright: 2017 Tutorial 07 Prepared by Ravinda Wijesinghe 1/09/2019 Version 01.3 Page 8 of 8

Assignment activities (individual) – Create data dictionary items for your

subsystem – i.e. you need to create data flow descriptions, data store

descriptions and process descriptions for your subsystem. Refer to

assignment marking rubric for more information. Please also be mindful

about submission due date.