SYSTEM

ANALYSIS
Chapter 5
 2
TOPICS:
Chapter 5a
• Traditional methods for determining requirements
• Contemporary methods for determining system requirements
Chapter 5b
• Requirements determination using Agile methodologies
• Structuring system process requirements
• Structuring system data requirements
 3

SYSTEM ANALYSIS
 4

SYSTEM ANALYSIS
Analysis is the first systems development life cycle (SDLC) phase where
you begin to understand, in depth, the need for system changes

Systems analysis involves a substantial amount of effort and cost, and is

therefore undertaken only after management has decided that the systems
development project under consideration has merit and should be pursued
through this phase.
 5

SYSTEM ANALYSIS
Two main activities
• Requirements determination. This is primarily a factfinding activity.
• Requirements structuring. This activity creates a thorough and clear
description of current business operations and new information
processing services.
TRADITIONAL METHODS
FOR DETERMINING
REQUIREMENTS
 7

FACT-FINDING TECHNIQUES
• Interview
• Questionnaire
• Document Review
• Observation
 8

INTERVIEW
• Interviewing is one of the primary ways analysts （ projects manager) gather
information about an information systems project.
• Interviewing is an important fact-finding(fact, opinion, specification) tool
during the system analysis phase.
• An interview is a planned meeting during which the analyst obtain
information from another person. The skills needed to plan, conduct, and
document interviews successfully must be understood.
• Interviewees are current users, sometimes customers/suppliers, of the current
system or potential users of the proposed systems.
• During interviews, it is important to gather as much relevant information as
possible.
 9

INTERVIEW
• Interviewer will ask more open-ended question so to obtain the qualitative
information.
• This technique is often the best source of qualitative information, such as
getting interviewee’ opinions or suggestions.
• The successful of an interview depends very much on the good
communication skill of the interviewer (SA).
 10

TYPICAL
INTERVIEW
GUIDE
 ADVANTAGES OF INTERVIEW 11

Provide & Clarify Facts

Face-to-face interview allows the interviewer to react to anything the interviewee says. (in order to
you to get in-depth data)

Overcome Resistance
Get the user directly involved & giving them the feeling of having made a substantial
contribution.

Intimate and Frankness

People who would be unwilling to put critical or controversial comments in writing talk more
freely in person.

Better understanding
Allow the analyst to observe tone & voice inflection, body language of respondent.
 12

DISADVANTAGES OF INTERVIEW
Costly and Time-consuming
An interview requires the dedicated time of both the interviewer and the interviewee for the
duration of the interview. [preparation-open ended question to interview-
interpretation(analyse the question)]

Require Skill
Certain amount of skill is required 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.
 13

QUESTIONNAIRE
• It enables a large number of participants, from various departments to even various
countries, to be involved in the systems investigation. (geographic areas)
• With standardized questions, the facts gathered tend to be more reliable and often more
honest responses.
• Questionnaire uses more close-ended questionnaires to gather quantitative information.
• Questionnaires should be tested and if necessary, modified before printed and distributed.
• Recipients of questionnaires should be selected depending on the information they can
provide. SA should ensure the respondents’ backgrounds and experiences that qualify them
to answer the questions.
 14

GUIDELINES TO DESIGN A GOOD QUESTIONNAIRE:

• Brief and user-friendly

• Clear instructions and guidance on how to answer the questions
• Questions in logical order, going from easy to more complex questions
• Use simple terms and words to avoid misunderstanding
• Avoid leading questions
• Limit open-ending questions that are difficult to tabulate
• Limit questions raising concern/negative issues
• Include a section for general comments
• Test the questionnaire in advance on a small group before finalizing it
• Use signed questionnaires when the SA need to know who the respondents are in order to
match or correlate information
• Use anonymous questionnaires for sensitive and controversial topics
 15

ADVANTAGES OF QUESTIONNAIRE
Respondent Given Time & Answer at Leisure
Given time to assemble the required information.

Information from Large Group

Respondents are relatively many and geographically dispersed.

Respond Anonymously
Submit the questionnaire without written name on the top.
 16

DISADVANTAGES OF QUESTIONNAIRE
Difficult to Design (a lot of guideline)
Difficult to design the questions so that no misinterpretation is possible and no
bias is possible in the replies.

Cannot Clarify Question

Subsequent interpretation of answers is subject to inaccuracies or biased.

Not all the forms will be returned (some of the form that refuse to answer)
Refuse to fill in forms.
 17

DOCUMENT REVIEW
• Records and reports can provide analysts with valuable information about the
organization and its business operations.
• In document review, SA examines information that has been recorded about the system
and users.
• Records include written policy, manuals, regulations and standard operating procedures
used by most organizations as a guide for managers and employees.
• Sometimes the documented records can be out-dated. Thus, it might be no longer in use
or the actual practices might not comply to the system documentation.
• SA should review copies of the actual forms and operating documents that are currently
used in the system. Both blank copies of forms and samples of actual completed forms
should be collected.
 18

ADVANTAGES OF DOCUMENT REVIEW

Better Understanding of Procedures
Give best guide to current practice

Detailed Description of Procedures

Provide more detailed description of the procedures involved

Cross-check And Verify Fact

Cross verification method to further support the fact gain through other
methods.
 19
DISADVANTAGES OF DOCUMENT
REVIEW
Documents May Not Up to Date
No longer be used or already changed.

Procedures Modified & Current Practice Not Following Documents

Some procedures to perform a task might be modified or eliminated.
Some staff may have their own way to carry out the job.

Need Careful Selection of Documents.

Not every document is meaningful to be served as current practice guide.
 20

OBSERVATION
• Refer to observing the current operating procedures, in order to have a fully understanding
of the system’s operation.
• Seeing the system in action gives an additional perspective to supplement what we have
heard and read from interview, observation or questionnaires.
• By personal observation, SA could verify statements made in interviews as well as
determine if procedures operate as specified in the system documentation.
• SA might even discover if the system documentation and the statements from interviewed
truly reflect the system in operations.
• Through observation, we might correct any misconceptions or erroneous impressions.
• Plan the observation in advance by preparing a checklist of the steps that wanted to be
observed and the questions to be asked.
 21

ADVANTAGES OF OBSERVATION
Additional Perspective
Seeing the system in action gives you an additional perspective to supplement
what you 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

Acquire Know-how
Personal observation helps you acquire the know-how you will need for
implementation
 22

ADVANTAGES OF OBSERVATION
Better Acceptance
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 23

Time Consuming
Time factor will often prevent the analyst from making as thorough an investigation

Need Power of Concentration

Good observation is very difficult to develop. Much depends on power of concentration

Need Prior Understanding of Procedure

It needs the observer to have an understanding of the procedures involved for effective observation

Subconscious Observation
An analyst will tend to make subconscious observations of his local environment and based on past
experiences
CONTEMPORARY METHODS FOR
DETERMINING SYSTEM
REQUIREMENTS
 25

METHODS FOR DETERMINING SYSTEM REQUIREMENTS

There are additional techniques to collect information about the

current system, the organizational area requesting the new system,
and what the new system should be like. (also reduce the time of
doing analysis)
Several contemporary information-gathering techniques for analysis:
• JAD,
• CASE tools to support JAD, and
• Prototyping
 26

METHODS FOR DETERMINING SYSTEM REQUIREMENTS

 27

JOINT APPLICATION DESIGN

A structured process in which users, managers, and analysts work together for
several days in a series of intensive meetings to specify or review system
requirements.
 JOINT APPLICATION DESIGN 28

The typical participants in a JAD are listed below:

JAD session leader (the one who call the meeting). The JAD session leader
organizes and runs the JAD. This person has been trained in group management
and facilitation as well as in systems analysis. The JAD leader sets the agenda and
sees that it is met; he or she remains neutral on issues and does not contribute
ideas or opinions, but rather concentrates on keeping the group on the agenda,
resolving conflicts and disagreements, and soliciting all ideas.

Users. The key users of the system under consideration are vital participants in a
JAD. They are the only ones who have a clear understanding of what it means to
use the system on a daily basis.
 JOINT APPLICATION DESIGN 29

Managers. Managers of the work groups who use the system in question provide
insight into new organizational directions, motivations for and organizational
impacts of systems, and support for requirements determined during the JAD.

Sponsor. As a major undertaking due to its expense, a JAD must be sponsored by

someone at a relatively high level in the company. If the sponsor attends any
sessions, it is usually only at the very beginning or the end.
 JOINT APPLICATION DESIGN 30

Systems analysts. Members of the systems analysis team attend the JAD,
although their actual participation may be limited. Analysts are there to learn
from users and managers, not to run or dominate the process. (to record the
progress of the project)

Scribe. The scribe takes notes during the JAD sessions. This is usually done on a
laptop. Notes may be taken using a word processor, or notes and diagrams may
be entered directly into a CASE tool.
 31

JOINT APPLICATION DESIGN

IS staff. Besides systems analysts, other information systems (IS)

staff, such as programmers, database analysts, IS planners, and data center
personnel, may attend to learn from the discussion and possibly contribute
their ideas on the technical feasibility of proposed ideas or the technical
limitations of current systems.
 32

ILLUSTRATION OF THE TYPICAL ROOM LAYOUT FOR A JAD

 33

CASE TOOLS DURING JAD

• For requirements determination and structuring, the most useful CASE tools
are for diagramming and form and report generation.
• The more interaction analysts have with users during this phase, the more
useful this set of tools is.
• The analyst can use diagramming and prototyping tools to give graphic form
to system requirements, show the tools to users, and make changes based on
the users’ reactions.
 34

CASE TOOLS DURING JAD

• Running a CASE tool during a JAD enables analysts to enter system models
directly into a CASE tool, providing consistency and reliability in the joint
model-building process.
• The CASE tool captures system requirements in a more flexible and useful
way than can a scribe or an analysis team making notes.
• Further, the CASE tool can be used to project menu, display, and report
designs, so users can directly observe old and new designs and evaluate their
usefulness for the analysis team.
 PROTOTYPING
35

An iterative process of systems development in which requirements are

converted to a working system that is continually revised through close
collaboration between an analyst and users.

The prototype can then serve as the basis for the production system in a process called
evolutionary prototyping.

Alternatively, the prototype can serve only as a model, which is then used as a reference for
the construction of the actual system. In this process, called throwaway prototyping, the
prototype is discarded after it has been used.
 36

PROTOTYPING
CASE tool

User try the

tools and
identify the
problem, thus
the creater can
 37

EVOLUTIONARY PROTOTYPING
• A life-cycle model of evolutionary prototyping illustrates the iterative nature
of the process and the tendency to refine the prototype until it is ready to
release.
• One key aspect of this approach is that the prototype becomes the actual
production system.
 38

EVOLUTIONARY PROTOTYPING

• Any given system must be designed to facilitate database access, database

integrity, system security, and networking.
• Systems also must be designed to support scalability, multiuser support, and
multiplatform support.
 39

THROWAWAY PROTOTYPING
• Throwaway prototyping does not preserve the prototype that has been developed.
• With throwaway prototyping, there is never any intention to convert the prototype
into a working system. the prototype is developed quickly to demonstrate some
aspect of a system design that is unclear or to help users decide among different
features or interface characteristics.
• Once the uncertainty the prototype was created to address has been reduced, the
prototype can be discarded, and the principles learned from its creation and testing
can then become part of the requirements determination.
 40

PROTOTYPING
Prototyping is most useful for requirements determination when:
• User requirements are not clear or well understood, which is often the case for
totally new systems or systems that support decision making. (to identify the
clear requirement of customer)

• One or a few users and other stakeholders are involved with the system.

• Possible designs are complex and require concrete form to fully evaluate.
 41

PROTOTYPING
Prototyping is most useful for requirements determination when:
• Communication problems have existed in the past between users and analysts
and both parties want to be sure that system requirements are as specific as
possible.

• Tools (such as form and report generators) and data are readily available to
rapidly build working systems.
 DRAWBACKS OF PROTOTYPING 42

• Prototypes have a tendency to avoid creating formal documentation of system

requirements, which can then make the system more difficult to develop into a fully
working system.

• Prototypes can become very idiosyncratic to the initial user and difficult to diffuse or adapt
to other potential users.

• Prototypes are often built as stand-alone systems (, thus ignoring issues of sharing data and
interactions with other existing systems, as well as issues with scaling up applications.

• Checks in the SDLC are bypassed so that some more subtle, but still important, system
requirements might be forgotten (e.g., security, some data entry controls, or
standardization of data across systems).
 REQUIREMENTS
DETERMINATION USING
AGILE METHODOLOGIES
 REQUIREMENTS DETERMINATION USING AGILE 44

METHODOLOGIES
Agile requirements determination techniques are another contemporary approach to
figuring out what a new or improved system is supposed to do.

Requirements determination techniques:

• Continual user involvement in the development process, a technique that works
especially well with small and dedicated development teams.
• JAD-like process called Agile Usage-Centered Design.
• The Planning Game, which was developed as part of eXtreme Programming.
 45

CONTINUAL USER INVOLVEMENT

• The development follows the analysis–design–code–test cycle favored by the
Agile Methodologies, because the user can provide information on requirements
and then watch and evaluate as those requirements are designed, coded, and
tested.

• This iterative process can continue through several cycles, until most of the major
functionality of the system has been developed.

• Extensive involvement of users in the analysis and design process is a key part of
many Agile approaches, but it was also a key part of Rapid Application
Development
THE ANALYSIS–DESIGN–CODE–TEST
46

CYCLE
 47

AGILE USAGE-CENTERED DESIGN

• Originally developed by Larry Constantine (2002) and adapted for Agile
Methodologies by Jeff Patton (2002).

• Continual user involvement in systems development is an excellent way to

ensure that requirements are captured accurately and immediately
implemented in system design.
48
THE PLANNING GAME FROM EXTREME PROGRAMMING 49

• One of the key emphases of eXtreme Programming is its use of two-person

programming teams and having a customer on-site during the development
process.

• The relevant parts of eXtreme Programming that relate to requirements

determination are:
1) How planning, analysis, design, and construction are all fused together into a single phase
of activity.
2) Its unique way of capturing and presenting system requirements and design specifications.

• All phases of the life cycle converge into a series of activities based on the basic
processes of coding, testing, listening, and designing.
The Planning Game has three phases: 50

exploration, commitment, and steering.

 STRUCTURING
SYSTEM PROCESS
REQUIREMENTS
52
 53

DATA FLOW DIAGRAM (DFD)

• Systems analysts may use data flow diagram to understand the system
requirements.
• DFD shows how data moves through an information system but does not
show program logic or processing steps.
• A set of DFDs, provides a logical model that shows what the system does,
not how it does it.
• DFD uses four basic symbols that represent process, data flows, data stores,
and entities.
54
56
57
58
 TOOLS FOR REQUIREMENT 59

SPECIFICATION
• There exist lots of tools that could be used in helping SA to perform the
analysis tasks.

• All these tools are to ensure that the tasks of analysis are performed with
accuracy and efficiency.

• Some of these tools include: -

- Decision Tree
- Decision Table
- Structured English
 60

DECISION TREE
• It is a graphical representation of the conditions, actions, and rules found in a
decision table. It also very useful ways to present the system to management.
• Decision trees show the logic structure in a horizontal form that resembles a tree
with the root at the left and branches to the right. This orientation allows the
analyst to write on the branches in order to describe conditions and actions.
• The sequence of the condition and actions are important. We begin to build the
tree from left to right while making sure that we complete listing all possible
alternatives before moving over to the right.
• A tree might not always be symmetrical all the times, where we could have a
complex decision tree.
 61

The steps involved in

building a decision tree:
• Identify the conditions
• Identifies the condition
alternatives
• Identify the actions
• Identify action rules (enter
actions)
• Create key and title
 62

DECISION TREE
Advantages of using decision trees:
• The order of checking conditions and executing actions is immediately noticeable.
• Conditions and actions of decision trees are found on some branches but not on others, unlike
decision tables where they are all part of the same table.
• Those conditions and actions that are connected directly to other conditions and actions, while
those conditions that do not matter are absent.
• Compared to decision tables, decision trees are more readily understood by others in the
organization. Thus, they are more appropriate as a communication tools.

Disadvantages of decision tree:

• Taking up space and consequently a minimum amount of description on the conditions and
actions can be written on the trees.
 63

EXAMPLE OF DECISION TREE

 DECISION TREE EXAMPLE 64

Develop a decision tree based on the following scenario:

• Customers, who are member and have been a member for more than two years are entitled to a 20% discount. In
addition, if the customer also submits an online feedback, a bonus coupon will be issued to the customer.
• Customers with memberships of two years and below are entitled to a 10% discount.
• Non-member customers are not entitled to any discount.
 65

DECISION TABLE
• A decision table is a table of rows and columns, separated into four
quadrants.

• In order to build a decision table, the analyst needs to determine the

maximum size of the table, eliminate any impossible situations,
inconsistencies or redundancies and simplify the table as much as possible
 DECISION TABLE 66

The steps of building a decision tables are as follows: -

1. Determine the number of conditions that may affect the decision.
2. Determine the number of possible actions that can be taken.
3. Determine the number of condition alternatives for each condition.
4. Calculate the maximum number of columns in the decision table by multiplying
the number of alternatives for each condition.
Number of conditions Number of Columns
1
2
3
4
 DECISION TABLE 67

The steps of building a decision tables are as follows: -

5. Fill in the condition alternatives.
6. Complete the table by inserting an ‘X’ where rules suggest certain actions.

7. Create a key to explain the abbreviations, if any.

8. Apply combine rules, where it is apparent that an alternative does not make a
difference in the outcome.
 DECISION TABLE
9.

10. Check the table for any impossible situation, contradiction and
redundancies.
 DECISION TABLE 69

• Contradictions occur when rules

suggest different actions but satisfy
the same conditions.
Contradictions often occur if the
dashes (-) are incorrectly inserted
into the table. Contradictions
could also be a result of discrepant
information gathered from
different systems users.
Redundancy occurs when identical
sets of alternatives require the
exact same action.
 DECISION TABLE 70

11. Rearrange the condition and

actions if this makes the decision
table more understandable.
 DECISION TABLE EXAMPLE 71

Develop a decision tree based on the following scenario:

• Customers, who are member and have been a member for more than two years are entitled to a 20% discount. In
addition, if the customer also submits an online feedback, a bonus coupon will be issued to the customer.
• Customers with memberships of two years and below are entitled to a 10% discount.
• Non-member customers are not entitled to any discount.
 72

ENHANCED DECISION TABLES

• Decision tables can become very burdensome because they grow rapidly as
the number of conditions and alternatives increase.
• For instance, a table with only seven conditions would have 128 columns.
• Use of extended entries, ELSE rule or construct multiple tables could
resolve this situation.
 73

EXTENDED-ENTRY FORM
• A narrative action approach is
used instead of simply a Y or N in
the case of a limited-entry form
table.
 74

ELSE-ENTRY FORM
• This form is useful in helping to eliminate many repetitious rules
requiring the same exact action. It is also useful in preventing errors of
omission.
 ELSE-ENTRY FORM EXAMPLE 75

Develop a decision tree based on the following scenario:

• Customers, who are member and have been a member for more than two years are entitled to a 20% discount. In
addition, if the customer also submits an online feedback, a bonus coupon will be issued to the customer.
• Customers with memberships of two years and below are entitled to a 10% discount.
• Non-member customers are not entitled to any discount.
 76

STRUCTURED ENGLISH
• Many functional operations simply involve straightforward sequence of
tasks or the iteration of smaller operations. In such case, a series of concise
English statements, called Structured English, can be used to
communicate the processing rules.

• It is a Standard English that similar to pseudocode of the structured

programming.

• Users are generally comfortable with English statements. As the format of

structured English is sufficiently precise so that it will not be
misinterpreted by designers or programmers.
 77

STRUCTURED ENGLISH
A Structured English must conform to the following rules:
1. Use only the 3 building blocks of sequence, selection and iteration.
2. Use indentation for readability.
3. Use a limited vocabulary including standard terms used in the data dictionary
and specific words that describe the processing rules.
4. Three basic constructs of Structured English:
1) Sequence
2) Selection
3) Iteration / Repetition
 78

SEQUENCE
• The completion of one of two steps in sequential order, one after another.
• One or more of the steps might represent a sub process that contains
additional logical structures.
 79

SEQUENCE
Example:
• Request the borrower’s library card.
• Check the borrower is the owner of the card.
• Receive the books from the borrower.
• Check the books are non-reference materials.
• Stamp due dates on the books.
• Return the library card and the stamped books to the borrower.
 80

SELECTION
• Often, we need to make decision where the successive actions are based on certain
decision made.
• Two possible forms are the IF-THEN-ELSE-ENDIF form and CASE-
OTHERWISE-ENDCASE form.
• Others are such as IF_ELSE_ENDIF, IF_ENDIF………
• IF-THEN-ELSE-ENDIF form is probably easier for the user to understand when
there are only two options possible for the selection. Use of indentation and the
separation of lines will enhance the readability.
• When three or more options are possible for a selection, the CASE-
OTHERWISE-ENDCASE construct usually communicates better.
 81

SELECTION
 82

ITERATION / REPETITION
• It shows the repetition of a group of statements some number of times
until it is done.
• The group of statements to be repeated is indented directly below the
conditional statement. The condition statement specifies the number of
times the iteration is to occur.
• It has three possible forms: FOR-ENDFOR, DO WHILE- ENDDO and
REPEAT-UNTIL.
ITERATION / REPETITION
 SELECTION EXAMPLE 84

Develop a decision tree based on the

following scenario:
• Customers, who are member and
have been a member for more
than two years are entitled to a
20% discount. In addition, if the
customer also submits an online
feedback, a bonus coupon will be
issued to the customer.
• Customers with memberships of
two years and below are entitled
to a 10% discount.
• Non-member customers are not
entitled to any discount.
 85

REFERENCES:
EXAMPLE OF A SALES PROMOTION POLICY:
 86

Decision Table
 87

Decision Tree
 88

Structured English
 89

STRUCTURING
SYSTEM DATA
REQUIREMENTS
 91

CONCEPTUAL DATA MODEL

• A conceptual data model is a representation of organizational data. The
purpose of a conceptual data model is to show as many rules about the
meaning and interrelationships among data as are possible.

Conceptual data model

• A detailed model that captures the overall structure of organizational data
that is independent of any database management system or other
implementation considerations.
 92

ENTITY RELATIONSHIP DIAGRAMS

• Widely accepted and adapted graphical tool for data modeling
• Graphical representation of entities and their relationships in a database
structure.
• Provides an overall view of the system and a blueprint for creating the
physical data structures.
• A top-down approach to data modeling.
 93

ENTITIES
• 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
• Using singular or plural nouns is a matter of preference
• Notation - it is represented by a rectangle.
 ENTITIES 94

Examples of Entities:
• Persons : agency, contractor, customer, department, division, employee,
instructor, student, supplier
• Places : sales region, building, room, branch office, campus
• 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
• Concepts : account, block of time, bond, course, fund, qualification, stock
 95

ATTRIBUTES
• Meaning - is a characteristic, data field, or data element of an entity. There are many
attributes for each entity.
• Example – Customer’s attributes are name, address, telephone, email.
• Notation:

• DBDL or Textual notation

STUDENT (STU_ID, STU_LNAME, STU_FNAME, STU_INITIAL, STU_EMAIL, STU_PHONE)
 96

RELATIONSHIPS
• Meaning. The lines between the entities (boxes) representing relationships
between them
• Example. Between CUSTOMER and ORDER
• Notation. The relationship is indicated by lines connecting the entities.
There’s a “crow’s” foot or a diamond shaped box
• Description : A relationship is read in two directions (left and right).
Example : Each customer places many orders, and each order is placed by
only one customer.

Customer Order
 97

DEGREE OF RELATIONSHIP
The degree of a relationship is the number of entity types that participate in that
relationship.
Unary relationship
• A relationship between instances of one entity type; also called recursive
relationship.
Binary relationship
• A relationship between instances of two entity types. This is the most common
type of relationship encountered in data modelling.
Ternary relationship
• A simultaneous relationship among instances of three entity types.
 98

Employee Professor Class

Doctor Prescription Patient

Drug
 99

TYPES OF RELATIONSHIPS
One-to-one relationship (1:1)
Exists when exactly one of the second entity occurs for each instance of the first entity.

One-to-many relationship (1:M)

Exists when one occurrence of the first entity can relate to many instances of the second
entity, but each instance of the second entity can associate with only one instance of the
first entity.

Many-to-many relationship (M:N)

Exists when one instance of the first entity can relate to many instances of the second
entity, and one instance of the second entity can relate to many instances of the first
entity.
 100

TYPES OF RELATIONSHIPS
Relationship - to be read in bidirectional:

• 1: 1 🡪 1: 1
1: 1

• 1: M 🡪 1: M
1: 1

• M: N 🡪 1: M
M: 1
 101

TYPES OF RELATIONSHIPS
• Example of One-to-Many Relationship (in Access)

• Example: A teacher can teach many students, and each student have one
class teacher.
 102

TYPES OF RELATIONSHIPS
Many-to-Many Relationship
• Meaning - When an entry can occur more than once on both sides of the relationship.
• Examples
• Each student can take many classes, and each class can contain many students
• Each order contains many products, and each product can be listed in many orders.

Student Class

Order Product
 We only use this for
ERD NOTATION
103

examination and
assignment submission
 104

Crow’s Foot Notation

Cardinality
Expresses minimum and maximum number
of entity occurrences associated with one
occurrence of related entity
Established by very concise statements
known as business rules
Important Note:
These are the only symbols to be used in tests
and exam questions
From this slide onwards, these correct Crow’s
foot notation should be used
 CROW’S FOOT NOTATION 105

• Describes the cardinality of relationship between two entities

• Shows how instances of one entity relate to instances of another entity.
• Because all relationships are bidirectional, cardinality must be defined in both directions
for every relationship.
 106

Crow’s Foot Notation

 107

RESOLVING MANY-TO-MANY RELATIONSHIP

Associative Entities
• Also known as weak entities.
• Used to resolve M:N relationships.
• Composed of primary keys of each of the entities to be connected.
• By introducing an ‘associative’ entity to form a new 2 pairs of one-to-
many relationships.
• M: N 🡪 1: M
M: 1
 RESOLVING MANY-TO-MANY RELATIONSHIP 108

• Introducing an ‘associative’ entity to form a new 2 pairs of one-to-many

relationships.

Before Order Product

After Order Product

Order_list

Associative Entity
 109

Order Product

RESOLVING
MANY-TO-
Order_list MANY
RELATIONSHIP
Associative Entity

Identify the keys in ORDER_LIST entity

Order (OrderID, OrderDate, OrderAmount)

Product (ProductCode, ProductName, UnitPrice)
Order_list (OrderID*, ProductCode*, Quantity)
* Foreign key
 110

EXAMPLE: RESOLVING M:N RELATIONSHIP

Advisor Student Advisor Student

Course Course Grade

Associative entity
SUMMARY 111

• System analysis: requirements determination and

requirements structuring.
• Fact-finding techniques: interview, questionnaire,
document review and observation.
• Methods for determining system requirements: JAD,
CASE tools to support JAD and prototyping.
• Requirements determination using agile methodologies.
• Data flow diagram.
• Tools for requirement specification: decision tree,
decision table and structure English.
• Entity relationship diagrams.