Chapter 3

System Analysis
SDLC System Request

Preliminary
Investigation
(Feasibility Study)

Preliminary
Investigation
Report
System Analysis

System
Requirements
Document

System
Design

System
Design
Specification
System Development

System Implementation
System Requirements
Definition of System Analysis (Requirements Analysis)

• Another name. Sometimes called ‘Requirements Analysis

/ Requirement Elicitation’.
• Focus or objectives. To understand the business
objectives and processes and to define the required
functionality of the new system.
• Document. These requirements are usually collated in a
list (Requirements Specification).
• Fact-Gathering Techniques. The analyst will use fact-
finding techniques such as interviewing, document
analysis and questionnaires.
• Fact-Recording Techniques. The documented facts will
be modelled using such techniques as DFD and ERD.
Fact Gathering in System Development

• From whom. From people who will be using the system

i.e. the end users.
• Quality of Analyst. The analyst must have knowledge and
be experienced in the business area e.g. business rules
and processes involved.
• What to gather. Business rules, processes, locations of
work, activities of users, and system interfaces with other
systems. (In short, the analyst must read nearly
everything available about the existing system)
Fact Finding
Techniques
Interviews

• Meaning
– Widely used technique and the most
productive.
– Ask the user face-to-face on how the current
system works and about requirements.
– Formal meetings (with agenda, objectives).
– Documented feedback to the user for
confirmation
 Advantages of Interviews
• Overcome Resistance. Provides an opportunity to meet
and overcome user resistance. It gets cooperation of
people involved.
• Body language. Interviews allow the analyst to observe
the tone of the responses and body language which
convey great deal of information. (this will help the analyst to
have better understanding of the real issues involved)

• Clarify (Make clear) Facts. Face-to-face interview allows

the interviewer to verify and clarify the confusing facts.
• Build Rapport (relationship). . Opportunity to develop
rapport with users and to seek cooperation.
• Intimate (close) and Frankness (honesty). . People who
would be unwilling to put critical or controversial
comments in writing talk more freely in person.
 Disadvantages of Interviews
• Costly and Time-consuming. An interview requires the
dedicated time of both the interviewer and the interviewee for
the duration of the interview.
• Require Skill. Certain amount of skill is required
(communication, analytical, interpersonal, listening skill) on
the part of the interviewer and interviewing is an art not
readily acquired.
• Require Personal Contacts. Personal contacts are important
in getting the cooperation of the people involved. (Where the
interviewer has personal contacts or good working
relationships with the end-users, it is much easier to make
appointments for interviews)
Survey
• Meaning
– Users are sent a set of questionnaire which listing
questions about the current system for him or her to
answer at their leisure time.
– A mix of closed questions (to ascertain facts) and open
questions (to describe feelings and opinions).
– Can be tested prior to their distribution and each user
is asked exactly the same questions.
– May represent a first stage of data collection to be
supported by later follow-on interviews.
 Survey
• Suitable Circumstances to Use Survey Technique
– Large number of users. There may be insufficient time to
interview all the possible users of the system and therefore a
sample is taken.
– Geographically distributed users.It is time-consuming and
expensive to interview users who are widely geographically
distributed.
– Anonymity. Useful in circumstances where the provider of the
information wants to remain anonymous. (information to be
collected may touch on sensible issues, for example,
information on the effectiveness of management)
– Factual information. Factual information requires the user to
investigate rather than respond with instant answers as in
interviews. (for example, volume of sales)
Example of
Questionnaire
Example of Questionnaires
• Focus on a particular issue, problem or objective
• Inventory System
– Problem : Lack of useful reports
– Questions :
• What are the reports which are produced by the
present system ?
• What do you think are some of the reports which are
missing but could be useful in your decision making ?
• How would each of these reports, which you have
suggested, help you in your decision making ?
• Do functions and features in the system available
allow you to create your own reports ?
• Have you been trained to use the system, particularly
on the reporting functions and features.
• What do you think are the reasons why the system
cannot produce the reports that you want ?
 Advantages of Survey
• Recipient Can Answer at Convenience. The recipients can answer
questionnaires at their convenience; it isn’t necessary to set aside a
significant block of time as one must do for an interview.
• Respond Anonymously. The questionnaire can be used to provide
anonymous responses. There is evidence to suggest that
respondents are more likely to give more accurate responses this
way. (does not require them to put their names on the response or
their identify are not disclosed. )
• Respondent Given Time. The respondent is given time to assemble
the required information. (This will allow the respondent sufficient
time to gather or compile information which are more relevant and
accurate)
• Information from Large Group. Questionnaires may be used where
the respondents are relatively many and geographically dispersed.
Disadvantages of Questionnaires
• Difficult to Design. Difficult to formulate or design
the questions so that no misinterpretation is possible
and no bias is possible in the replies.
• Cannot Clarify Question. One cannot clarify on the
spot to the respondents the question as can be done
in an interview (if any of the respondents not
understand the questions).
• Not all the Forms Will be Returned. Many people
reluctant to filling in forms while others delay
completing them until they are eventually forgotten.
 Observation - Meaning
• Objectives. An analyst would watch who
interrelates with whom in a dept and
procedures. (observation of a system in action
to fully understand the system’s requirements)
• Items observed. Observe how data flows :
from desk to desk or computer to computer.
Note how data comes into and leaves the
organisation.
• Arrangement. Make arrangements and make
everyone aware of the purpose of your visit.
• Forms. Participatory observation; in this form
the analyst temporarily joins the activities of
the group. (A non-participatory observation, the
persons being observed may become nervous)
 Advantages of Observation
• Additional Perspective. Seeing the system in action gives
SA an additional perspective to supplement what he/she
have heard (interview) and read (inspection).
• Cross-check and Verify. Provides the opportunity for the
analyst to cross-check and verify information given in an
interview. (between how the users say they go about their work
and how they actually do it.)
• Acquire Know-how. Personal observation helps to acquire
the know-how that system analyst will need for
implementation.
• Better Acquaintance (know about someone) . SA also become
better acquainted with the operating personnel who will be
implementing the new or changed system.
• Environmental Conditions. Allows the analyst to observe
environmental conditions (such as dirt, space and noise)
which may affect implementation.
 Disadvantages of Observation
• Time Consuming. Time factor will often prevent the analyst from
making as thorough an investigation. (Example, a purchase cycle
may consume up to weeks to complete the whole purchasing
cycle)
• Need Prior Understanding of Procedure. It needs the observer to
have an understanding of the procedures involved for effective
observation. (must be familiar with the processes involved in a
particular system before he/she is able to spot any problems or
suggest solutions.)
• Need Power of Concentration. Good observation is very difficult
to develop. Much depends on power of concentration.
• Subconscious Observation. An analyst will tend to make
subconscious observations of his local environment and based
on past experiences.
• Hawthorne Effect. Workers might be nervous under observation. (
the observed facts may not represent the true picture of the
situation observed)
Analysis of Existing Documents
• The analyst will collect a number of
documents used in the current
system.
• Make copies or samples of relevant
documents.
• Examples : reports, organisation
charts, procedures, manuals etc.
• Make analysis of the documents.
Advantages of Document Inspection

• Detailed Description of Procedures.

Provide additional perspectives to the
answers not clearly described through
interviewing or questionnaires.
• Better Understanding of Procedures.
Enable one to understand the system’s
operating procedures and documents.
• Guide to Current Practice. Close study of
the forms give the best guide to current
system’s practice.
Disadvantages of Documents
Inspection
• Documents Not Up To Date. Sometimes
system documentation is not up to date.
• Documented Procedures Modified. Some
documented procedures might have been
modified or eliminated.
• Current Practice Not Following Documents.
The current practice may not use the original
forms or documents.
• Need Careful Selection of Documents. To be
fruitful it requires careful selection of
documents/records to be studied.
Joint Application Development
(JAD)
• Forum. JAD is a workshop for users in exploring
requirements, issues and problems.
• Purpose. Allows IT personnel to work with users as a
group to learn about their requirements through
discussion. (discuss business needs and define the
new system requirements)
• Participants. Headed by a project leader who has
various skills eg. organisational, interpersonal,
technical (eg CASE tools) (users ask to review
design, offer comments)
• Documentation. Proceedings of the workshop are
recorded.
Background Research
• Reviewing journals, periodicals, and
books that contain information relevant to
the task at hand.
• Attending professional meetings and
seminars.
• Formal and informal discussions with
other professional in related areas.
• Visits to similar sites.
 Prototyping as a
Technique for
Understanding Users’
Requirements
 Prototyping Approach
• Model. A model containing key features e.g. data entry,
or report program, is created by using a 4GL or CASE
tools. (to understand what the user want).
• Purpose. For users to test and provide feedback as to
whether it meets their requirements.
• Speed. The prototypes can be modified quickly (usually
minutes/hours rather than the week) eg using 4GL or
CASE tools.
• Productivity. The models or prototypes can be developed
into a working and complete application programs in
shorter time period. (and meet user requirements)
Steps of
Prototyping
Process
 Prototyping Process
Users and IS
Personnel
Comparing Waterfall and Prototyping
Model
Waterfall Model Prototyping Model

Evaluation

Evaluation

Evaluation carried out at the Evaluation carried out at

end of the SDLC early part of SDLC (ie.
System Analysis)
Exercise for Students
• KL Capital Management helps to manage RM5
billion in assets for 200 clients. Currently KL
Capital employs 20 consultants without the
use of systems. The company is planning to
implement expert system to assist the
consultants.
• Required
– Identify and briefly describe 2 fact-gathering
methods to be used.
– Justify your selection of the fact-gathering
methods.
Solutions
• Fact-gathering Methods : (any 2)

• Justification
Requirements Mapping of A
Software Package
Functional Requirements
• Describe the functionality or services that the system
is expected to provide.
• Described in detail eg. inputs, outputs, processes,
and stored data. (that are needed to satisfy the
system improvement objectives)
• Depend on :
– type of software
– users’ requirements
 Examples of Functional
Requirements – Sales Order System
• Storage Requirements. Fast retrieval (eg. for reporting
purpose) and update of data from product.
• User Interface Requirements. Automatic entry of
product data (e.g. Through use of bar-code scanning )
and easy-to-use data entry screens. (e.g. Through
keyboards)
• Processing Requirements. Fast automatic calculation of
sales totals and shipping costs.
• Control Requirements. Signals for data entry errors and
quick pricing, and customer databases. Mail
confirmation for customers. (for orders which have been
accepted and processed).
Non-Functional Requirements

• Do not directly related to specific functions of

the system. (also important features of a system)
• Describe other features, constraints and
characteristics/attributes of the system.
Example 1 : Interfaces with other
systems
• With other systems - there is an increasing
need for applications to receive data from
one system and to supply it to another.
– Example - Payroll system with Accounts
system for cash flow forecasting.
• With generalized software - such as
spreadsheets or specialised tools for data
mining.
Example 2 : Audit requirements
• Meaning - most software solutions require some sort
of audit trail. This trail records significant information
about particular transactions.
• Example - payroll system (for example, an employee
might raise his/her own salary) : the change of salary
scale for a particular employee might be recorded on
an audit trail eg. date, time of change, the previous
salary scale etc.
• Agreement - the need for, and content of, an audit trail
must be agreed with auditors and defined in the non-
functional requirements.
Example 3 : Legal issues
• Importance - the software may have to support
certain legal requirements. These may be defined by
industry-wide legislation, such as the Data Protection
Act (in UK).
• Purpose - legislation may place certain
responsibilities on the user; the software should
support the user in fulfilling those responsibilities.
• Example - (banking industry) the legislation may
require fields recording who provided that
information and when that information was last
updated etc
Example 4 : Archiving, backup and
recovery
• Backup and Recovery Routines
– Definition - to make a copy in anticipation of future failure or
corruption.
– Purpose - to ensure that the most recent usable copy of the data
can be recovered and restored in the event of loss or corruption.
– Method – manually or automated using software (part of OS
function)
– Intervals for Back-up - depending on (1) nature of data and (2)
nature of organization
• Archiving Facilities
– Definition - the process of moving (by copying) data from primary
storage, such as a hard disk, to tape or other portable media for
long-term storage.
– Purpose - provides a legally acceptable business history, while
freeing up hard disk space, speed up searching function.
– Length of Retention depends on : (1) Legal obligations (the control
of law or the limit of law) and (2) Other business needs.
Example 5 : Usability
• Usability – ease with which end users can use a particular
system to perform a particular business function.
• Methods used to measure :
– Learnability – How long it takes a user to learn to use a
particular function of the system ?
– Efficiency – Once users have learned the design, how
quickly can they use the system to perform tasks ?
– Memorability – When users return to the design after a
period of not using it, how easily can they re establish
proficiency?
– Errors – How many errors do users make, how severe are
these errors, and how easily can they recover from the
errors?
– Satisfaction – How pleasant is it for the users to use the
design ?
Example 6 : Reliability
• Measures
– System’s ability to perform and continue to perform its
functions without failure.
– Systems which are not reliable break down frequently.
• Consequences
– System out of service brings hardship (suffering) to the
users and others e.g. customers.
• Reasons for not being reliable
– Insufficient testing
– Poor design
• Important in some industries
– Safety Critical Systems (e.g. Life-support systems)
– Mission Critical Systems (e.g. Attack and defend systems)
Exercise for students
• Inventory System :
– Describe 2 functional requirements
– Describe 2 non-functional requirements
Solutions
• Describe 2 functional requirements

• Describe 2 non-functional requirements

Modelling Techniques and
Concepts
Fact Recording
• Purpose - Facts about the existing system
must be recorded / documented so that
they can be referred to during the
subsequent stages.
• Variety - System analyst may use different
recording methods (next slide).
Models Used in Fact Recording
• Narrative Description
• Data Flow Diagram
• Entity Relationship Diagram
• Decision Tables
• Decision Tree
• Structure Diagram
• Flowcharts eg. System flowchart, program
flowchart, clerical procedural flowchart.
• Organisation Chart
Examples of
Models Used
in Analysis
Phase
The analysis phase
activity may involve
creating a variety of
models.
They are referred to
as logical models
because define in
great detail what is
required without
committing to one
specific technology
Narrative Description
.... in words
Consider an order processing system. Whenever an
order is received the system should first check to
determine if payment has been received with the order.
There are two possibilities – yes and no – which lead on
to differing responses.
If payment is included with the order, the system
would then have to check on the availability of the
items ordered. Here there are two further possibilities
– the items can be in stock or not.
If the item are in stock they would then be shipped or
delivered to the customer.
If the item is not in stock a record of the customer’s
order orders to be made so that the item will be
despatched when stock becomes available.
If the customer has not included payment with order a
similar set of activities would be undertaken but they
would be preceded by credit evaluations.
Data Flow Diagram
Definition of DFD
• Models which can be used to graphically
document the operation of the current
system.
• The processes of the current system
described in user interviews (see above) may
be modeled with a standard set of symbols.
• The diagramming notation usually includes
symbols for a process, a data store, a data
flow and an external entity (source or sink).
• There are also rules that govern the
connections between these symbols
Components of DFD

Data
Store
DFD Symbols
 Notation Used (Recommended)
These will be
the symbols
recommended
and used in
TAR University
College in
assignments
and exams.
 Data Flow (object / noun)
• Definition
– A path by which data moves from one part of the IS to
another part.
– Represents a specific piece of data in motion.
• Examples
– Calculating Gross Pay Process :
• Input data flows (e.g. worked hours, pay rate,
employee number);
• Output data flows (e.g. gross pay)
– Creating Purchase Order Process : Input data flows
(purchase requisition, item details, supplier details);
Output data flows (eg. PO)
• Symbol/Notation
invoice
 Process(active verb + object/noun)
• Definition
– Describes the main transformations that take place
within the system. It changes incoming data flows into
outgoing data flows.
• Examples
– Calculate gross pay
– Preparing vendor cheques
• Symbol
– A circle
– Labeled with an active verb (eg. Calculate) and a noun
Data Store
• Definition
– Shows information that is stored within the system
– It is accessed and updated by the processes
– It is a repository of data (a file)
• Examples
– Student Scores
– Employee Salary and Deduction data
• Symbol/Notation
– An open-ended rectangle
– Labeled with a name (noun) and a number as an
identifier
Entities
• Definition
– Represents a person, department, organisation
or other IS that receives (sink) or send (source)
information to the system concerned.
– Show the boundaries of the IS
• Examples
– Customer
– Patient
• Symbol
– A rectangle
– Labeled with a noun
Steps in Drawing DFD
• Start by drawing a Context Diagram
• Draw detail diagrams using series of ‘explosion’ or level
of abstraction eg. Diagram 0, diagram 1 etc. until
‘functional primitive’. (a process that consists of a single
function that is not exploded further).

Draw
Context Diagram

Draw
Diagram 0 DFD

‘Explosions’
Draw
Diagram 1 DFD
DFD and
Levels of
Abstraction
(‘explosion’)

Note :
Data stores not
shown in context
diagram
The number of
external entities
remain the same
In ‘balancing’, the
number of inflows
and outflows
remain the same
Context Diagram
• Definition – represents the entire software element
as a single process (rectangle or circle) with input
and output data indicated by incoming and
outgoing arrows.

request for
quotation

purchase 0 quotation
request
Branches Purchasing Supplier
System
purchase
order
Example 1 – Sales Order System
• In XYZ Ltd, when a sales order is received from a
customer, the sales personnel would have to
check whether the particular customer’s credit
limit has been exceeded or not. This can be
carried out by checking with the Accounts Dept.
The next thing to check is the availability of the
stock items ordered. Where all these are in
proper order, then an order confirmation will be
sent to the customer and a delivery request sent
to the Warehouse. The Warehouse would
confirm if the delivery of goods has been
completed. After the goods have been sent to
the customer, an Invoice generation request will
be sent to the Accounts Dept to issue an invoice
to the customer.
Context Diagram
Diagram 0 DFD
Diagram 1 DFD – Receive Order
Example 2 – Ticket Reservation
System
• The ticketing function starts with the customer
booking tickets online in the comfort of their
homes or simply to walk-in to any of the 50
ticketing counters located in various places
throughout the country. When a reservation is
made, cash payment is collected to be banked
in later in the day. Payment can also be made
using credit cards where the normal credit
verification with the credit card firm is carried
out. Cancellation, if any, can only be allowed at
least two weeks prior to the concert when
refunds will be given. In other cases no
refunds will be allowed.
Context Diagram – Ticket
Reservation System

Context
Diagram
Diagram 0 DFD
Steps in Drawing DFD
- Purchasing System
Purchasing System
• Purchase requests are received from other departments
to buy goods.
• The purchasing department will invite request for
quotations to suppliers. Suppliers will be sending in
bids.
• A purchase order will be prepared, a copy of which is
sent to the supplier and a copy retained.
• When goods are delivered by the suppliers, the items
received are checked against the purchase order. The
delivery order is filed after noting any discrepancies.
• When the invoice is received from the supplier, it is
checked against the delivery order, payment is then
made and the invoice is filed.
1. Draw Context Diagram
• Draw a single process that represents the entire system. The process is
named after the system with number zero
• Identify and draw the external entities
• Draw the data flows from an external entity to the system and from the
system to that external entity
Diagram 0
DFD
Diagram 1 DFD – User Module
Purpose of DFD
• Help the analyst to understand the
business processes or users’ problems
better
• Describe how the current business
processes work.
• Describe how the proposed system work
and its scope and boundary.
• Users - gain users agreement (sign-off)
and commitment.
Important Points /
Rules on DFD
DFD Rules
• Process Rules
– Transformation. Processes must have both inputs and outputs and they
must differ, that is some transformation must occur to the inputs to produce
the outputs
– Process Number. Each process is numbered but this is only for ease of
identification and not to show sequence.
– Process Heading. The description of the process should be a verb like
‘prepare’, ‘calculate’, ‘check’ etc plus objects (nouns).
• Data Flow Rules
– Arrows. Arrows must always finish at or start from a process.
– Label. Every arrows must be labeled. However, there is no requirement to
label arrows that go in and out of data stores.
– Data flow should not cross line to each other (Solution: duplicated
entity/data store)
• Data Store Rules
– Number. Data stores are given a reference number (for reference only)
Repeated Diagrams
• Rather than having data flow arrows criss-
crossing all over the place it is often
simpler to show a symbol more than once
on the same diagrams.

• Repeated Data Store Student Details

• Repeated Entity
Customer
Some Common Errors
Incorrect Combination of Data Flow
and Process Symbols
Incorrect Combination of Data Flow
and Process Symbols
• Miracle: has outputs but no inputs
• Black hole: has inputs but no outputs
• Gray hole: the inputs are insufficient to produce the output

Policy number Apply Payment amount Miracle

insurance
premium

Hours worked Pay rate

Calculate Black hole
gross pay

Date of birth Final grade

Calculate
grade Gray hole
Example of Common Errors
Correct Combination of Data Flow
and Process Symbols
Incorrect Uses of Data Store
Symbols
Correct Use of Data Store Symbols
Integration Between Systems
Exercise 1 – Order Processing
• Orders received from customers are checked that the
product and payment-type are valid values, and there is
sufficient stock.
• Accepted order details are stored on an order file. If not, the
rejected orders are sent back to the customer and the whole
order is put on hold and an explanatory letter is sent to the
customer.
• Goods are received from suppliers by referring to the PO and
GRN is generated. Stock is updated.
• The ‘on-hold’ orders are checked and converted into an
ordinary order when there is sufficient stock.
• Despatch notes are raised for all orders received. A copy of
the despatch note is sent to the customer and a second copy
is sent to the warehouse. The despatch-date is noted on the
order file.
• At the end of the week an invoice is raised and sent to the
customer. The invoice-date is noted on the order file.
Solution
Entity Relationship
Diagram (ERD)
Components of ERD
• There are only 2 components :

Customer Region Supplier

Entities
Order Product

Despatch Relationships
Note
ERD Notations
Entity
• Meaning. A class of persons, places,
objects, events, or concepts about
which we need to capture and store
data (crudely, it is a file and described
using a noun).
• Examples : customers, products,
suppliers, employees, departments
• Notation. It is represented by a
rectangular box.
Examples of Entities
• Persons : agency, contractor, customer,
department, division, employee, instructor,
student, supplier
• Objects : book, machine, part, product, raw
material, software license, software package,
tool, vehicle model, vehicle
• Events : application, award, cancellation, class,
flight, invoice, order, registration, renewal,
requisition, reservation, sale, trip
• Places : sales region, building, room, branch
office, campus
Exercise 2
• List 4 appropriate entities for the following
systems :
– Inventory System
– Human Resource System
– Purchasing System
Solution
• Inventory System

• Human Resource System

• Purchasing System
Relationship
• Meaning. The lines between the boxes
represent relationships.
• Example. Between CUSTOMER and
ORDER
• Notation. The relationship is indicated by
lines connecting the entities
3 Types of Relationship
• One-to-One (1 : 1)

• One-to-Many (1 : N)
Types of Relationship
• Many-to-Many (M : N)
Cardinality – no of occurrences
Crow’s Foot Notation
Crow’s Foot Notation
• Describes the number of relationships between
two entities
• Shows how many instances of one entity relate
to instances of another entity.
• Cardinality must be defined in both directions for
every relationship.
Crow’s Foot Notation Examples
Crow’s Foot Notation Examples
Example 1 - Inventory System
Example 2 – Sales Order
Processing System
Example 3 – Purchase Order
Processing
Resolving Many-to-Many
Relationship
Example 1 – Associative Entity
• By introducing an ‘associative’ entity to form a
new 2 pairs of one-to-many relationships.

Before Customer Order Product

After Customer Order Product

Order Line

Associative
Entity
Attributes (Fields)

Customer Order

Primary
Key

CustomerID OrderNo
LastName Order Date
Attributes FirstName CustomerID
Address
PostCode
City
Phone
Foreign
Key
Sample Data for Each Attribute
Listing Attributes using DBDL
• DBDL = Database Design Language

Customer Order

CUSTOMER (CustomerID, LastName, FirstName,

Address, PostCode, City, Phone)

ORDER (OrderNo, Order Date, CustomerID*)

Primary Key Foreign Key

Example 2 (take note of error in
book)
Before After
Example 2
Example 3
Purposes of ERD
• Business Rules – capture and describe the
business rules and relationships between the
entities.
• Modeling System – describe the business system
in diagrams.
• Users - communicating system to the users for
their confirmation (sign-off) of requirements.
• File Design – form the basis of subsequent data
and file design as the entities become physical
files or database tables.
Exercise 3 - Purchasing System
• A company has 10 buyers, each one
reporting to one of two purchasing
managers.
• Each buyer has sole responsibility for the
ordering of 500 of the 5000 parts used by
the company.
• The same part can be provided by several
suppliers.
• Each purchase order can contain several
parts.
Solution
Exercise 4 – Invoicing System
• Each Customer may generate one or more Invoices
• Each Invoice is generated by only one Customer.

• Each Invoice contains one or more Invoice Lines

• Each Invoice Line is contained in only one Invoice

• Each Invoice Line references only one Product

• Each Product may be referenced in one or more
Invoice Lines

Note : Each relationship can be read in both

directions
Solution
*Relationship Between DFD and ERD
• There is a relationship between DFD and the
ERD. The data stores in DFD is related to
entities in ERD.
• A well-drawn DFD can be used as a starting
point for drawing the ERD.
• But take note that this relationship may not be
1 : 1. For example, the diary data store in DFD
of a dentist system corresponds to the entities
: appointment, appointment time and
appointment type, in an ERD.
*Relationship Between DFD and ERD
(cont…)

The data stores in DFD is related to entities in ERD. The

number of data stores can be used as a starting point for
drawing the ERD. But take note that this relationship may not
be 1 : 1.
Attributes / Data Elements
Exercise 5
• Find and
indicate the
foreign keys
Solution
* Exercise 6
• Find and indicate the
foreign keys
Solution
Exercise 7 for Students
• At the Best University, students enroll on courses (e.g.
BA in Business Administration), but they also need to
enroll on units that relate to these courses.
• A minimum number of students need to enroll on each
unit for it to run.
• Each course has typically a number of units that can
make up its total number of credit points.
• Each unit is led by one lecturer, but can be co-taught
by other lecturers. Some lecturers get research-related
leaves and so they don't need to teach on or lead any
units.
• Also, each lecturer may have a number of students who
are his or her "academic advisor" who can consult him
or her on personal and other types of problems.
Solution