CSC 302

CSC 302
Systems Analysis
University of Ibadan Distance Learning Centre

Open and Distance Learning Course Series Development
1
Copyright © 2023 by Distance Learning Centre, University of Ibadan, Ibadan
All rights reserved. No part of this publication may be reproduced, stored in a retrieval
system, or transmitted in any form or by any means, electronic, mechanical, photocopying,
recording or otherwise, without the prior permission of the copyright owner.
ISBN: 978-021-813-0
General Editor: Prof. E.B. Omobowale
University of Ibadan Distance Learning Centre

University of Ibadan,
Nigeria
Telex: 31128NG
Tel: +234 (8061400584)
E-mail: ssu@dlc.ui.edu.ng
Website: www.dlc.ui.edu.ng
2
Vice-Chancellor’s Message
The global switch to Open and Distance Education (ODE) is gaining considerable
acceptance in Nigeria. The Distance Learning Centre, over three decades of its
existence, has consistently built a system that makes Distance Education a viable
alternative for the teeming populace of Nigeria, seeking emancipation through
University education. The Distance Learning mode of study is not second-rated at the
University of Ibadan. Therefore, the university is committed to providing access to
higher education for many deserving Nigerians, especially those who because of
sundry reasons do not have the luxury of full time education in face-to-face setting.
The changing demographics of relatively young people seeking admission into the
UIDLC, which is engendered by the admission gridlock occasioned by minimal
access to the face-to-face mode of study has also contributed to the University‘s poise
to give the Distance Learning Centre the full complement of support to make it a true
flag bearer of ODL solution in Nigeria. Younger candidates are now being given
access to leverage on the distance learning mode of study as an alternative to the face -
to-face mode of study.
5
One of the ways of ensuring that actual learning takes place is the production ODL
compliant course materials by writers who are specially trained in ODL course
delivery. They have made good efforts in providing up-to-date information,
knowledge and skills in the different disciplines and at the same time making them
user-friendly.
In addition to the provision of course materials in print and e -format, a lot of
Information Technology input has also gone into the deployment of the course
materials. Most of which can be downloaded from the UIDLC Learning Management
System (LMS) platform while some are also available as Open Educational Resources
(OERs). They are also available in audio format downloadable to mobile phones,
IPod, MP3 among other devices to allow learners listen to the audio study sessions.
We will continue in our efforts to provide and review course materials for our courses.
Nevertheless, to take advantage of these formats, learners will need to improve on
their digital competencies and develop requisite distance learning culture which
requires them to be self-paced and self-learning. These course materials afford
learners the opportunity to learn at their own individual pace, space and time.
I hereby urge you to put these course materials to the best use.
Prof. K.O. Adebowale

Vice-Chancellor
3
Foreword
In fulfilment of its mandate to emancipate Nigerians through widening access to
tertiary education, the University of Ibadan, Distance Learning Centre has been
making intentional efforts to reposition its distance education delivery for more
effectiveness. It aims at embracing a holistic and all-encompassing approach to the
delivery of its Open Distance Learning (ODL) programmes and making it more
seamless for its learners.
The administrative and academic framework and support given to our learners are
tailored toward a sustainable drive for effective continuous learning. Besides this, we
are committed to providing educational course materials for the use of our learners to
fulfil the ideals of distance education. Without up-to-date, learner-friendly and ODL
compliant course materials, there can be no basis to assert that the Centre is a provider
of distance learning education that conforms to global best practice. Therefore,
provision of appropriate course materials in multiple formats is at the forefront of the
UIDLC drive to be the flagship of distance Education in Nigeria.
From the foregoing, the Centre has made the provision for credible, learner-friendly
and interactive course materials for all its courses a priority. Authoring of, and review
of course materials are commissioned to a team of ODL experts who have been
trained in-house. Professional consultation is also done from time to time to ensure
that the outputs of these course materials are subjected to rigorous peer review so that
high standards are maintained. This approach not only emphasizes cognitive
knowledge, but also, skills which are at the core of education, even in an ICT age.
The development of the materials which is on-going also has input from experienced
editors and illustrators who have ensured that they are accurate and current. They are
specially written and graphics are deployed with the distance learner in mind. It is
important to note that, for a distance learner to excel, there is the need to read relevant
materials apart from this course materials. Therefore, adequate supplementary reading
materials, as well as other information are suggested in the course materials.
Learners are advised to seek the assistance of course facilitators, especially academic
advisors during their study of the course material, even before physical interactive
session which is designed for revision. Academic advisors will assist them in using
convenient technology application tools which include: Google Hang Out, YouTube,
Talk Fusion, etc. among others. It is also going to be of immense advantage if they
complete their assignments as and when due so as to have necessary feedbacks as
guide.
Nonetheless, a learner has the responsibility to develop requisite distance learning
culture which includes diligence, discipline and consistent self-study habit in order to
maximize this mode of study. They can also seek available administrative and
academic support made available by the Centre. This is why they are encouraged to
develop their computer skills by availing themselves the opportunity of basic
computer training which the Centre‘ provides.
4
Consequently, it is envisaged that the course materials would also be useful for the
students in the face-to-face mode of study. This underpins the parity of esteem policy
of the University of Ibadan where particularly, the same facilitators are engaged for
the two modes of study. Therefore, it is a delight to present these modules to both our
distance learners and the university students in the face-to-face mode. We are
confident that the materials will be of immense value to all.
Best wishes.
Professor E.B. Omobowale

Director
5
Course Development Team
Content Authoring Oladejo, Bolanle F. Ph.D
Content Editor Prof. Ayo Kehinde
Production Editors Prof. Omobola Adelore, O.F.W. Onifade Ph.D
Managing Editor Ogunmefun Oladele Abiodun
ODL Material Converter Arimi Kayode Ph.D
General Editor Prof. E.B. Omobowale
6
Table of Contents
Timeframe 10
Study skills 10
Need help? 11
Academic Support 11
Activities 12
Assignment 12
Assessments 12
About this Course 13
Study Session 1: Meaning and Fundamental Concepts of Systems 14
Expected duration: 1 week or 3 contact hours 14
Introduction 14
Learning Outcomes for Study Session 1 14
1.1 What is a System? 14
Now that you are able to have a good grasp of what a System is, let us learn its
characteristic in details. 15
1.2 Characteristics of a System 16
1.3. Important System Concepts 17
1.4. Types of Systems 20
1.5. Computer-Based Information Systems 25
1.6 Difference between Computers and Information Systems 28
Summary of Study Session 1 31
In Study Session 1, you have learned that: 31
Self- Assessment Questions (SAQs) for Study Session 1 31
Notes on the Self- Assessment Questions (SAQs) for Study Session 1 32
References 34
Study Session 2: Overview of Information System 35
Introduction 35
Now that you are able to have a good understanding of information system, let us learn
types of information systems and their roles in an organization. 36
2.2 Types of Information Systems and their roles in an Organization 36
2.2.1 Transaction Processing Systems 37
7
References 47
Study Session 3: System Development Methodology 48
Introduction 48
Reference 59
Study Session 4: System Development Life Cycle (SDLC) 60
Introduction 60
Introduction 81
References 123
Study Session 6: Modelling and Analysis of Information System 124
Introduction 124
References 137
Study Session 7: Modelling and Analysis of Information System-II 138
8
Introduction 138
References 161
Study Session 8: Data Modelling--I 162
Introduction 162
Study Session 9: Data Modelling--II 180
Introduction 180
9
Timeframe
This is a one semester course.
45 hours of formal study time is required.
How long?
Study skills
As an adult learner your approach to learning will be different
to that from your school days: you will choose what you want
to study, you will have professional and/or personal
motivation for doing so and you will most likely be fitting
your study activities around other professional or domestic
responsibilities.
Essentially you will be taking control of your learning
environment. As a consequence, you will need to consider
performance issues related to time management, goal setting,
stress management, etc. Perhaps you will also need to
reacquaint yourself in areas such as essay planning, coping
with exams and using the web as a learning resource.
Your most significant considerations will be time and space
i.e. the time you dedicate to your learning and the
environment in which you engage in that learning.
We recommend that you take time now—before starting your
self-study—to familiarize yourself with these issues. There are
a number of excellent web links & resources on the Course
CD. Go to ―Self-Study Skills‖ menu in course CD.
10
Need help?
You may contact any of the following units for information,
learning resources and library services.
Help Head Office

Computer Based Centre and Administrative Building
Complex, University of Ibadan, Ajibode-Extension.
Tel: (+234) 08061400584, 08061984661, 07082807899
(Student Support Officers)
Email: ssu@dlc.ui.edu.ng
Information Centres 16, Ajanaku Street,

20 Awolowo Road, Bodija, Off Salvation Bus Stop,
Ibadan. Awuse Estate, Opebi, Ikeja
Lagos
For technical issues (computer problems, web access, and
etcetera), please send mail to webmaster@dlc.ui.edu.ng.
Academic Support
A course facilitator is commissioned for this course. You have
also been assigned an academic advisor to provide learning
support. The contacts of your course facilitator and academic
Help advisor for this course are available at
onlineacademicsupport@dlc.ui.edu.ng
11
Activities
This manual features ―Activities‖, which may present material
that is NOT extensively covered in the Study Sessions. You
will be provided with answers to every activity question.
Activities Therefore, your emphasis when working the activities should
be on understanding your answers. It is more important that
you understand why every answer is correct.
There are different forms of activities in this manual, ranging
from reading activities, case studies, discussion activities. The
use of activities is particularly based on learning outcomes
and nature of content. Some Study Sessions comes with
discussion topics. You may discuss the Study Sessions at
respective discussion boards on course website.
You may see dates for active discussion with tutor on course
schedule. This course schedule is available on the course
website.
Assignment
This manual also comes with tutor marked assignments
(TMA). Assignments are expected to be turned-in on course
website. You may also receive TMAs as part of online class
Assignment activities. Feedbacks to TMAs will be provided by your tutor
in not more than 2-week expected duration.
Schedule dates for submitting assignments and engaging in
course / class activities is available on the course website.
Kindly visit your course website often for updates.
Assessments
There are two basic forms of self - assessment in this course:
in-text questions (ITQs) and self - assessment questions
Assessments (SAQs). Feedbacks to the ITQs are placed immediately after
the questions, while the feedbacks to SAQs are at the back of
manual. You will receive your TMAs as part of online class
activities at the UI Mobile Class. Feedbacks to TMAs will be
provided by your tutor in not more than 2-week expected
duration.
Schedule dates for submitting assignments and engaging in
course / class activities is available on the course website.
Kindly visit your course website often for updates.
12
About this Course
CSC 302 (System Analysis) is a three [3] credit unit course dealing with the fundamental
concepts of the analysis and design of Computer Based Information Systems. Several
structured approaches to system analysis are explored in the course.
The study material provides in depth background information that is relevant for students to
understand and be able to develop information systems. The course contents are divided into
several units with the first unit expatiating on the fundamental concepts and meaning of
systems. Each session ends with some self assessment questions.
Structured System Analysis and Design is an important field in computing; its understanding
and know-how serve as a solid foundation for the development and deployment of reliable
computing resources. In the light of the above, the overall objectives of the course include:
 Understanding of Systems concepts
 Understanding of what systems requirements are and how they are gathered
 Description of models and analysis of information systems
 To model events that happen in systems
 To describe the data information systems operate with
The Course Contents

Advanced study and application of structured analysis and design methods throughout the
system life cycle. Common approaches for gathering requirements, modelling, analyzing and
designing information systems. Managing the complexity of system development projects is
also addressed. 3 Units, Required.
13
Study Session 1: Meaning and Fundamental Concepts of Systems
Expected duration: 1 week or 3 contact hours
Introduction
You are familiar with the concept of a system because you learned some fundamental
concepts about it in your lower classes. In this session you will learn more on everything you
need to know about the concept of system analysis, design, its characteristics, and the
numerous types of systems in great detail. The term system is derived from the Greek word
systema, which indicates a well-organized interaction between working units or components.
The study units are divided session by session for easier comprehension, and each session has
a learning outcome and students‘ assessment questions that will assist you in measuring your
level of comprehension.
Learning Outcomes for Study Session 1
When you have studied this session, you should be able to:
1.1 Explain the meaning of System. (SAQ 1.1)
1.2 List the characteristics of a System (SAQ 1.2)
1.3 Describe the Important Concepts of a System: Decomposition, Modularity, Coupling
and Cohesion (SAQs 1.3)
1.4 State the Types of Systems and define computer-based information system (SAQ1.4).
1.5 Differentiate between Computers, Information Systems and information technology
(SAQ 1.5)
1.1 What is a System?
A set of interrelated, interconnected or interdependent elements that operates collectively to
accomplish some common purpose or goal, is called SYSTEM.‖ Understanding systems and
how they work is critical to understanding systems analysis and design.
A system exists because it is designed to achieve one or more objectives. Every day, we come
in contact with the transportation system, the telephone system, the accounting system, the
production system, and, for over two decades, the computer system. Similarly, we talk of the
business system and of the organization as a system consisting of interrelated departments
(subsystems) such as production, sales, personnel, and an information system. None of these
14
subsystems is of much use as a single, isolated unit. However, when these subsystems are
properly coordinated, the firm can function effectively and profitably.
In order to have a good understanding of what systems analysis and design is, it is imperative
to understand systems and how they work. There are more than a hundred definitions of the
word system, but most seem to have a common thread that suggests that a system is an
orderly grouping of interdependent components linked together according to a plan to achieve
a specific objective. The word component may refer to physical parts (engines, wings of
aircraft, car), managerial steps (planning, organizing and controlling), or a system in a multi
level structure. The component may be simple or complex, basic or advanced. They may be
single computer with a keyboard, memory, and printer or a series of intelligent terminals
linked to a mainframe computer. In either case, each component is part of the total system
and has to do its share of work for the system to achieve the intended goal. This orientation
requires an orderly grouping of the components for the design of a successful system.
A system can therefore be defined as an interrelated set of business procedures (or
components) used within one business unit, working together for some purpose. For example,
a system in the payroll department keeps track of cheques, whereas an inventory system
keeps track of supplies. The two systems are separate. A system has nine characteristics,
seven of which are shown in figure 1.1. A detailed explanation of each characteristic is given
below the figure, but from the figure you can see that a system exists within a larger world,
an environment. A boundary separates the system from its environment. The system takes
input from outside, processes it, and sends the resulting output back to its environment. The
arrows in the figure show this interaction between the system and the world outside of it.
ITQ/ITQ answer
o A system is an interrelated set of business procedures used within one business unit,
working together for some purpose. True/False:
 True
Now that you are able to have a good grasp of what a System is, let us learn its characteristic
in details.
15
1.2 Characteristics of a System
Figure 1.1: Seven Characteristics of a System

The characteristics that are present in all systems are explained below:
1. System components: A system is made up of components. A system component is
either an irreducible part or an aggregate of parts, also called a subsystem. The simple
concept of a component is very powerful. For example, just as with an automobile or
a stereo system, with proper design, we can repair or upgrade the system by changing
individual components without having to make changes throughout the entire system
2. Interrelated components: The components are interrelated; that is, the function of one
is somehow tied to the functions of the others. For example, the work of one
component, such as producing a daily report of customer orders received, may not
progress successfully until the work of another component is finished, such as sorting
customer orders by date of receipt.
3. Boundary: The entity which separate system from environment is called Boundary. A
system has a boundary, within which all of its components are contained and which
establishes the limits of a system, separating it from other systems. Components
within the boundary can be changed, whereas systems outside the boundary cannot be
changed.
4. Purpose: All of the components work together to achieve some overall purpose for the
larger system: the purpose is the system‘s reason for existing.
5. Environment: In systems theory the term 'environment' is defined as the set of all
objects a change in whose attributes affects the system as well as those objects whose
attributes are changed by the behaviour of the system. Like system, environment is
16
also a set of elements operating together to achieve common goal. These elements
surrounds the system and often interacts with it i.e. system exists within an
environment. The environment is everything outside the system‘s boundary that
influences the system. For example, the environment of a university includes
prospective students, foundations and funding agencies, and the news media. Usually
the system interacts with its environment. A university interacts with prospective
students by having open houses and recruiting from local high schools. An
information system interacts with its environment by receiving data (raw facts) and
information (data processed in a useful format). Figure 1.2 shows how a university
can be seen as a system.
6. Interfaces: The points at which the system meets its environment are called interfaces;
an interface also occurs between subsystems.
7. Constraints: These are the limits (in terms of capacity, speed, or capabilities) a
system must face while carrying out its functions. These limits affect what the system
can do and how it can achieve its purpose within its environment. Some of these
constraints are imposed inside the system (e.g., a limited number of skilled personnel
available in the organization), and others are imposed by the environment (e.g., due
dates or government regulations).
8. Input: A system takes input from its environment in order to function. People, for
example, take in food, oxygen, and water from the environment as input.
9. Output: A system returns output to its environment as a result of its functioning and
thus achieves its purpose.
In-text Question & Answer

o The points at which the system meets its environment are called --------
 Interfaces
1.3. Important System Concepts

The study of systems concepts has three basic implications:
1. A system must be designed to achieve a predetermined objective.
2. Interrelationships and interdependence must exist among the components.
3. The objectives of the organization as a whole have a higher priority than the objectives of
its subsystems. For example, computerizing personnel applications must conform to the
organization‘s policy on privacy, confidentiality and security, as well as making selected data
(e.g. payroll) available to the accounting division on request.
17
Figure 1.2: A University as a System
Several important systems concepts systems analysts need to know are as follow:
i. Decomposition
ii . Modularity
iii. Coupling
i v. Cohesion
Decomposition is the process of breaking down a system into its smaller component parts.
These components may themselves be systems (subsystems) and can be broken down into
their components as well. How does decomposition aid understanding of a system? It results
in smaller and less complex pieces that are easier to understand than larger, complicated
pieces.
Decomposing a system also allows us to focus on one particular part of a system, making it
easier to think of how to modify that one part independently of the entire system.
Decomposition is a technique that allows the systems analyst to:
a. Break a system into small, manageable, and understandable subsystems
b. Focus attention on one area (subsystem) at a time, without interference from other
areas
18
c. Concentrate on the part of the system pertinent to a particular group of users, without
confusing users with unnecessary details
d. Build different parts of the system at independent times and have the help of different
analysts
Modularity is a direct result of decomposition. It refers to dividing a system into chunks or
modules of a relatively uniform size. Modules can represent a system simply, making it easier
to understand and easier to redesign and rebuild. For example, each of the separate subsystem
modules for the MP3 player in Figure 1.3 shows how decomposition makes it easier to
understand the overall system.
Coupling means that subsystems are dependent on each other. Subsystems should be as
independent as possible. If one subsystem fails and other subsystems are highly dependent on
it, the others will either fail likewise or have problems functioning. Looking at Figure 1.3, we
would say the components of an MP3 player are tightly coupled. The best example is the
control system, made up of the printed circuit board and its chips. Every function the MP3
player can perform is enabled by the board and the chips. A failure in one part of the circuit
board would typically lead to replacing the entire board rather than attempting to isolate the
problem on the board and fix it. Even though repairing a circuit board in an MP3 player is
possible, it is typically not cost-effective; the cost of the labor expended to diagnose and fix
the problem may be worth more than the value of the circuit board itself. Conversely, in a
home stereo system, the components are loosely coupled because the subsystems, such as the
speakers, the amplifier, the receiver, and the CD player, are all physically separate and they
function independently. If the amplifier in a home stereo system fails, only the amplifier
needs to be repaired.
Cohesion is the extent to which a subsystem performs a single function. In the MP3 player
example, supplying power is a single function.
This brief discussion of systems should better prepare you to think about computer-based
information systems and how they are built. Many of the same principles that apply to
systems in general apply to information systems as well.
19
Figure 1.3: An MP3 player as a System with power supply, storage and control subsystems.

o Can you list the various concept of a system the analyst need to know?
 The concept of a system the analyst need to know include decomposition,
Modularity, coupling, and cohesion
1.4. Types of Systems

Let us start by identifying various ways of system classification. The context within which
one views a system is related to the use of the systems approach for analysis. Systems have
been classified in different ways. Popular classifications are:
i. Physical or Abstract Systems
ii. Open or Closed Systems
iii. Deterministic or Probabilistic Systems and
iv. Man-made Information Systems

Physical systems are tangible entities that may be static or dynamic in operation.
For example, the physical parts of the computer centre are the officers, desks, and chairs that
facilitate operation of the computer. They can be seen and counted; they are static. In
contrast, a programmed computer is a dynamic system. Data, programs, output, and
20
applications change as the user‘s demands or the priority of the information requested
changes.
Abstract systems (also known as conceptual systems or non-physical entities) are orderly
arrangement of concepts, ideas, of theories. For example – Theology is a system of orderly
arrangement of ideas about God and its relationship with Human. They may be as
straightforward as formulas of relationships among sets of variables or models – the abstract
conceptualization of physical situations. A model is a representation of a real or a planned
system. The use of models makes it easier for the analyst to visualize relationships in the
system under study. The objective is to point out the significant elements and the key
interrelationships of a complex system.

Another classification of systems is based on their degree of independence. An open system
has many interfaces with its environment. It permits interaction across its boundary; it
receives inputs from and delivers outputs to the outside. An information system falls into this
category, since it must adapt to the changing demands of the user. In contrast, a closed
system is isolated from environmental influences. In reality, a completely closed system is
rare. In systems analysis, organizations, applications and computers are invariably open,
dynamic systems influenced by their environment.
A focus on the characteristics of an open system is particularly timely in the light of present
day business concerns with computer fraud, invasion of privacy, security controls, and ethics
in computing. Whereas the technical aspects of systems analysis deal with internal routines
within the user‘s application area, systems analysis as an open system tends to expand the
scope of analysis to relationships between the user area and other users and to environmental
factor that must be considered before a new system is finally approved. Furthermore, being
open to suggestions implies that the analyst has to be flexible and the system being designed
has to be responsive to the changing needs of the user and the environme nt.
Five important characteristics of open systems can be identified.

1. Input from outside: Open systems are self- adjusting and self-regulating.
When functioning properly, an open system reaches a steady state or equilibrium.
In a retail firm, for example, a steady state exists when goods are purchased and sold
without being either out of stock or overstocked. An increase in the cost of goods
forces a comparable increase in prices or decrease in operating costs. This response
gives the firm its steady state.
21
2. Entropy: When system is put in use it depreciates. The quantitative measure of
depreciation is called Entropy. If it is continue to exist in the system the system
terminates soon in future.
All dynamic systems tend to run down over time, resulting in entropy or loss of
energy. To offset the increase in entropy requires inputs of matter and energy to repair
the system and extend its termination. Open systems resist entropy by seeking new
inputs or modifying the processes to return to a steady state. This maintenance input is
called as Negative Entropy. Open system require more negative entropy than
relatively closed system.
3. Process, output and cycles: Open systems produce useful output and operate in
cycles, following a continuous flow path.
4. Differentiation: Open systems have a tendency toward an increasing specialization of
functions and a greater differentiation of their components. In business, the roles of
people and machines tend toward greater specialization and greater interaction. This
characteristic offers a compelling reason for the increasing value of the concept of
systems in the systems analyst‘s thinking.
5. Equifinality: means that the same or similar results can be achieved by using a
variety of different processes. For example, management can achieve the same results
by using different inputs or by using different processes with the same inputs.
Equifinality suggests that there is no one right way to accomplish important results in
an organization. In most systems, there is more of a consensus on goals than on paths
to reach the goals. However, closed systems have one right way to do things. For
example, in heavily bureaucratic organizations, a person must finish the necessary
procedures regardless of how useful an intended result will be for the organization –
the focus is on doing things right, rather than doing the right things.
Understanding system characteristics helps analysts to identify their role and relate their
activities to the attainment of the firm‘s objectives as they undertake a system project.
Analysts are themselves part of the organization. They have opportunities to adapt the
organization to changes through computerized application so that the system does not ―run
down.‖ A key to this process is information feedback from the prime user of the new system
as well as from top management.
The theme of the process of designing information systems borrows heavily from a general
knowledge of systems theory. The objective is to make a system more efficient by modifying
its goals or changing the outputs.
22
iii. Deterministic or Probabilistic Systems
A deterministic system is one in which the occurrence of all events is perfectly predictable. If
we get the description of the system state at a particular time, the next state can be easily
predicted. An example of such a system is a numerically controlled machine tool.
Probabilistic system is one in which the occurrence of events cannot be perfectly predicted.
An example of such a system is a warehouse and its contents.
Ideally, information reduces uncertainty about a state or event. For example, information that
the wind is calm reduces the uncertainty that the boat trip will be pleasant. An information
system is the basis for interaction between the user and the analyst. It provides instruction,
commands and feedback. It determines the nature of the relationships among decision-
makers. In fact, it may be viewed as a decision centre for personnel at all levels. From this
basis, an information system may be defined as a set of devices, procedures and operating
systems designed around user based criteria to produce information and communicate it to
the user for planning, control and performance. In systems analysis, it is important to keep in
mind that considering an alternative system means improving one or more of these criteria.
Many practitioners fail to recognize that a business has several information systems; each is
designed for a purpose and works to accommodate data flow, communications, decision
making, control and effectiveness.
The major business information systems are:
i. Formal Information System
ii. Informal Information System and
iii. Computer-Based Information System.
Formal Information system

A formal information system is based on the organization, represented by the organization
chart. The chart is a map of positions and their authority relationships, indicated by boxes and
connected by straight lines. It is concerned with the pattern of authority, communication and
workflow. Information is formally disseminated in instructions, memos, or reports from top
management to the intended user in the organization. This structure also allows feedback up
the chain of command for follow-up. In Figure 1.4 input from the environment provides
impetus for policy decision by top management. Policies are generalizations that specify what
an organization ought to do.
Policies are translated into directives, rules and regulations and transmitted to lower-level
management for implementation. The output represents employee performance.
23
Formal Organizational
positions
Chief Executive
Officer
Director of Director of Finance & Director of

Executive Services Accounts Operations
Department Head Department Head Lines of

Audit Authority
Purchase & Supply
Workers Workers
Figure 1.4: Organizational chart showing Formal Information System
Informal Information Systems

The formal information system is a power structure designed to achieve company goals. An
organization‘s emphasis on control to ensure performance tends to restrict the communication
flow among employees, as a result, an informal information system develops. It is an
employee based system designed to meet personnel and vocational needs and to help solve
work-related problems. It also funnels information upward through indirect channels. In this
respect, it is a useful system because it works within the framework of the business and its
stated policies.
While carrying out a systems study, the analyst should have knowledge of the chain of
command, the power-authority-influence network, and how decisions are made to get a feel
for how much support can be expected for a prospective installation. Furthermore, knowledge
about the inner workings of the employee-based system is useful during the exploratory
phase of analysis. Employee cooperation and participation are crucial in preventing sabotage
and training users. Since computers cannot provide reliable information without user staff
support, a proper interface with the informal communication channels could mean the
difference between the success and failure of new systems.
24
1.5. Computer-Based Information Systems
A computer-based information system (CBIS) is an information system that uses computer
technology to perform some or all of its intended tasks. This is a type of information system
that relies on the computer for handling business applications. Such a system can include as
little as a personal computer and software. Or it may include several thousand computers of
various sizes with hundreds of printers, plotters, and other devices, as well as communication
networks (wire-line and wireless) and databases. In most cases an information system also
includes people. The basic components of information systems are listed below. Note that not
every system includes all these components.
Components of Information Systems

1. Resources of people: (end users and Information System specialists, system analyst,
programmers, data administrators etc.).
2. Hardware: (Physical computer equipments and associate device, machines and media).
3. Software: (programs and procedures).
4. Data: (data and knowledge bases), and
5. Networks: (communications media and network support).
People Resources
• End users: (also called users or clients) are people who use an information system or the
information it produces. They can be accountants, salespersons, engineers, clerks,
customers, or managers. Most of us are information system end users.
• IS Specialists: people who actually develop and operate information systems. They include
systems analysts, programmers, testers, computer operators, and other managerial,
technical, and clerical IS personnel. Briefly, systems analysts design information systems
based on the information requirements of end users, programmers prepare computer
programs based on the specifications of systems analysts, and computer operators operate
large computer systems.
25
Hardware Resources
 Machines: as computers and other equipment along with all data media, objects on
which data is recorded and saved.
 Computer systems: consist of variety of interconnected peripheral devices. Examples
are microcomputer systems, midrange computer systems, and large computer systems.
Software Resources: Software Resources includes all sets of information processing
instructions. This generic concept of software includes not only the programs, which direct
and control computers but also the sets of information processing (procedures). Software
Resources includes:
• System software, such as an operating system
• Application software, which are programs that direct processing for a particular use of
computers by end users.
• Procedures, which are operating instructions for the people, who will use an information
system. Examples are instructions for filling out a paper form or using a particular
software package.
Data Resources
Data resources include data (which is raw material of information systems) and database.
Data can take many forms, including traditional alphanumeric data, composed of numbers
and alphabetical and other characters that describe business transactions and other events and
entities. Text data, consisting of sentences and paragraphs used in written communications;
image data, such as graphic shapes and figures; and audio data, the human voice and other
sounds, are also important forms of data.
The data resources of IS are typically organized into:
 Processed and organized data-Databases.
 Knowledge in a variety of forms such as facts, rules, and case examples about
successful business practices.
Data resources must meet the following criteria:
i. Comprehensiveness: means that all the data about the subject are actually present
in the database.
ii. Non-redundancy: means that each individual piece of data exists only once in the
database.
iii. Appropriate structure: means that the data are stored in such a way as to minimize
the cost of expected processing and storage.
26
Network Resources: Telecommunications networks like the Internet, intranets, and extranets
have become essential to the successful operations of all types of organizations and their
computer-based information systems. Telecommunications networks consist of computers,
communications processors, and other devices interconnected by communications media and
controlled by communications software. The concept of Network Resources emphasizes that
communications networks are a fundamental resource component of all information systems.
Network resources include communications media, and network support:
Here, the computer is deployed as the source of information. Computer-based information

systems provide a powerful means of gaining new insight into, and control over, business
functions and to assist directly in knowledge sharing activities in all organizational areas. The
ultimate goal is the integration of information processing in order to create a knowledge
environment in which organizational members can regard and understand the organization in
new ways. Systems analysis relies heavily on computers for problem solving. This suggests
that the analyst must be familiar with computer technology and have experience in handling
people in an organizational context. This type of Information System is the focal point in this
text.

o Identify four types of systems
 There are four types of systems. These are

1 Physical or Abstract Systems
2. Open or Closed Systems,
3.Deterministic or Probabilistic Systems
4.Man-made Information Systems
27
1.6 Difference between Computers and Information Systems
Computers provide effective and efficient ways of processing data, and they are a necessary
part of an information system. An IS, however, involves much more than just computers. The
successful application of an IS requires an understanding of the business and its environment
that is supported by the IS. In learning about information systems, it is therefore not sufficient
just to learn about computers. Computers are only one part of a complex system that must be
designed, operated, and maintained. A public transportation system in a city provides an
analogy. Buses are a necessary ingredient of the system, but more is needed. Designing the
bus routes, bus stops, different schedules, and so on requires considerable understanding of
customer demand, traffic patterns, city regulations, safety requirements, and the like.
Computers, like buses, are only one component in a complex system.

o Is computer a part of information system? Answer Yes or No
 The answer is yes. Computer is a part of information system
1.7 Information Technology and Information Systems

Information technology is broadly defined as the collection of computer systems used by an
organization. Information technology, in its narrow definition, refers to the technological side
of an information system. It includes the hardware, software, databases, networks, and other
electronic devices. It can be viewed as a subsystem of an information system. Sometimes,
though, the term information technology is also used interchangeably with information
system.
The term IT in its broadest sense used to describe an organization‘s collection of information
systems, their users, and the management that oversees them.
A major role of IT is being a facilitator of organizational activities and processes. That role
will become more important as time passes. Therefore, it is necessary that every manager and
professional staff member learn about IT not only in his or her specialized field, but also in
the entire organization and in inter-organizational settings as well.
Obviously, you will be more effective in your chosen career if you understand how
successful information systems are built, used, and managed. You also will be more effective
if you know how to recognize and avoid unsuccessful systems and failures. Also, in many
ways, having a comfort level with information technology will enable you, off the job and in
your private life, to take advantage of new IT products and systems as they are developed.
28
(Wouldn‘t you rather be the one explaining to friends how some new product works, than the
one asking about it?) Finally, you should learn about IT because being knowledgeable about
information technology can also increase employment opportunities. Even though
computerization eliminates some jobs, it also creates many more.
The demand for traditional information technology staff—such as programmers, systems

analysts, and designers—is substantial. In addition, many excellent opportunities are
appearing in emerging areas such as the Internet and e-commerce, m-commerce, network
security, object-oriented programming, telecommunications, multimedia design, and
document management.

o -----------------is a collection of computer systems used by an organization.
 Information technology
In the next study section, we review different types of Information Systems that are used by
various organizations for effective running of their business activities.
Activity 1.1 Patterns of communication in an organisation

Take a moment to reflect on what you have read so far. Based on your learning experience,
and knowing that system has a wide scope, note down some of the keys in formal information
system?
Activity 1.1 Feedback:
A formal information system is represented by the organization chart. The chart is a map of
positions and their authority relationships, indicated by boxes and connected by straight lines.
It is concerned with the pattern of authority, communication and workflow
29
Take a look at figure 1.4; it describes the various patterns of authority,
communication and workflow in an organisation
Formal Organizational
positions
Chief Executive
Officer
Director of Director of Finance & Director of

Executive Services Accounts Operations
Department Head Department Head Lines of

Audit Authority
Purchase & Supply
Workers Workers
Figure 1.4: Organizational chart showing Formal Information System
 For us to meaningfully learn about system there is a need to understand some

fundamental concepts of a system and its importance. In other words the meaning and
concept of a system are explained in Box 1.1
30
Box 1.1: Meaning and Fundamental Concepts of Systems
System is a set of interrelated, interconnected or interdependent elements that operates
collectively to accomplish some common purpose or goal.
It is important to note:
 A system exists because it is designed to achieve one or more objectives.
 A system is made up of components. A system component is either an
irreducible part or an aggregate of parts, also called a subsystem.
 A system has characteristics which include system component, Interrelated
components, Boundary, Purpose: Environment, Interfaces, Constraints: Input:
and output
 The study of systems concepts has three basic implications which are:
1. A system must be designed to achieve a predetermined objective.
2. Interrelationships and interdependence must exist among the components.
3. The objectives of the organization as a whole have a higher priority than the
objectives of its subsystems.
 The term information system is also used interchangeably with information
technology
Also, note that the term IT means information technology, information technology in its
broadest sense used to describe an organization‘s collection of information systems,
their users, and the management that oversees them. However, it can be narrowly
defined as the technological side of an information system.
Summary of Study Session 1

In Study Session 1, you have learned that:
1. The fundamental concepts of a system are Decomposition, Modularity, Coupling
Cohesion.
2. A system is made up of as an interrelated set of business procedures or components
used within one business unit, working together for some purpose.
3. A system is an organized relationship among functioning units or components.
4. The context within which one views a system is related to the use of the systems
approach for analysis.
5. The most common classifications of system are Physical or Abstract Systems, Open or
Closed Systems, Deterministic or Probabilistic and Man-made Information Systems.
Self-Assessment Questions (SAQs) for Study Session 1
Now that you have completed this study session, you can assess how well you have achieved
its Learning Outcomes by answering these questions. You can check your answers with the
Notes on the Self-Assessment Questions at the end of this Module.
31
SAQ 1.1 (tests learning outcome 1.1)
Can you explain the meaning of a System?
Can you list the characteristics of a System?
Can you describe the following terms: modularity, coupling and cohesion?
Can you State the Types of Systems and define computer based system?
Can you define computer-Based Information Systems?
SAQ 1.5 (tests learning outcome 1.5 & 1.6)
Can you differentiate between computers, information technology and Information Systems?
Notes on the Self-Assessment Questions (SAQs) for Study Session 1
SAQ 1.1: System is a set of interrelated, interconnected or interdependent elements that
operates collectively to accomplish some common purpose or goal
SAQ 1.2: The characteristic of a system are system components, Interrelated components,
Boundary, Purpose, Environment, Interfaces, Constraints, Input and output
SAQ 1.3: The concept of a system includes
1 Decomposition: This is a process of breaking down a system into its smaller
component parts. These components may themselves be systems (subsystems) and
can be broken down into their components as well. Decomposing a system also allows
us to focus on one particular part of a system, making it easier to think of how to
modify that one part independently of the entire system. Decomposition is a technique
that allows the systems analyst to:
a. Break a system into small, manageable, and understandable subsystems

b. Focus attention on one area (subsystem) at a time, without interference from other
areas
c. Concentrate on the part of the system pertinent to a particular group of users, without
confusing users with unnecessary details
d. Build different parts of the system at independent times and have the help of different
analysts
2 Modularity: This is a direct result of decomposition. It refers to dividing a system into
chunks or modules of a relatively uniform size. Modules can represent a system simply,
making it easier to understand and easier to redesign and rebuild.
32
3. Coupling: This is a situation in which subsystems are dependent on each other.
Subsystems should be as independent as possible. If one subsystem fails and other
subsystems are highly dependent on it, the others will either fail likewise or have problems
functioning.
4 Cohesion: This is the extent to which a subsystem performs a single function. In the MP3
player example, supplying power is a single function.
SAQ 1.4: System can be classified into the following group
iii. Deterministic or Probabilistic Systems and
A computer-based information system is an information system that uses computer
technology to perform some or all of its intended tasks. This is a type of
information system that relies on the computer for handling business applications.
SAQ 1.5 Computers provide effective and efficient ways of processing data, and they are a
necessary part of an information system while information system involves much
more than just computers. The successful application of an information system
requires an understanding of the business and its environment that is supported by
the information system. Information technology is the technological side of an
information system. This includes the hardware, software, databases, networks, and
other electronic devices, on the other hand, information system involves much
more than just computers. It requires an understanding of the business and its
environment that is supported by the IS
33
References
Alter, S. (1992): Information Systems: A Management Perspective. Redwood City, CA:
Benjamin/Cummings Publishing.
Alan Dennis, Barbara Haley Wixom, and Roberta M. Roth (2012): Systems analysis and
design. 5th edition, John Wiley & Sons, Inc.
Alexander Laszlo and Stanley Krippner (1998): Systems Theories: Their Origins,
Foundations, and Development. J.S. Jordan (Ed.), Systems Theories and A Priori Aspects of
Perception. Amsterdam: Elsevier Science, Ch. 3, pp. 47-74.
Dr. Jawahar Vetter and Prof. Dharminder Kumar. Overview of System Analysis & Design.
Lesson No: 1 Lesson
F.A. Wilson: Computer-Based Information Systems and Knowledge Management:
Contrasting the Objectivist and Subjectivist Perspectives. Information Systems Institute
University of Salford Salford England
Information Systems Concepts: Retrieved June 26, 2016 from http://www.wirc-
icai.org/material/1- information-system-concepts.pdf
Joseph S. Valacich, Joey F. George, and Jeffrey A. Hoffer. (2012): Essentials of Systems
Analysis and Design. 5th Edition, Prentice Hall.
Sprague, R. H., Jr. (1980): A Framework for the Development of Decision Support Systems.
MIS Quarterly 4(4):1-26.
34
Study Session 2: Overview of Information System
Introduction
You learned the definition of a system in Study Session One. You discovered that the term
system is derived from the Greek word systema, which indicates a well-organized
relationship among functional units or components. This session will be more concerned with
information systems.
Information system here is what we referred to as computer-based information system in the
previous chapter. Information systems have become the backbone of most organizations. In
almost every sector; banking, health care, government, manufacturing, education, business
etc, information systems play a prominent role by supporting the activities in those sectors.
Every day work, communication, information gathering, and decision making all rely on
information technology (IT). When we visit a travel agency to book a trip, a collection of
interconnected information systems is used for checking the availability of flights and hotels
and for booking them. When we make an electronic payment, we interact with the bank‘s
information system rather than with personnel of the bank. Modern supermarkets use IT to
track the stock based on incoming shipments and the sales that are recorded at cash registers.
Most companies and institutions rely heavily on their information systems. Organizations
such as banks, online travel agencies, tax authorities, and electronic bookshops can be seen as
IT companies given the central role of their information systems.
When you have studied this Unit, You should be able to explain:
2.1 Explain the meaning of Information System (SAQ 2.1).
2.2 List the different types of Information Systems (SAQ 2.2)
2.3 Define artificial intelligence (SAQ 2.3)
2.4 Explain the role of scientific and engineering computing system in the field of
engineering (SAQ 2.4).
35
2.1 Definition of Information Systems
Organizations offer products to customers to make money. These products can be goods or
services. In most organizations, huge volumes of data accumulate: data of products, data of
customers, data of employees, data of the delivery of products, and data of other sources.
These data therefore play an important role in contemporary organizations and must be
stored, managed, and processed, which is where information systems come into play.
Before we provide our definition of an information system, we first explain the term
―information,‖ which can mean any of the following:
1. The communication act of one agent—the term ―agent‖ may refer to any entity ranging
from a person or a software component to an organization—informing another agent (e.g., by
exchanging messages);
2. The knowledge or beliefs of agents as a part of their mental state; or
3. (Data) objects that represent knowledge or beliefs.
An information system is a software system that captures, transmits stores, retrieves,
manipulates, or displays information, thereby supporting people, organizations, or other
software systems. Information system deals with the organizational data, computer hardware,
software, network, people, and procedures.

o ------------ is a software system that captures, transmits stores, retrieves, manipulates,
or displays information, thereby supporting people, organizations, or other software
systems.
 An information system
Now that you are able to have a good understanding of information system, let us learn types
of information systems and their roles in an organization.
2.2 Types of Information Systems and their roles in an Organization

Given the broad range of people and interests represented in organizations, it could take
several different types of information systems to satisfy all of an organization‘s information
system needs. Traditionally, organizations have considered four types of information
systems: Transaction Processing Systems, Management Information Systems, Decision
Support Systems, and Expert Systems. Decision support system is further broken down into
those for individuals, groups, and executives. Then we will briefly outline two categories of
information systems, Scientific (or technical) Computing and Office Automation Systems,
which are recognized in many organizations. As a systems analyst, part of your job will be to
36
determine which kind of system will best address the organizational problem or opportunity
on which you are focusing. In addition, different classes of systems may require different
methodologies, techniques, and tools for development.
Figure 2.1: Depiction of three classes of Information System: TPS, MIS and DSS
2.2.1 Transaction Processing Systems

The first type of information systems built were transaction processing systems (TPS), which
are computer-based versions of manual processes used in organizations. Transaction
processing systems automate the handling of transactions, which are individual simple events
in the life of an organization. For instance, in a banking system, transactions occur when a
customer deposits some amount of money into his account or makes withdrawals from the
money in his account; Data about each transaction are captured, transactions are verified and
accepted or rejected, and validated transactions are stored. A record is made of each
transaction that occurs. All of these records were originally kept on paper. However, with
transaction processing systems, reports may be produced immediately to provide summaries
of transactions, and transactions may be moved from process to process in order to handle all
aspects of the business activity. In the early days of computerization, someone would later
transfer the records to computer punched cards or to magnetic tape, so that the computer
could then read and manipulate the data. Now, for medium- to large-size organizations, most
transactions are captured in computer-readable form immediately at a point-of-sale terminal.
37
Figure 2.2: Transaction Processing System
When a transaction processing system processes an organization's transactions, each
transaction is available for recall later. More importantly to the organization, the number and
volume of transactions can be calculated for a given time period. For example, processing the
number of deposits per hour or per day at a bank branch allows the bank to more easily know
the cash flow and thus more effectively manage outflow of cash and request for funds into the
Automated Teller Machines. Transactions also provide the official record of business
activities, which drive other systems such as those which bill customers, pay vendors and
employees, and reorder inventory or raw materials or stocked goods. The analysis and design
of a TPS requires you to focus on the firm‘s current procedures for processing transactions.
How does the organization track, capture, process, and output data?
The goal of TPS development is to improve transaction processing by speeding it up, using
fewer people, improving efficiency and accuracy, integrating it with other organizational
information systems, or providing information not previously available.
2.2.3. Decision Support Systems (DSS)

Decision Support Systems (DSS) are a specific class of computerized information system that
supports business and organizational decision-making activities. A properly-designed DSS is
an interactive software-based system intended to help decision makers compile useful
information from raw data, documents, personal knowledge, and/or business models to
identify and solve problems and make decisions. DSS belong to an environment with
multidisciplinary foundations, including database research, artificial intelligence, human
computer interaction, simulation methods, software engineering and telecommunication.
38
Decision Support Systems are designed to help organizational decision makers make
decisions. Whereas an MIS produces a report, a DSS provides an interactive environment in
which decision makers can quickly manipulate data and models of business operations. A
DSS is characterized by less structured and predictable use. DSS software supports certain
decision-making activities (from problem finding to choosing a course of action). DSS
usually have three major components: a database, a model base, and a dialogue module.
Figure2.3 shows these components.
 The database contains data (which may be extracted from a TPS or MIS) relevant to
the decision to be made.
 The model base: It has decision models that relate to operational, tactical and strategic
decisions. In addition, the model base is able to link models together in order to solve
larger and more complex problems, particularly semi-structured problems.
 The dialogue module (or user interface): is one of the more critical features of the
system, it is used to assist the decision maker in making more efficient and effective
use of the system. Both decision makers and non-technical managers, communicate
with the DSS through this component.
The database/model base management system is the bridge between database and model base
components. It has the ability to extract data from the database and pass it to the model base
and vice versa.
Lastly, for these systems to be effective in supporting management decision, the decision
maker must have the skills and knowledge on how to correctly use these systems to address
the unique problem situation at hand.
39
Strategic
Models
T
Finance Other
R Tactical
A Internal Database Model Base Models
N
S Production Data Management Management
A
C System System Operational
T Research
I Models
O
N
Personnel External
D Model
A Data Building
T Marketing
A Blocks and
User Subroutines
Others
Interface
Data Base Model Base
Decision
Maker
Figure 2.3: Decision Support System
The systems analysis and design for a DSS often concentrates on the three major DSS
components; as with an MIS, a data orientation is most often used for understanding user
requirements. The systems analysis and design project will carefully document the
mathematical rules that define interrelationships among different data. These relationships are
used to predict future data or to find the best solutions to decision problems. Decision logic
must be carefully understood and documented. Also, because a decision maker typically
interacts with a DSS, the design of easy-to-use yet thorough user dialogues and screens is
important.
By running the data and possible decisions through one or more models, the decision maker
can compare possible solutions to the problem at hand. The DSS allows the manager to test
or propose different solutions and see what the results may be before committing to any
particular model.
The first decision support systems were designed to support individual decision makers.
When computing technology was more primitive and more difficult for non-technical people
to use, an intermediary often used the DSS for the manager. The intermediary was usually a
staff person who had the computer skills the manager lacked to work with the DSS. The
manager would then use the output to help decide which course of action to take. Due to early
40
technical limitations, each individual or specific DSS had to be designed and built one at a
time. Now, many decision support systems run on microcomputers. The models are relatively
easy to construct, change, and interpret using such software programs as electronic
spreadsheets. Tools like spreadsheets and fourth-generation language (4GLs) are called DSS
generators because they are general purpose tools that can be used to develop many specific
DSS with relative ease.
2.2.3.1 Group DSS

In the late 1970s, some companies began to develop DSS that would support groups of
decision makers. All of these commercial systems failed. However, in the mid-1980s, group
DSS (GDSS) were resurrected at several universities, including those in Arizona, Indiana,
Michigan, and Minnesota. Using a GDSS, a group of decision makers can use special
software to contribute to a problem's solution. The most common form of a GDSS consists of
a special-purpose room with a microcomputer for each group member and special
presentation equipment. The microcomputers are networked together so that group members
can share information. Group members can also view aggregates of their work, such as the
results of a group vote, on large screens. Researchers and packaged software houses, like
Lotus Development Corp., are now working on making GDSS available and useful outside of
these special-purpose rooms so that group members can join the process from their own
offices on their own schedule.
2.2.3.2 Executive Support Systems
Another relatively new form of DSS is referred to as executive support systems (ESS) or
executive information systems (EIS). Executive support systems are designed specifically for
high-level executives who:
1. May not have many computer skills
2. Have very little time to devote to any given situation
An ESS is a DSS that allows senior management to explore data starting at a high level of
aggregation and selectively drill down into specific areas where more detailed information is
required. For example, an executive who sees that sales have decreased for the month in
North Eastern Nigerian market may want to find out which segments of the market are doing
best. The executive would then ask for the same information by segment and, seeing that the
Southern Nigerian segment had the best performance, the executive may then want to see
which geopolitical zone had the best performance. Once the information is presented at this
level, the executive would see that Southern Western part of Nigeria had done the best. The
executive may then want to examine the information by city, and so on.
41
An ESS is relatively easy to manipulate and usually provides graphical presentations on
several different pre-defined topics.
o All the following are types of information systems: Transaction Processing Systems,
Management Information Systems, Decision Support Systems, Expert Systems.
True/False?
 True.
2.3 Expert Systems

Different from any of the other classes of systems we have discussed so far, expert systems
(ES) attempt to codify and manipulate knowledge rather than information. By knowledge, we
mean understanding acquired through experience, deep and extensive learning. Expert
systems are based on principles of artificial intelligence research. Artificial intelligence is the
branch of computer science devoted to creating intelligence with machines. Typically users
communicate with an ES through a dialogue during which the ES asks questions and the user
supplies the answers. The answers are then used to determine which rules apply and the ES
finishes with a recommendation based on its rules. One of the most difficult parts in building
an ES is acquiring the knowledge of the expert in the particular problem domain. Specially
trained people called knowledge engineers perform this knowledge acquisition. Knowledge
engineers are similar to systems analysts; however, they are trained to use different
techniques, as determining knowledge is considered more difficult than determining data.

o List what differentiate expert system from other information system
 Expert system codifies and manipulates knowledge rather than information.
2.4 Scientific and Office Information Systems

Although we are concerned in this book primarily with the types of information systems used
in the administration of organizations, for completeness we should also mention some other
types of information systems. We will not describe how such systems are developed,
however, as an understanding of this type of systems development requires skills beyond the
scope of the book.
One broad classification of systems is based on Scientific and Engineering Computing. These
systems support engineers in the design of new products or improvement of older ones. Their
computer support might require computer simulations or analytical models of physics or
42
chemistry properties. Computer-Aided Design (CAD) systems allow engineers to create
graphic simulations of the products they design. Engineers can then manipulate and observe
these simulations, allowing the engineers to see what a product will look like without having
to build the product first. Related to CAD is Computer-Aided Manufacturing (CAM) systems.
These systems help automate and control the manufacturing process in factories. Scientific
computing allows scientists in many fields to simulate everything from molecular movements
to global weather patterns, providing an understanding that would otherwise either not be
possible or be cost-prohibitive.
Another class of systems consists of Office Automation Systems. The term office automation
promises more than the term delivers, as the term conjures up images of offices organized
and run like automated factories. Office automation systems are usually quite basic and
include such tools as word processing and accounting information systems. Integrated office
systems that include electronic mail, calendaring features, and reminder files in addition to
word processing are also available. Electronic mail (e-mail) allows office workers to send
each other messages and files directly from their computers and is usually more convenient
than trying to reach someone by telephone. Calendaring features allow office workers to
coordinate their schedules, to reserve conference rooms, and to schedule meetings. Reminder
files provide a means for conveniently reminding ourselves of meetings and other
commitments. Office systems are rarely if ever developed in-house, but instead are purchased
or leased from hardware or software producers.

o ----------------- is a system that allows engineers to create graphic simulations of the
products they design.
 Computer-Aided Design
Activity 2.1 Decision Support Systems

and knowing that system has a wide scope, note down some of the uses of decision support
system and its components.
43
Activity 2.1: Feedback:
Decision Support Systems is helpful in guiding every business organisation in making
informed decision. A DSS provides an interactive environment in which decision makers can
quickly manipulate data and models for business operations.
Take a look at figure Figure2.3; it describes the various components: a database, a model
base, and a dialogue module.
Strategic
Models
T
Finance Other
R Tactical
A Internal Database Model Base Models
N
S Production Data Management Management
A
C System System Operational
T Research
I Models
O
N Personnel External
Model
D Data
A
Marketing Building
T
A
Blocks and
Others User Subroutines
Interface
Data Base Model Base
Decision
Maker
Figure 2.3: Decision Support System
 For us to meaningfully learn about information system there is a need to understand

some types of information system used in some fields of studies. Some types of
information systems are explained in Box 2.1
44
Box 2.1: Information Systems
An information system is a software system that captures, transmits stores, retrieves,
manipulates, or displays information, thereby supporting people, organizations, or
other software systems.
It is important to note that:
 Information system deals with the organizational data, computer hardware,
software, network, people, and procedures.
 Traditionally, organizations considered four types of information systems
which include: Transaction Processing Systems, Management Information
Systems, Expert Systems, and Decision Support Systems.
 Decision support system is further broken down into those for individuals,
groups, and executives.
 In general, there are two categories of information systems, Scientific (or
technical) Computing and Office Automation Systems, which are recognized in
many organizations.
 Other categories of information system are scientific and office information
systems. These include
1. Scientific and Engineering Computing. These systems support engineers in the
design of new products or improvement of older ones. Their computer support
might require computer simulations or analytical models of physics or
chemistry properties. Computer-Aided Design (CAD) systems allow engineers
to create graphic simulations of the products they design.
2. Office Automation Systems. Office automation systems are usually quite basic
and include such tools as word processing and accounting information systems.
Integrated office systems that include electronic mail, calendaring features, and
reminder files in addition to word processing are also available.
Also, note that the term CAD means Computer-Aided Design. CAD systems allow
engineers to create graphic simulations of the products they design. On the other hand
CAM means Computer-Aided Manufacturing. CAM systems help automate and
control the manufacturing process in factories.

1 information system is a software system that captures, transmits stores, retrieves,
2 Traditionally, information system is classified into four types, namely: Transaction
Processing Systems, Management Information Systems, Decision Support Systems,
and Expert Systems.
3 Information systems can also be categorized into Scientific (or technical) Computing
and Office Automation Systems, which are recognized in many organizations.
45

Can you explain the meaning of an information system?
Can you list the different types of information system?
Can you define artificial intelligence?
Can you explain the role of scientific and engineering computing system in the field of
engineering?
SAQ 2.1: Information system is a software system that captures, transmits stores, retrieves,
SAQ 2.2: Information system is classified into

1. Transaction Processing Systems
2. Management Information Systems
3. Decision Support Systems
4. Expert Systems.
SAQ 2.3: Artificial intelligence can be defined as the branch of computer science that is
devoted to creating intelligence with machines.
SAQ 2.4: The role of scientific and engineering computing systems in the field of
engineering is to support engineers in the design of new products or improvement of older
ones.
46
References
Alan, D., Barbara H. W., and Roberta M. R. (2012): Systems analysis and design. 5th
edition, John Wiley & Sons, Inc.
Georgiana M. (n.d.): Decision support systems. Faculty of Computer Science for Business
Management, Romanian American University, Bucharest, Romania
Joseph S. V., Joey F. G, and Jeffrey A. H., (2012): Essentials of Systems Analysis and
Design. 5th Edition, Prentice Hall.
Srinivas N.(n.d.) : Management information systems and business decision making:

review, analysis, and recommendations. Journal of Management and Marketing Research
Stephen B. H (n.d.): Management Information Systems. Department of Agricultural

Economics Michigan State University https:// mitpress.mit.edusitesdefaultfilescontent
47
Study Session 3: System Development Methodology
Introduction
In Study Session One, you learned what a system is, and in Study Session Two, you learned
about the types of information systems utilized in various organizations. You discovered that
an information system is a software system that captures, transmits, stores, retrieves,
manipulates, or displays information, thereby assisting people, organizations, or other
software systems. You will learn system development methods in this session.

3.1 Explain the methodology used to develop system. (SAQ 3.1)
3.2 Describe structured design (SAQ 3.2)
3.3 Different between System development methodology and system development life cycle
(SAQ 3.3)
3.4 Highlight Tools for Rapid Application Development (SAQ 3.4)
3.1 System development methodology

System development methodology is a standard process followed in an organization to
conduct all the steps necessary to analyze, design, implement, and maintain information
systems. It is a formalized approach of developing a system. System development life cycle
provides the guidelines for the steps or activities that need to be performed to design and
develop a system; however, it does not prescribe the method of performing the phases or
activities.
48
Methodology
A methodology provides a sequential approach of traversing the activities or tasks of
designing and developing a system. There can be multiple methodologies of developing a
system; but, there is only one systems development life cycle.
Example: You wish to fly from one place to another; however, you can go through various
routes to reach your destination. Going from one location to another is SDLC, and taking
various routes are methodologies.
The following is an example of Waterfall development methodology:
System Request
PHASE 1
Systems Planning
Pre liminary
Inve stigation Re port
PHASE 2
STOP Systems Analysis
Stop Project Replace

System Requirements
Development Document Information
System
PHASE 3
STOP
Systems Design
Stop Project System Design

Development Specification
PHASE 4
STOP Systems
Implementation
Stop Project
Development
Complete Functioning
Information System
PHASE 5
Systems Operation
& Support
O perational
Information System
Figure 3.1: The Phases and end-products of the systems development life cycle (SDLC)
49
There are several methodologies that are used to develop a system. All of these follow certain
phases of the system development life cycle. Considering the time requirement to develop a
system, these methodologies can be grouped into the following:
• Structured Design
• Rapid Application Development (RAD)
3.2 Structured Design

Structured design methodologies adopt a formal step-by-step approach to the SDLC that
moves logically from one phase to the next. Structured design methodologies can be divided
into several types as described in the following:
i. Waterfall Development: This is the original structured system design and development
methodology mentioned above. In this case, each phase of the SDLC flows downward in a
sequence like a waterfall as shown in figure 3.1. The key deliverables for each phase are
typically produced on paper (often as long documents) and are presented to the project
sponsor for approval.
Although it is possible to go backward in the SDLC (e.g., from design to analysis), it requires
substantial resources. Thus the activities of each phase are completed before moving to the
next phase.
ii. Parallel Development: The parallel development methodology attempts to address the
problem of long delays between the analysis phase and the delivery of the system. Instead of
doing the design and analysis in sequence, it performs a general design of the whole system
and then divides the project into a series of distinct sub-projects that can be designed and
implemented in parallel.
50
PLANNING
DESIGN
ANALYSIS
IMPLEMENTATION Sub-project A
DESIGN
DESIGN
IMPLEMENTATION Sub-project B
DESIGN IMPLEMENTATION
IMPLEMENTATION SYSTEM
Sub-project C
Figure 3.2: Parallel Development
iii. Spiral Model: The "spiral model" is an iterative model for software development,
described by Barry Boehm. Each iteration basically follows the Waterfall Model, but
subsequent iterations build upon previous work. Barry Boehm devised the spiral model to
address the weaknesses of the waterfall model, especially its lack of resilience in the face of
change. The spiral model focuses on addressing risks incrementally by repeating the waterfall
model in a series of cycles or rounds:
 Concept of Operation
 System Requirements
 System Product Design
 Detailed Design
 Code
 Unit Test
 Integration and Test
 Acceptance Test
 Implementation.
51
Figure 3.3: Spiral Model
It is called a "spiral" because the common illustrative diagram shows a long string of
waterfalls wrapping around a centre, emphasizing the aspect of continuous growth and
revisiting of previous work. The spiral model is an improvement on the waterfall model, as it
provides for multiple builds and provides several opportunities for customer involvement.
However, it is elaborate, difficult to manage, and does not keep all workers occupied during
all phases.
The spiral model is an approach to application development that focuses on minimizing risk.
Each transition around the spiral involves repeating the same four steps: (1) determine the
objectives, alternatives, and constraints of this iteration; (2) evaluate alternatives; identify and
resolve risks; (3) develop and verify deliverables from this iteration; and (4) plan the next
iteration.
iv. Iterative Model: The activities of phases for planning, analysis and design are repeated
until a solid system design is developed before developing the system.
52
PLANNING
ANALYSIS
DESIGN
IMPLEMENTATION
OPERATION & SUPPORT
Figure 3.4: An alternative model of the SDLC that shows the interaction of planning, analysis, design,
which leads to implementation and then to operation and support
3.3 Rapid Application Development (RAD)

RAD refers to a development life cycle designed to give much faster development and higher
quality systems than the traditional life cycle. It is designed to take advantage of powerful
development software like CASE tools, prototyping tools and code generators. The key
objectives of RAD are: High Speed, High Quality and Low Cost. Rapid application
development attempts to address both weaknesses of the structured development
methodologies: long development times and difficulty in understanding a system from a
paper-based description.
RAD is a people-centred and incremental development approach. Active user involvement,

as well as collaboration and co-operation between all stakeholders are imperative. Testing is
integrated throughout the development life cycle so that the system is tested and reviewed by
both developers and users incrementally.
Rapid Application Development is an approach to building systems which combines

Computer-Assisted Software Engineering (CASE) tools and techniques, user-driven
prototyping, and stringent project delivery time limits into a potent, tested, reliable formula
for top-notch quality and productivity. RAD drastically raises the quality of finished systems
while reducing the time it takes to build them
53
RAD methodologies adjust the SDLC phases to get some part of the system developed
quickly and place into the hands of the users, so that users can better understand the system
and provide feedback for improvement of the system.
Two common methodologies of rapid application development are: phased development and
prototyping.
Phased Development: The phased development methodology breaks the overall system into
a series of versions that are developed sequentially. The analysis phase identifies the overall
system concept, and the project team, users, and system sponsors then categorize the
requirements into a series of versions. The most important and fundamental requirements are
bundled into the first version of the system. The analysis phase then leads into design and
implementation, but only with the set of requirements identified for version 1.
Once version 1 is implemented, work begins on version 2 and follows the steps, and so on.
Any additional requirement identified during testing of the older version is implemented in
the next version.
Phased development has the advantage of quickly getting a useful system into the hands of
the users.
ANALYSIS
PLANNING
DESIGN
ANALYSIS
IMPLEMENTATION
ANALYSIS
DESIGN
IMPLEMENTATION
ANALYSIS
System Version 1
DESIGN
System Version 2
IMPLEMENTATION
System Version 3
Figure 3.5: Phased Development
54
Prototyping: The prototyping methodology performs the analysis, design, and
implementation phases concurrently, and all three phases are performed repeatedly in a cycle
until the system is completed.
In this case, the users of the system are an active participant of the system development
process. With the basic requirements from the users, a quick analysis and design of the
system is performed, and a prototype of the system containing main features of the
requirements, are developed.
The prototype is handed to the users for testing and to provide comments; which are then
reanalyzed and redesigned, and a second prototype is developed. The process continues in a
cycle until the users and developers agree to a final system.
Prototyping methodology gives a system quickly to the users‘ hands, which they can
visualize from the very beginning instead of waiting at the end of the system development.
PLANNING
ANALYSIS
SYSTEM IMPLEMENTATION
DESIGN
PROTOTYPE
IMPLEMENTATION
SYSTEM
Figure 3.6: Prototyping

o Prototyping methodology gives a system quickly to the users‘ hands, which they can
visualize from the very beginning instead of waiting at the end of the system
development. True/False?
 True
55
Now that you are able to describe system methodology, let us learn tools for rapid
applications development
3.4 Tools for Rapid Applications Development

Most RAD methodologies recommend that analysts use special techniques and computer
tools to speed up the analysis, design, and implementation phases. Two common techniques
and tools include JAD (Joint Application Design), and CASE (Computer-Aided Software
Engineering) tools.
Joint Application Design (JAD): In this approach, the sponsor company creates a task force
of users, managers, and IS professionals that works together to gather information, discuss
business needs, and define the new system requirements. This group usually meets over
periods of days or weeks.
Because of the wide range of user input, JAD produces the best possible definition of a new
system than a single analyst can provide.
CASE (Computer-Aided Software Engineering) Tools: There are software packages

available that can help speed up various phases of the SDLC, thus shortening the
development time. These tools can be used in the analysis phase to document data dictionary
(data elements, data flows, data stores, processes, and external entities), and create data-flow
diagrams.
In the design phase, CASE tools can be used to create entity-relationship diagrams and to
generate program codes in certain language such as Visual Basic. Visible Analyst, a CASE
tool from the Visible Systems Corporation can be used in the planning, analysis, design, and
code generation of a system development.

o ----------------- and --------are the special techniques and computer tools used by
analysts to speed up the analysis, design, and implementation phases in rapid
application development
 JAD (Joint Application Design), and CASE (Computer-Aided Software
Engineering) tools
56
Activity 3.1 Rapid Application Development
and knowing that RAD drastically raises the quality of finished systems while reducing the
time it takes to build them, note down common methodologies of rapid application
development?

The two common methodologies for rapid application development are: phased development
and prototyping
Take a look at figure 3.5; it describes the phased development
ANALYSIS
PLANNING
ANALYSIS DESIGN
IMPLEMENTATION
ANALYSIS
DESIGN
IMPLEMENTATION
ANALYSIS
System Version 1
DESIGN
System Version 2
IMPLEMENTATION
System Version 3
Figure 3.5: Phased Development
For us to meaningfully learn about system there is a need to understand system development
methodology and its rapid application development. In other words the meaning and concept
of a system development are explained in Box 3.1
57
Box 3.1: Meaning of Systems development methodology
System development methodology is a standard process followed in an organization to
conduct all the steps necessary to analyze, design, implement, and maintain
information systems. It is important to note:
 System development life cycle provides the guidelines for the steps or activities
that need to be performed to design and develop a system; however, it does not
prescribe the method of performing the phases or activities.
 A methodology provides a sequential approach of traversing the activities or
tasks of designing and developing a system.
 There can be multiple methodologies of developing a system; but, there is only
one systems development life cycle.
 Methods use in developing a system is grouped into two, namely:
i. Structured Design
ii. Rapid Application Development (RAD)
 RAD methodologies recommend that analysts use special techniques and

computer tools to speed up the analysis, design, and implementation phases.
 Two common techniques and tools include JAD (Joint Application Design),
and CASE (Computer-Aided Software Engineering) tools.
Also, note that the term RAD refers to a development life cycle designed to give much
faster development and higher quality systems than the traditional life cycle.
 The phased development methodology breaks the overall system into a series of
versions that are developed sequentially.

 System development methodology is a standard process followed in an organization
to conduct all the steps necessary to analyze, design, implement, and maintain
 System development life cycle provides the guidelines for the steps or activities that
need to be performed to design and develop a system.
 System development methodologies can be grouped into Structured Design and Rapid
Application Development (RAD).
 Structured design methodologies include Waterfall, Parallel, Spiral and Iterative
Models while RAD is made up of Phased development and Prototyping.
58
Can you explain the methodology used to develop a system?
Can you describe structure design?
Can you differentiate between System development methodology and system development
life cycle?
Can you state the tools for Rapid Application Development?
SAQ 3.1: Methodology used in developing a system is a standard process followed in an

organization to conduct all the steps necessary to analyze, design, implement, and maintain
SAQ 3.2: Structured design is a system development method that adopts a formal step-by-
step approach to the SDLC and proceeds logically from one phase to the next. Structured
design approaches are classified into numerous types, as follows: Parallel Development and
Waterfall Development
SAQ 3.3: System development methodology is a standard process used in an organization to
carry out all of the steps required to analyze, design, implement, and maintain information
systems, whereas the System development life cycle provides guidelines for the steps or
activities that must be carried out to design and develop a system.
SAQ 3.4: Two common tools for Rapid application development are
i. JAD (Joint Application Design), and
ii CASE (Computer-Aided Software Engineering) tools.
Reference
Introduction to Rapid Application Development. Retrieved on June 26, 2016 from
http://www.ftms.edu.my/images/Document/IMM006RAPIDAPPLICATION
DEVELOPMENT.pdf
59
Study Session 4: System Development Life Cycle (SDLC)
Introduction
You learned about system development approaches and a basic introduction to the system
development life cycle in the previous session. The system development life cycle (SDLC) is
a critical process that must be followed during the development of any system. This session
will teach you about the many actions required in the system development life cycle.

4.1. Explain System development life cycle (SDLC) (SAQ 4.1)
4.2 State the five phases of SDLC (SAQ 4.2)
4.3 Explain the two phases of system design (SAQ 4.3)
4.4. Highlights the objectives of structured system analysis and design method (SAQ 4.4)
4.5 Describe factors that necessitate the use of system development life cycle in developing
information systems (SAQ 4.5)
4.1. System development Life Cycle

The various activities, which are undertaken when developing systems, are often represented
as systems development life cycle (SDLC). System development life cycle (SDLC) is an
essential process used during the development of any system. It is the overall process of
developing, implementing, and retiring information systems through a series of multistep
process. SDLC begins with the identification of the need(s) for the system and terminates
with the formal verification of the developed system against the requirements set out at the
beginning; the system then enters the evolutionary phase of the SDLC as the business
environment and requirement change with time and events.
4.2 Activities in System Development Life Cycle
60
The series of steps used to mark the phases of development for an information system is
referred to as system development life cycle. It is a process by which systems analysts,
software engineers, and programmers build systems. The system development life cycle does
not exist by itself; it is in fact part of an overall product lifecycle.
Within the product life cycle, system will undergo maintenance to correct errors and to
comply with changes to requirements. The simplest overall form is where the product is just
software, but it can become much more complicated, with multiple software developments
each forming part of an overall system to comprise a product.
System development life cycle is a phased approach to analysis and design of a system,
which holds that systems are best developed through the use of a specific cycle of analyst and
user activities.
System analysis and design are the central phases of SDLC. In its simplest form, SDLC
consists of five phases:
 Systems planning
 Systems analysis
 Systems design
 Systems implementation
 Systems operation and support
Each phase is divided into multiple steps or activities that need to be completed.
Note, a system analyst spends most of his or her time in analyzing and designing a system
before the programmers actually develop the system; although program coding takes about
three-fourth of the total time of the system development life cycle.
61
 Project Initiation (System Request)
 Preliminary Investigation/Feasibility Study (Feasibility Report)
 Technical Feasibility
 Economic Feasibility
 Operational Feasibility  Determine Business Requirements (Requirement Definition)
 Project M anagement (Project Plan)  Analyze Requirements
 Data-Flow Diagrams; Data Dictionary
 Entity-Relationship Diagram
 System Proposal
PLANNING
ANALYSIS
 Input Design
 Output Design
 Database/File Design
 Program Design
DESIGN  Architectural Design
 Design Specification
OPERATION &  Operation

 Maintenance
S UPPORT
 Coding
 Installation
IMPLEMENTATION  T raining
 File Conversion
Figure 4.1: Typical Phases and Activities of a Systems Development Life Cycle
The number and names of the SDLC phases varies from author to author, but the five phases
depicted in figure 4.1 above i.e. System Planning, System Analysis, System Design, System
Implementation and Operation and Support are common phases. The cycle typically flows
through numerous iterations. Some authors break the planning, design, and implementation
phases further. In some cases, systems maintenance is not strictly considered as part of the
SDLC. But in all cases, the following issues are addressed in developing a system:
i. Identify a project
ii. Determine end-user‘s requirements
iii. Analyze system needs
iv. Acquire computer hardware and software (if required)
v. Design the new system
vi. Construct the new system
vii. Install the new system
viii. Maintain and improve the system
62
In each phase of the SDLC, certain steps are performed to complete the phase. In a particular
project, all steps in a particular phase may not follow a logical path, but the steps are fitted
according to the need of the system. An important outcome of each phase of the SDLC is a
document. The document from one phase provides a structure for the development of the next
phase. At each phase the system gets more elaborate and refined.
System Planning
The systems planning phase is the fundamental process of understanding why an information
system should be built and it determines how the project team will go about building it. Here,
an organization‘s total information system needs are identified, analyzed, prioritized and
arranged. Thus the planning phase can be divided into two sub-phases: Project Identification
and Selection, and Project Initiation and Planning.
Project Identification and Selection:
In this phase, someone in an organization identifies that there is a need to improve an existing
system or a new system is needed to improve business operations. Most ideas come from
outside the IT department such as marketing, accounting, etc., and managers and other
personnel get involved to initiate a process.
The initiation of this phase comes as a system request document, which provides a brief
summary of a business need and explains how a new or improved system can increase
business value of the organization.
Project Initiation and Planning:
In this phase, an analyst from the IT department gets involved. His or her purpose is to
identify clearly the nature and scope of the problems, opportunities of improvement, and
define specific solutions. This requires preliminary investigation.
Activities in this phase include interviewing prospecting users and management,
summarizing the knowledge obtained, estimating the scope of the project, and documenting
the results.
The preliminary investigation is often called a feasibility study (or feasibility analysis) as the
information gathered by the analyst is analyzed in terms of economical feasibility, technical
feasibility, and operational feasibility of the project.
• Technical Feasibility: Is the solution technically practical? Does our staff have the technical
expertise to design and build this solution?
63
• Operational Feasibility: Will the solution fulfil the end-user‘s requirements? To what
degree? How will the solution change the end-users‘ work environment? How do end-users
feel about such a solution?
• Economic Feasibility: Is the solution cost effective?
The output of the planning phase is a feasibility report that presents findings and
recommendations. It usually includes a problem definition, objective summary, and
preliminary cost-benefit analysis. The objective of this report is to determine whether the
project is feasible, i.e., whether to invest significant resources for further study or not.
The system request and the feasibility report are presented to an information systems
approval committee. If the committee approves the project, then the second step of the project
initiation occurs – project management.
During project management, the project manager creates a work plan, staffs the project, and
puts techniques in place to help him or her control and direct the project through the entire
system development life cycle.
The deliverable for project management is a project plan that describes the project team
member roles, deliverable phases, cost of each deliverable, timeline for each deliverable, and
so on.
Having a project plan at the beginning keeps the project under control in terms of time and
money. It also helps to stop the project at any step if the project runs over the budget or the
business policy of the sponsor-company changes over time.
SYSTEM ANALYSIS
Information systems analysis refers to a number of activities in the early stages of
information systems development. It can be referred to as a method used by companies to
create and maintain information systems that perform basic business functions such as
keeping track of customer names and addresses, processing orders, and paying employees.
The main purpose of systems analysis is to identify and document the requirements for an
information system to support and / or improve organizational activities. In this phase of
system development life cycle, the system analyst tries to understand the data and
information collected in the previous phase and defines requirements or needs of the new
system.
64
Some of the major tools used in structured system analysis include: Function diagram, Data
flow diagram, Data dictionary, Process specification, and Entity relationship diagram. The
systems analyst may collect further information from the users to obtain a clear picture of the
existing system and understand the requirements of the new system. He or she then analyzes
the requirements-an elaborate step termed as requirement analysis.
The most popular approach to requirement analysis is modelling. The analyst may use
process modelling tool (data flow diagrams) to chart the input, processing, and output of the
business functions in a structured graphical form. The analyst also uses data modelling tool
such as Entity-Relationship (E-R) diagrams. The analysis leads to the data dictionary
(definitions of the inputs, files, database, and outputs) and process descriptions for the new
system, but do so without expressing technical details. Essentially, the activities in this phase
focus on the general or logical design of the system (as opposed to physical design) to give an
overview of the system.
An alternative approach to requirement definition is prototyping. When end-users have

difficulty in defining requirements, the analyst uses computer tools to build a prototype, or
small-scale working model of the final system. The end-users can then react to the prototype
to help the analyst establish their requirements more easily.
During this phase, the system analyst analyzes various possible solutions to the problem.
Each candidate is evaluated for technical, operational, and economic feasibilities. Among the
possible candidate solutions analyzed, a solution is selected that defines the objectives of the
project. The selection phase determines how the new system is to be designed but only at a
very high level, without details.
The solution that offers the best combination of technical, operational, and economic
feasibilities may be selected for the next phase of the SDLC. The output of this phase is a
system proposal (or systems requirement document). The system proposal is presented to the
approval committee. If the committee approves the project, a detailed design of the system is
initiated.

o ----------------- is referred to as a number of activities in the early stages of
information systems development
 Information systems analysis
65
4.3 System Design
In a traditional SDLC environment, systems design usually started when the systems analysis
phase was done. Using the system requirements specification as a blueprint, developers
transformed the logical design into a working model that could be tested, reviewed by users,
and implemented. Today, the process is much more dynamic. In general, systems
development is faster, more flexible, and more user-oriented. The introduction of adaptive
methods such as agile development and extreme programming has changed the landscape
significantly. Depending on the project, system developers often blend traditional and
cutting-edge development methods, because what works in one situation might not work in
another.
Information systems design refers to the process of defining the software architecture,
components, modules, interfaces, and data for a software system to satisfy requirements
specified during systems analysis. In the design phase, a description of the recommended
solution is converted into logical and then physical system specifications. The design phase
decides how the system will operate, in terms of the hardware, software, and network
infrastructure; the user interface, forms, and reports that will be used; and the specific
programs, databases, and files that will be needed. Look and feel or blueprint of the system
on paper is developed in this phase. This phase introduces techniques for the design of
interfaces, menus, and databases, based on the requirement specification worked out during
the analysis phase. Any glitch in the design phase could be very expensive to solve in the
later stage of the software development. Several techniques are used for the design phase of
system development process; these include:
 Information System Design and Optimization System (ISDOS)
 Pseudo-code
 Structured design (SD)
 Jackson Design methodology (JDM)
 Hierarchy Plus Input, Process, and Output (HIPO)
 Structured Analysis and Design Technique (SADT)
 Entity Relationship Model (E-R Model)
 Data Structure Diagram (DSD)
 CASE Method and
 Semantic Data Model (SDM)
Systems design phase can be broken into two phases: logical design and physical design.
66
Logical Design
In the logical design phase, all functional features of the system chosen for development in
analysis are described independently of any computer platform. In this phase, the system
analyst uses the information collected earlier to develop a logical design of the information
system. The database structure is also defined here; and it identifies external entities and
relationships through entity-relationship (E-R) diagrams and normalization.
Physical Design
The logical specifications of the system from logical design are transformed into the
technology-specific details from which all programming and system construction can be
accomplished. This phase identifies the file and database structures, system structure,
program structure, and hardware and software necessary to implement the system. They
include:
• Database: Implementation of E-R diagram. Defines all tables in the database including field
names, field size, data type, keys, validation rules, and so on.
• Files: If the system requires any input or output file, their structures are defined. A file
definition includes information such as the record length, field names, field size, field
sequence, and so on.
• Data-Entry Forms: Data-entry forms are developed, which defines the relationships of data-
entry fields with the file or table-fields. The forms can also be used for displaying data. These
forms can be character-based or GUI-based. The analyst defines exactly how each form looks
on the computer screen.
• Menus: Menus are designed such that the forms and reports can be accessed and printed
according to the business need of the organization. It should also address the security
requirement of the organization.
• Reports: Reports are defined, which includes the relationships of the report-fields with the
table-fields, any calculations, layout, font type, font size, and so on.
• Systems and Programs: All programs and program modules corresponding to processes are
defined through a structured chart. To define the processes performed by a program, the
analyst may include data-flow diagrams, flow-charts, and pseudocodes that were used to
describe the processes in the analysis phase.
• Programming Languages: Identifies the languages that will be used to code the systems.
• Database System: Identifies the database software that will be used in the system.
• Hardware Platform: Identifies the computer hardware that will be used in various parts of
the system.
67
• Operating Systems: Operating systems that will be used in various parts of the system.
• Network Architecture: Identifies the network architecture of the system.
The output of the design phase is a Functional Specification or Design Specification;

Programmers and network administrators use this document as the working specification for
the physical development of the system.
The goal of systems design is to build a system that satisfies business requirements. A
successful system must be effective, reliable, and maintainable:
• A system is effective if it supports business requirements and meets user needs.
• A system is reliable if it handles input errors, processing errors, hardware failures, or human
mistakes. A good design will anticipate errors, detect them as early as possible, make it easy
to correct them, and prevent them from damaging the system itself.
• A system is maintainable if it is flexible, scalable, and easily modified. Changes might be
needed to correct problems, adapt to user requirements, or take advantage of new technology.
Although each project is different, design considerations usually involve users, data, and
system architecture.
 USER CONSIDERATIONS: The most important goal is to make the system user
friendly. Here are some suggestions to keep in mind:
i. Carefully consider any point where users receive output or provide input- The user
interface must be easy to learn. Input processes should be easy to follow, intuitive, and
forgiving of errors. Output should be attractive and easy to understand, with an appropriate
level of detail.
ii. Anticipate future needs- Suppose that a parts inventory database contains a one character
field for category, such as electrical, mechanical, or hydraulic. The design works well, but
what if the company decides to break these overall groups down into more specific segments?
Why should there be a limitation of just one character? A better design would anticipate
possible expansion to two or more characters. For example, many people recall the concern
called the Y2K issue, when some older programs that used only two characters to store the
year might not adjust properly to the new century
iii. Provide flexibility- Suppose that a user wants a screen display of all customer balances
that exceed N5,000 in an accounts receivable system. How should you design that feature?
The program could be coded to check customer balances against a fixed value of 5000, which
is a simple solution for both the programmer and the user because no extra keystrokes are
required to produce the display.
68
However, that approach is inflexible. For instance, if a user later needs a list of customers
whose balances exceed N7,500 rather than N5,000, more programming would be needed. A
better approach might be to allow the user to enter the amount. For example, if a user wants
to display customers with balances of more than N7,500, he or she can enter that figure in a
parameter query. A parameter is a value that the user enters whenever the query is run,
which provides flexibility, enables users to access information easily, and costs less. A good
systems design can combine both approaches. For example, you could design the program to
accept a variable amount entered by the user, but start with a default value of 5000 that the
system displays automatically. Users can press the ENTER key to accept the default value, or
enter another value. Often the best design strategy is to come up with several alternatives, so
users can decide what will work best for them.
 DATA CONSIDERATIONS: Data entry and storage are important in every system.
Here are some suggestions to keep in mind:
i. Enter data as soon as possible- For example, employees in the receiving department
should enter data about incoming shipments when the shipments arrive, and sales clerks
should enter data about new orders when they take the orders.
ii. Verify data as it is entered- The input design should specify a data type, such as
alphabetic, numeric, or alphanumeric, and a range of acceptable values for each data item. If
an incorrect value is entered, the system should recognize and flag it immediately. The
system also should allow corrections at any time. Some errors, for example, can be easily
corrected while the original source documents are at hand or the customer is on the phone.
Other errors may need further investigation, so users must be able to correct errors at a later
time.
iii. Use automated methods of data entry whenever possible - For example, receiving
department employees can use scanners to capture data about merchandise received.
Automated data entry methods, such as the RFID scanner, can reduce input errors and
improve employee productivity.
iv. Control data entry access and report all entries or changes to critical values - Dollar
fields and volume fields are critical data fields. Examples of critical volumes might include
the number of checks processed, the number of medical prescriptions dispensed, or the
number of insurance premium payments received. Reports that trace the data entry and
changes to critical data values are called audit trails and are essential in every system.
69
v. Log every instance of data entry and changes. For example, the system should record
when a customer‘s credit limit was established, by whom, and any other information
necessary to construct the history of a transaction.
vi. Enter data once. If input data for a payroll system also is needed for a human resources
system, you should design a program interface between the systems so data can be transferred
automatically. For example, an employee‘s date of birth should be entered only once, but the
data should be accessible by multiple systems or authorized users.
vii. Avoid data duplication. In an inventory database, vendor addresses should not be stored
with every part record. Otherwise, the address of a vendor who supplies 100 different parts
will be repeated 100 times. Additionally, if the vendor‘s address changes, all 100 parts
records must be updated. Data duplication also can produce inconsistencies. If the 100 stored
addresses for the vendor are not identical, how would a user know which version is correct?
In unit 7, you will learn about data modelling and a technique called normalization, which is
a set of rules that can help you identify and avoid inconsistencies in data design tasks
ARCHITECTURE CONSIDERATIONS:
In addition to the issues affecting users and data, you should consider the overall architecture.
Here are some suggestions to keep in mind:
i. Use a modular design- In a modular design; you create individual components, called
modules, which connect to a higher-level program or process. In a structured design, each
module represents a specific process, which is shown on a DFD and documented in a process
description. If you are using an object-oriented design, object classes are represented by code
modules.
ii. Design modules that perform a single function- Independent module provides greater
flexibility because they can be developed and tested individually, and then combined or
reused later in the development process. Modular design is especially important in designing
large-scale systems, because separate teams of analysts and programmers can work on
different areas and then integrate the results..
SYSTEM IMPLEMENTATION
During implementation, the information system is coded, tested, installed and supported in
the organization. This phase can be divided into two parts: systems development and systems
installation.
70
Systems Development
In this phase, the system analyst works with the programmers to develop the new system
(software and hardware) according to the definition of the functional specification. The
analyst works as a facilitator to the programmers and other system architects to explain any
part of the design that may not be clear from the document.
Constructing the new system is the most time-consuming part of the development life cycle.
If the functional specification defines all processes clearly, then the programming becomes a
systematic activity. A poor functional specification may require a lot of interaction time
between the analyst and programmers.
The development phase also involves program testing and control. As each input form, report
or process is developed, it is tested and kept aside until the whole system is integrated and
tested again.
During this phase, the analyst also works with the users to develop effective documents for
software. These might include procedure manual, online help, frequently asked questions,
―readme‖ files, training guide, and so on.
Systems Installation
Once the system is developed, the analyst helps implement the new system. In this phase, the
analyst works with the users to describe the functionality of the new system. He or she also
trains the users for the new system.
It may take several versions to install the final system. Any change or improvement
originated due to user interaction or demonstration should be reflected in the next version,
until the users are satisfied with the system.
OPERATION AND SUPPORT

The system is systematically repaired and improved. Once a system is delivered, the role of
the system analyst changes from development to support.
Maintenance is the correction of errors and omissions that were not caught during the testing
and delivery phases. Improvements are the additions of new capabilities to the system.
Maintenance and improvement may arise due to the following reasons:
• Additional features: Request for additional features such as new reports and interfaces,
improved screen or report layouts, and so on.
• Change of business over time: Software must be modified to encompass changes as new
government rules need to be implemented.
71
• Hardware and software change: A system that uses older technology may be modified to
use the capabilities of newer technology.

o ------------------- is referred to as the process of defining the software architecture,
components, modules, interfaces, and data for a software system to satisfy
requirements specified during systems analysis.
 Information systems design
Now that you are able to describe system development life cycle (SDLC), let us learn
Approaches to System Analysis and Design
4.4 Approaches to System Analysis and Design

In this sub-session, you will learn numerous approaches to system analysis and design. Please
pay close attention to any acronyms used in the session.
Structured System Analysis and Design Method
Structured Systems Analysis & Design Method (SSADM) is a widely-used computer
application development method in the UK, where its use is often specified as a requirement
for government computing projects. It is increasingly being adopted by the public sector in
Europe. SSADM is in the public domain, and is formally specified in British Standard
BS7738.
SSADM divides an application development project into modules, stages, steps, and tasks,
and provides a framework for describing projects in a fashion suited to managing the project.
SSADM covers those aspects of the life-cycle of a system from the feasibility study stage to
the production of a physical design; it is generally used in conjunction with other methods
which are concerned with the broader aspects of project management.
In detail, SSADM sets out a cascade or waterfall view of systems development, in which
there are a series of steps, each of which leads to the next step. (This might be contrasted with
the rapid application development methodology - RAD, which pre-supposes a need to
conduct steps in parallel.). SSADM's steps, or stages, are:
 Feasibility
 Investigation of the current environment
 Business systems options
 Definition of requirements
72
 Technical system options
 Logical design
 Physical design
For each stage, SSADM sets out a series of techniques and procedures, and conventions for
recording and communicating information pertaining to these- both in textual and
diagrammatic form. SSADM is a very comprehensive model, and a characteristic of the
method is that projects may use only those elements of SSADM appropriate to the project.
SSADM is supported by a number of CASE tool providers.
A physical model is often used in surveying the current system and designing the new system
while a logical model is used in analyzing system‘s requirements. This is a significant
advantage brought about by the Structural system analysis method.
Structural analysis together with prototype method gives ideas of the new system and helps
make best use of both methods.
Structured analysis is a set of techniques and graphical tools used by the analyst for applying
a systematic approach to systems analysis. The traditional approach for system analysis
focuses on cost/benefit and feasibility analyses, project management, hardware and software
selection, and personnel considerations. In contrast, structured analysis uses graphical tools
such as Data Flow diagram, data dictionary, structured English, Decision tree, and decision
tables. The outcome of structured analysis is a new document, called system specifications,
which provides the basis for design and implementation.
The primary steps included in structured analysis are:

1. Study affected user areas, resulting in a physical DFD. The logical equivalent of the
present system results in a logical DFD.
2. Remove the physical checkpoints and replace them with a logical equivalent, resulting in
the logical DFD.
3. Model new logical system
4. Establish man/machine interface
5. Quantify costs and benefits and select hardware.
The structured specification consists of the DFDs that show the major decomposition of
system functions and their interfaces, the data dictionary documenting all interface flows and
data stores on the DFDs, and documentation of the intervals of DFDs through structured
English, decision trees, and decision tables.
73
Structured design is a data flow methodology. The graphical representation of data flow,
communication & defining the modules & their relationship with each is known as Structure
Chart. This method decomposes & modularizes the system so that the complexity &
manageability will come down. Thus reducing the intuitive reasoning & promotes the
maintainable provable systems.
On the other hand SSADM puts special emphasis on the analysis of the system and its
documentation. This causes the danger of over-analyzing, which can be very time and cost
consuming. Due to various types of description methods, checks of consistence cannot be
carried out. Especially with large systems, the outline diagram can become very unclear,
because all relevant data flows have to be included.
The objectives of Structured System Analysis and Design Methods are to:
 Improve project management & control
 Make more effective use of experienced and inexperienced development staff
 Develop better quality systems
 Make projects resilient to the loss of staff
 Enable projects to be supported by computer-based tools such as computer-aided
software engineering Systems
 Establish a framework for good communications between participants in a project
Complete System Analysis and Design

Complete Systems Analysis integrates the event-response model of the processes with the
entity-relationship model of the stored data, and makes the data dictionary and mini
specifications support both. This integrated requirements specification is demonstrably
complete: Complete Systems Analysis cross checks the models to ensure that no part of the
system is overlooked. The integrated models have their inbuilt rules of correctness.
It uses a comprehensive modelling approach to build a specification containing all the
requirements. It uses events to partition the system, and integrates the event-response process
with the essential data for the event. The modelling technique used here is the event-response
based modelling.
74
The use of object-oriented languages means that the systems analysis method must place an
equal emphasis on the data, and the processes using that data. Complete Systems Analysis
delivers a specification that readily translates to the correct classes. Unimportant information
gets filtered and only significant aspects of the system get modelled.

o Structure is NOT the graphical representation of data flow, communication and
defining the modules and their relationship with each Chart. TRUE/FALSE
 FALSE
4.5 The Need for SDLC Models

It is important to share with all members involved the reasons behind the introduction of a
system development life cycle model. It is not unusual for team members to realise that a
system development life cycle is in place at a system development project they have just
joined. It is critical to ensure that the decision for the specific SDLC model is justified and
the requirements for its use are well clarified.
The following are some of the major factors that necessitate the use of SDLC in system
development:
i. Requirements for goal setting: System development projects differ according to their
scope. Some projects are necessary for the creation of new systems, while others are triggered
by the need for updates and redevelopment of existing, legacy systems. The model used must
be suitable for the type of activities associated with the scope of the development project.
ii. Requirements for skills: Determining each system requires certain skills for the
development of its components. There are several activities and tasks associated with system
development ranging from specification to testing and installation and maintenance. Each
activity and task requires certain skills and the proper development cycle should allow the
identification and alignment of these skills.
iii. Requirements for project managing: The existence of the system life cycle phases allows
the manager of a system development team to allocate roles and assign tasks accordingly; this
ensures that the entire project is managed well. It is quite often to witness more complicated
models of task coordination where individual members may be brought together for handling
tasks such as risk management, cost-benefit analysis, planning, status assessment, etc.
iv. Requirements for Assessing Usability: The success of any software system depends on
how useful is for its intended users. It is therefore imperative to assess any usability needs
75
form various stakeholders, at different stages when developing and deploying a software
system.
v. Requirements for Support Planning: The support provided after the deployment and
installation of any system is critical for ensuring its use for a long period of time. Such
support must be organized according to the different development stages, as support needs
may differ. For instance, the training and step-by-step guidance offered is important for end
users, while requirements for bug fixing and additional functionality is likely to be discussed
with more advanced stakeholder groups.

o List the major factors that necessitate the use of SDLC in system development
 i. Requirements for goal setting

ii. Requirements for skills
iii. Requirements for project managing
iv. Requirements for Assessing Usability
v. Requirements for Support Planning:
In the next study session, you will learn requirement analysis, in which the system analyst
determines the functional and non-functional needs for the new system throughout the
development process.
Activity 4.1 The need for SDLC Models

and knowing that it is critical to convey the rationale for the installation of an SDLC model
with all individuals involved. It is also vital to ensure that the choice of SDLC model is
justified and that the requirements for its use are adequately clarified, note down the meaning
of SDLC, and some of the major factors that necessitate the use of SDLC in system
development?

SDLC means System Development Life Cycle. Some of the factors influence SDLC
introduction are Requirements for goal setting, Requirements for skills, Requirements for
project managing, Requirements for Assessing Usability and Requirements for Support
Planning
76
Take a look at sub-session 4.3; it describes the factors
For us to meaningfully learn about system analysis development there is a need to understand
system development life cycle and factor influences its installation. In other words the
meaning of a system development life cycle and factor influences its introduction are
explained in Box 4.1
Box 4.1: Meaning of Systems development Life cycle

System development Life Cycle is the overall process of developing, implementing,
and retiring information systems through a series of multistep process. It is important
to note:
 The system development life cycle does not exist by itself; it is in fact part of
an overall product lifecycle
 SDLC consists of five phases which are;
i Systems planning
ii. Systems analysis
iii Systems design
iv Systems implementation
v Systems operation and support
 Factor affecting SDLC model introduction includes Requirements for goal

setting, Requirements for skills, Requirements for project managing,
Requirements for Assessing Usability and Requirements for Support Planning
Also, note that the term SDLC refers to as system development life cycle, and .
Systems design phase can be broken into two phases: logical design and physical
design.
 Logical Design: in this phase, all functional features of the system chosen for
development in analysis are described independently of any computer platform.
In this phase, the system analyst uses the information collected earlier to
develop a logical design of the information system.
 Physical Design phase the logical specifications of the system from logical
design are transformed into the technology-specific details from which all
programming and system construction can be accomplished. This phase
identifies the file and database structures, system structure, program structure,
and hardware and software necessary to implement the system.
77
 System development life cycle (SDLC) is the series of steps used to mark the phases
of development of an information system.
 SDLC is the process by which systems analysts, software engineers, and programmers
build systems.
 System development life cycle consists of five phases: these are
i Systems planning
ii Systems analysis
iii Systems design,
iv Systems implementation and
v Systems operation and support.
 Factor affecting SDLC model introduction includes
i. Requirements for goal setting
ii Requirements for skills,
iii Requirements for project managing,
iv Requirements for Assessing
v Usability and Requirements for Support Planning


Can you explain the system development life cycle?
Can you state the five phases of SDLC?
Can you explain the two phases of system design?
Can you highlight the objectives of structured system analysis and design method?
Can you mention factors that necessitate the use of system development life cycle when
developing information system?
78
SAQ 4.1: System Development Life Cycle is the overall process of developing,
implementing, and retiring information systems through a series of multistep process.
SAQ 4.2: The five phases of System Development Life Cycle (SDLC) are;
i Systems planning
ii. Systems analysis
iii Systems design
iv Systems implementation
v Systems operation and support
SAQ 4.3: The two systems design phases are: Logical design and Physical design.
i. Logical Design: in this phase, all functional features of the system chosen for development
in analysis are described independently of any computer platform. In this phase, the system
analyst uses the information collected earlier to develop a logical design of the information
system.
ii. Physical Design phase the logical specifications of the system from logical design are
transformed into the technology-specific details from which all programming and system
construction can be accomplished. This phase identifies the file and database structures,
system structure, program structure, and hardware and software necessary to implement the
system.
SAQ 4.4: The objectives of Structured System Analysis and Design Methods are to:
i) Improve project management & control
ii) Make more effective use of experienced and inexperienced development staff
iii) Develop better quality systems
iv) Make projects resilient to the loss of staff
v) Enable projects to be supported by computer-based tools such as computer-aided
software engineering Systems
vi) Establish a framework for good communications between participants in a project
SAQ 4.5: Factors that necessitate the use of system development life cycle when developing
information system includes: i. Requirements for goal setting, ii. Requirements for skills, iii
Requirements for project managing, iv Requirements for Assessing Usability and v
Requirements for Support Planning
79
References
Alan, D., Barbara H. W., and Roberta M. R. (2012): Systems analysis and design (5th
edition), John Wiley & Sons, Inc.
Dr. Kevin P. Duffy, (2011): Structured Systems Analysis and Design. Sogeti University
Gary B. S., and Harry J. Rosenblatt (2012): Systems Analysis and Design (9th edition): Shelly
Cashman Series: Thomson Course Technology. USA.
Hyalij B., and Gondane P. S. (2010): System Analysis and Design Flexibility in the Approach
Based on the Product Definition. Maharashtra Institute of Technology Pune, India:
International Journal of Computer Applications (2010). Vol1-No.20
Learning without boundaries(2012): Module- Systems Analysis and Design: Resource

Development International Ltd.
80
Study Session 5: Requirement Analysis
Introduction
In the last study session, you learned about the system analysis phase, and you know that the
system analyst determines the functional and non-functional requirements for the new
system. In this study session, you will be able to learn in depth about the system development
analysis phase, the concept of a requirement analysis, its purpose, and the structure of the
requirements. In addition, techniques for eliciting requirements, including interviews, JAD
sessions, questionnaires, document analysis, and observation, are described. Finally,
numerous requirements analysis strategies are also described to assist the analyst in
identifying requirements.
5.1 Explain the term analysis phase of a system development (SAQ 5.1)
5.2 Define requirement (SAQs 5.2)
5.3 Enumerate the techniques that can be used to acquire information for a system (SAQ 5.3)
5.4 State the two group of requirement (SAQ 5.4)
5.5 List the three types of interview questions you know (SAQ 5.5)
5.6 State five criteria to consider for requirement gathering techniques (SAQ 5.6).
5.1 The Analysis Phase

The term analysis refers to breaking a whole into its parts with the intent of understanding the
parts‘ nature, function, and interrelationships. In the context of the SDLC, the outputs of the
planning phase (the system request, feasibility study, and project plan), outline the business
goals for the new system, define the project‘s scope, assess project feasibility, and provide
the initial work plan. These planning phase deliverables are the key inputs into the analysis
phase. In the analysis phase, the systems analyst works extensively with the business users of
the new system to understand their needs from the new/proposed system.
The basic process of analysis involves three steps:
81
 Understand the existing system (the as-is system).
 Identify improvements.
 Define requirements for the new system (the to-be system).
Sometimes the first step (i.e., understanding the as-is system) is skipped or not carried out
extensively. This happens when no current system exists, if the existing system and processes
are irrelevant to the future system, or if the project team is using a RAD or agile development
methodology in which the as-is system is not emphasized. Traditional methods such as
waterfall and parallel development (see Unit 3) typically allocate significant amount of time
to understanding the current system and identifying improvements before moving to capture
requirements for the proposed system. Newer RAD and agile methodologies, such as iterative
development and prototyping (see Unit 3), focus more exclusively on improvements and the
proposed system requirements, and they devote little time for investigating the current
system. However, it is useful to study the current situation whenever possible because the
insights gained from reviewing the existing system can be quite valuable to the project team.
A systems analyst needs strong critical thinking skills which is the ability to recognize
strengths and weaknesses and recast an idea in an improved form. These skills are needed in
order for the analyst to understand issues and develop new and improved business processes
that are supported by information system technologies. These skills are essential in
examining the results of requirements discovery and translating those requirements into a
concept for the new system.
As an example, let‘s say that a user states that the new system should ―eliminate inventory
stock-outs.‖ While this might be a worthy project goal, the analyst needs to think about it
critically in order to formulate the statement in terms of useful requirements. The analyst
could first have the users think about circumstances leading to stock-outs (e.g., supplier
orders are not placed in a timely way), and then describe the issues that lead to these
circumstances (e.g., on-hand inventory levels are updated only once a week; delays occur in
identifying the best supply source for the items; delays occur in receiving approval of the
supply order, etc.). By focusing on these issues, the team is in a better position to develop
new business processes that address these concerns. The new requirements will then be based
on the issues that truly need to be fixed. In this case, the requirements might include, in part:
 The system shall update on-hand inventory levels twice per day.
 The system shall produce an out-of-stock notification immediately when an item
quantity on hand reaches the item reorder point.
82
 The system shall include a recommended supplier with every out-of-stock
notification.
 The system shall produce a supply purchase order that is sent to the appropriate
manager for approval.
 The system shall send an approved supply purchase order to the supplier via secure
electronic communication channel.
As this example illustrates, the analyst cannot realistically expect that the true requirements
for the new system are easily gathered following a few conversations with the stakeholders.
The analyst must be prepared to dig into the situation and discover requirements. This is not
often an easy process; this is where critical thinking is required.
A number of techniques and tools can be used by the analyst to facilitate this process of
gathering requirements. In this unit, we will describe those techniques and tools so that you
can learn how to use them during the analysis phase. We will also explain the essential role
that requirements play in defining the new system.
As mentioned above, the analyst also employs tools during this phase that are the subject of
complete chapters: use cases, process models (unit 6), and data models (unit 7).
The final deliverable of the analysis phase is the system proposal, which compiles the
detailed requirements definition statement, use cases, process models, and data model
together with a revised feasibility analysis and work plan. At the conclusion of the analysis
phase, the system proposal is presented to the approval committee, usually in the form of a
system walk-through. The goal of the walk-through is to explain the system in moderate
detail so that all the stakeholders (the users, managers, and key decision makers) clearly
understand it, can identify any needed modifications, and are able to make a decision about
whether the project should continue.
If approved, the system proposal components (requirements definition, use cases, process
models, and data model) are used as inputs to the steps in the design phase, which further
refine them and define in much more detail how the system will be built.
Many of the major design decisions for the new system are found in the analysis deliverables.
Therefore, it is important to remember that the deliverables from the analysis phase are really
the first step in the design of the new system.
83
To be candid, determining requirements is the single most critical aspect of the entire SDLC
because a system that does not provide the function(s) expected of it by its users would be
regarded as a failed system. Although many factors contribute to the failure of systems
development projects, failing to determine the correct requirements is a primary cause.
A 2008 study of Fortune 500 company software projects found just 37% of survey
respondents felt the project met users‘ needs. Therefore, analysts should devote considerable
attention to the activities carried out in the analysis phase. It is here that the major elements of
the system first begin to emerge. If the requirements are later found to be incorrect or
incomplete, significant rework may be needed, adding substantial time and cost to the project.
During requirements determination, the proposed system concept could still be easily altered
because substantial phases of the system development have not been done yet. As the system
moves through the subsequent SDLC phases (design and implementation), it becomes more
difficult to backtrack to requirements determination and make major changes because of all
of the rework that is involved. This is why the iterative approaches of many RAD and agile
methodologies are so effective, where small batches of requirements can be identified and
implemented in incremental stages, allowing the overall system to change and evolve over
time. Also, methodologies such as the V-model stress that tests for the system should be
defined at the same time that the requirements are being defined. That way, testing is not just
a last-minute, thrown-together process, but instead is based directly on the requirements of
the system as they are being defined.

o ------------ compiles the detailed requirements definition statement, use cases, process
models, and data model together with a revised feasibility analysis and work plan.
 System proposal
Now that you are able to have a good understanding of analysis, let us learn its requirement
determination.
5.2 Requirements Determination

Requirements determination is performed to transform the system request‘s high-level
statement of business requirements into a more detailed, precise list of what the new system
must do to provide the needed value to the business. This detailed list of requirements is
84
supported, confirmed, and clarified by the other activities of the analysis phase: creating use
cases, building process models, and building a data model. We first explain what a
requirement is and discuss the process of creating a requirements definition statement.
What Is a Requirement?
A requirement is simply a statement of what the system must do or what characteristics it
needs to have. During a systems development project, requirements will be created that
describe what the business needs (business requirements); what the users need to do (user
requirements); what the software should do (functional requirements); characteristics the
system should have (non-functional requirements); and how the system should be built
(system requirements). These categories of requirements reflect the purpose of the
requirements and the stage in the SDLC in which they are defined.
We have already discussed the creation of the systems request in the planning Phase (see Unit
4) of the SDLC. In the system request, there are statements that describe the reasons for
proposing the systems development project. These statements reflect the business
requirements that this system, will fulfil if built. These business requirements help define the
overall goals of the system and help clarify the contributions it will make to the
organization‘s success.
Examples of business requirements include: ―Increase market share‖; ―Shorten order
processing time‖; ―Reduce customer service costs‖; ―Lower inventory spoilage‖; ―Improve
responsiveness to customer service requests‖; and ―Provide account access to mobile
customers.‖
When the systems development project is complete, success will be measured by evaluating
whether the stated business requirements have actually been achieved; therefore, they provide
the overall direction for the project.
During the analysis phase, requirements are written from the perspective of the business, and
they focus on what the system needs to do in order to satisfy business user needs. A good
starting place is to concentrate on what the user actually needs to accomplish with the system
in order to fulfil a needed job or task. These user requirements describe tasks that the users
perform as an integral part of the business‘ operations, such as: ―Schedule a client
appointment‖; ―Place a new customer order‖; ―Re-order inventory‖; ―Determine available
credit‖; and ―Look up account balances.‖ Use cases (discussed in Unit 6) are tools used to
clarify the steps involved in performing these user tasks. By understanding what the user
85
needs to do in terms of tasks to perform, the analyst can then determine ways in which the
new system can support the users‘ needs.
Determining ways in which the new system can support user needs leads to statements of the
system‘s functional requirements. A functional requirement relates directly to a process the
system has to perform as a part of supporting a user task and/or information it needs to
provide as the user is performing a task. The International Institute of Business Analysis
(IIBA) defines functional requirements as ―the product capabilities, or things that a product
must do for its users.‖ Functional requirements begin to define how the system will support
the user in completing a task.
For example, assume the user requirement is ―Schedule a client appointment.‖ The functional
requirements associated with that task include:
i. Determine client availability
ii. Find available openings matching client availability
iii. Select desired appointment
iv. Record appointment, and
v. Confirm appointment.
Notice how these functional requirements expand upon the user‘s task to describe capabilities
and functions that the system will need to include, allowing the user to complete the task.
As the analyst works with the business users of the system to discover user and functional
requirements, the user may reveal processes that will be needed or information that will be
needed. For example, as shown in Table 5.1, the user may state ―The system must retain
customer order history for three years‖ (an information need). The analyst should probe for
the reasoning behind this statement, such as ―The system should allow registered customers
to review their own order history for the past three years‖ (a process need). Similarly, the user
may state ―The system should check incoming customer orders for inventory availability‖ (a
process need).
An alert analyst will recognize the related information need, ―The system should maintain
real-time inventory levels at all warehouses.‖ All of these requirements are necessary to fully
understand the system that is being developed.
Process models (Unit 6) are used to explain the relationship of functions/ processes to the
system users, how the functions/processes relate to each other, how data is entered and
produced by functions/processes, and how functions/processes create and use stored data.
Process models help clarify the software components that will be needed to accomplish the
functional requirements.
86
FUNCTIONAL
REQUIREMENT DESCRIPTION EXAMPLES
Process-Oriented A process the system i. The system must
must perform; a process allow registered
the system must do. customers to review
their own order
history for the past
three years.
ii. The system must
check incoming
customer orders for
inventory availability.
iii. The system should

allow students to
view a course
schedule while
registering for
Information-Oriented Information the system classes.
must contain.
i. The system must

retain customer order
history for three
years.
ii. The system must
include real-time
inventory levels at all
warehouses.
iii. The must include
budgeted and actual
sales and expense
amount for current
year and three
87
previous years
Table 5.1: Functional Requirements
User requirements and functional requirements defined in the analysis phase will flow into
the design phase, where they evolve to become more technical, describing how the system
will be implemented. Requirements in the design phase reflect the developer‘s perspective,
and they usually are called system requirements. These requirements focus on describing how
to create the software product that will be produced from the project.
It is important to note that a requirement is a statement of what the system must do, and the
focus of requirements will change over time as the project moves from planning to analysis to
design to implementation. Requirements evolve from broad statements of overall business
needs from the system to detailed statements of the business capabilities that a system should
support to detailed technical statements of the way in which the capabilities will be
implemented in the new system.
The final category of requirements is non-functional requirements. The IIBA defines this
group of requirements as ―the quality attributes, design, and implementation constraints, and
external interfaces which a product must have.‖
Non-functional requirement describes a variety of system characteristics which are expected
as important behavioural properties that the system must have, such characteristics include
performance, security, operational, political, cultural, and usability features etc. For instance,
the ability to access the system through a mobile device would be considered a non-
functional requirement. Non-functional requirements are primarily used in the design phase
when decisions are made about the user interface, the hardware and software, and the
system‘s underlying architecture. Many of these requirements will be discovered during
conversations with users in the analysis phase. These characteristics do not describe business
processes or information, but they are very important in understanding what the final system
should be like. For example, the project team needs to know whether a system must be highly
secure, requires short response time, or has to reach a multilingual customer base etc. These
requirements will affect design decisions that will be made in the design phase, particularly
architecture design,
88
Table 5.2 lists different kinds of non-functional requirements and examples of each kind.
Non-Functional Description Examples

Requirements
Operational The physical and technical a. The system can run on
environment in which the handheld devices.
system will operate. b. The system should be able to
integrate with the existing
inventory system.
c. The system should be able to
work on any web browser.
Performance The speed, capacity and a. The interaction between the
reliability of the system. user and system should not exceed
2 seconds.
b. The system downloads new
status parameters within 5 minutes
of a change.
c. The system should be available
for use 24 hours per day.
Security Who has authorized access a. Only direct managers can see
to the system under what personnel records of staff.
circumstance? b. Customers can see their order
history only during business
hours.
c. The system includes all
available, updated safe guards
from viruses, Trojan horses,
worms etc
Cultural and Political Cultural and political a. The system should be able to
factors and legal distinguish between the Nigeria
requirements that affect the currency (Naira) and currencies of
system. other nations.
b. Company policy is to buy
89
computers only from Toshiba.
c. Personal information is
protected in compliance with the
Data Protection Act.
Table 5.2: Non-Functional Requirements

o Increasing market share, shortening order processing time, reducing customer service
costs, lowering inventory spoilage, improving responsiveness to customer service
requests, and providing account access to mobile customers are examples of business
requirements. True/False
 True
Now that you are able to have a good understanding of requirement determination, let us
learn the process of a requirement gathering.
5.3 The Process of Requirements Gathering

Both business and IT perspectives are needed to determine requirements during the analysis
phase. Systems analysts may not understand the true business needs of the users. According
to study by the Standish Group, the lack of user involvement is the top reason for IT project
failure. On the other hand, the business users may not be aware of the opportunities that a
new technology may offer. It is important that the team carefully considers the underlying
business process and how best to support that business process with information system
technology.
A good analogy is building a house or an apartment. We have all lived in a house or
apartment, and most of us have some understanding of what we would like in our homes. If
we were asked to design a dwelling from scratch, however, it would be a challenge because
we lack appropriate design skills and technical engineering skills. Likewise, an architect
acting alone would probably miss some of our unique tastes (requirements). Therefore, the
most effective approach is to have both business people and system analysts working together
to determine requirements. The analysis phase involves significant interactions with people
who have an interest in the new system (often called stakeholders). One of the first tasks for
the analyst is to identify the primary sources of requirements, including the project sponsor,
all users of the system (both direct and indirect), and possibly others.
90
Elicitation refers to gathering the requirements of the system from different stakeholders.
Boundaries, identification of stakeholders, goals and tasks performed are discovered in this
phase. There are various techniques for requirement elicitation that can be used to acquire
information for a system, they are broadly categorised as traditional and modern methods.
The traditional methods of requirement gathering are:
 Interviews
 Questionnaires
 Observation
 Document Analysis
While the modern methods include:
 Joint Application Development (JAD)
 Prototyping
Even though we called interviews, questionnaires, observation, and document analysis

traditional methods for determining a system‘s requirements, they are all still used by
analysts to collect important information today, however, the modern methods can support
effective collection and structuring while reducing the amount of time required for analysis.
The information gathered by these techniques is critically analyzed and used to craft the
requirements definition statement. The analyst works with the entire project team and the
business users to verify, change, and complete the list of requirements and, if necessary, to
prioritize the importance of the requirements that are identified. During this process, use
cases, process models, and data models may be used to clarify and define the ideas for the
new system. This process continues throughout the analysis phase, and the requirements
definition evolves over time as new requirements are identified and as the project moves into
later phases of the SDLC.
When a requirement reflects an important business need, but is not within the scope of the
current system or current release, it should be evaluated in terms of its importance and impact
on time and budget. It may be that the requirement is essential enough to add to the current
project, along with appropriate adjustments to the project scope, budget, and time frame. We
should not assume that the requirements for the project can never be changed. However, it is
also possible that the requirement might be added to a list of future requirements or given a
low priority. The management of requirements (and system scope) is one of the hardest parts
of managing a project!
91
o The modern methods of requirement gathering are --------- and --------
 Joint Application Development (JAD) and Prototyping
Now that you are able to explain the process of a requirement gathering, let us learn the
Requirements Definition Statement
5.4 The Requirements Definition Statement

The requirements definition statement—usually just called the requirements definition—is a
straightforward text report that simply lists the functional and non-functional requirements in
an outline format. Figure 5.1 shows a sample requirements definition for Holiday Travel
Vehicles, a fictitious recreational vehicle dealership.
Functional Requirements
1. New Vehicle Management
1.1 The system will allow managers to view the current new vehicle
inventory.
1.2 The system will allow the new vehicle manager to place orders for
new vehicles.
1.3 The system will record the addition of new vehicles to inventory
when they are received from the manufacturers.
2. Vehicle Sales Management

2.1 The system will enable salespersons to create a customer offer.
2.2 The system will allow sale people to know whether an offer is
pending on a specific vehicle.
2.3 The system will enable managers to record approval of a customer
offer.
2.4 The system will record a customer deposit.
Non-Functional Requirements
2.5 The system will record a customer payment.
1.Operational
3. Used Vehicle Management
1.1 The system should be run on table PCs to be used by salespeople.
3.1 The system will record information on a customer trade-in vehicle .
1.2 The system
etc. should interface with the shop management system.
1.3 The system should connect to printers wirelessly.
2. Performance
2.1 The system should support a sales staff of 20 salespeople
2.2 The system should be updated with pending offers on vehicles every 30
minutes.
3. Security
3.1 No salesperson can access any other salesperson‘s customer contacts.
3.2 Only the owner and sales manager may approve customers offers.
4.Figure
Cultural andSample
5.1: PoliticalRequirements Definition Statement
4.1 Company policy says that all computer equipment is purchased from
Toshiba. 92
4.2 Customer personal information is protected in compliance with the Data
Protection Act.
As shown in figure 5.1, it is common to number the requirements in a legal or outline format
so that each requirement is clearly identified. It is important that the requirements be
identified with unique numbers so that each requirement can be easily tracked through the
entire development process. For clarity, the requirements are typically grouped into
functional and non-functional groupings. Then, within each of those groups, they are
classified further by the type of requirement or by business area.
Sometimes, requirements are prioritized on the requirements definition statement. They can
be ranked as having ―high,‖ ―medium,‖ or ―low‖ importance in the new system, or they can
be labelled with the version of the system that will address the requirement (e.g., release 1,
release 2, release 3, etc). This practice is particularly important with RAD methodologies that
deliver requirements in batches by developing incremental versions of the system.
The most obvious purpose of the requirements definition is to provide a clear statement of
what the new system should do in order to achieve the system vision described in the system
request. The use cases, process models, and data models provide additional explanatory
content in different formats. A critically important purpose of the requirements definition,
however, is to define the scope of the system.
The document describes to the analysts exactly what the final system needs to do. In addition,
it serves to establish the users‘ expectations for the system. If and when discrepancies or
misunderstandings arise, the document serves as a resource for clarification.

o The requirements definition statement is also known as -----------
 The requirements definition
Now that you are able to explain the process of a requirement gathering, let us learn the
Requirements Gathering Techniques.
5.5 Requirements Gathering Techniques

The best analysts will thoroughly search for requirements using a variety of techniques and
make sure that the current business processes and the needs for the new system are well
understood before moving into design. Also, there is need for careful consideration of the key
stakeholders to be included in process and every opportunity for contact and interaction
between the systems analyst and these stakeholders should be used to boost their interest and
commitment to the system project; one important way to achieve these as an analyst is to be
93
well prepared for the requirement gathering process and make adequate use of all the types of
requirements gathering techniques.
5.5.1 Interviews
This is the most commonly used technique for gathering requirement. Generally, interviews
are conducted one on one (one interviewer and one interviewee), but sometimes, due to time
constraints, several people are interviewed at the same time. There are five basic steps to the
interview process:
 Selecting Interviewees
 Designing Interview questions
 Preparing for the Interview
 Conducting the Interview and
 Post-Interview Follow-up.
Selecting Interviewees: An interview schedule should be created, listing who will be

interviewed, the purpose of the interview, and where and when it will take place.
The schedule can be an informal list that is used to help set up meeting times or a formal list
that is incorporated into the work plan. The people who appear on the interview schedule are
selected on the basis of the analyst‘s information needs. The project sponsor, key business
users, and other members of the project team can help the analyst determine who in the
organization can best provide important information about requirements. These people are
listed on the interview schedule in the order in which they should be interviewed.
People at different levels of the organization will have different viewpoints on the system, so
it is important to include both managers who manage the processes and staff who actually
perform the processes to gain both high-level and low-level perspectives on an issue. Also,
the kinds of interview subjects that you need may change over time. For example, at the start
of the project the analyst has a limited understanding of the current business process. It is
common to begin by interviewing one or two senior managers to get a strategic view and then
move to mid-level managers who can provide broad, overarching information about the
business process and the expected role of the system being developed. Once the analyst has a
good understanding of the big picture, lower-level managers and staff members can fill in the
exact details of how the process works. Like most other things about systems analysis, this is
an iterative process—starting with senior managers, moving to midlevel managers, then staff
94
members, back to mid-level managers, and so on, depending upon what information is
needed along the way.
Designing Interview Questions: There are three types of interview questions: closed-ended
questions, open-ended questions, and probing questions.
Closed-ended questions require a specific answer. It is similar to multiple choice or

arithmetic questions in an exam. They are used when the analyst is looking for specific,
precise information (e.g., how many credit card requests are received per day?). In general,
precise questions are best. (See table 5.3 for examples). For example, rather than asking ―Do
you handle a lot of requests?‖
It is better to ask ―How many requests do you process per day?‖
Closed-ended questions enable analysts to control the interview and obtain the information
they need. However, these types of questions don‘t uncover why the answer is the way it is,
nor do they uncover information that the interviewer does not think to ask ahead of time.
Open-ended questions are those that leave room for elaboration on the part of the
interviewee. They are similar in many ways to essay questions that you might find in an
exam. (See table 5.3 for examples.) Open-ended questions are designed to gather rich
information and give the interviewee more control over the information that is revealed
during the interview. Sometimes the subjects the interviewee chooses to discuss uncover
information that is just as important as the answer (e.g., if the interviewee talks only about
other departments when asked for problems, it may suggest that he or she is reluctant to
admit his or her own department‘s problems).
The third type of question is the probing question. Probing questions follow-up on what has
just been discussed in order for the interviewer to learn more, and they often are used when
the interviewer is unclear about an interviewee‘s answer.
They encourage the interviewee to expand on or to confirm information from a previous
response, and they are a signal that the interviewer is listening and interested in the topic
under discussion. Many beginning analysts are reluctant to use probing questions because
they are afraid that the interviewee might be offended at being challenged or because they
believe it shows that they didn‘t understand what the interviewee said. When done politely,
probing questions can be a powerful tool in requirements discovery.
In general, you should not ask questions about information that is readily available from other
sources. For example, rather than asking what information is used to perform to a task, it is
95
simpler to show the interviewee a form or report and ask what information on it is used. This
helps focus the interviewee on the task and saves time, because he or she does not need to
describe the information in detail.
Your interview questions should anticipate the type of information the interviewee is likely to
know. Managers are often somewhat removed from the details of daily business processes
and so might be unable to answer questions about them, whereas lower-level staff members
could readily respond. Conversely, lower-level employees may not be able to answer broad,
policy-oriented questions, while managers could. Since no one wants to appear ignorant,
avoid confounding your interviewees with questions outside their areas of knowledge.
TYPES OF QUESTIONS EXAMPLES
Closed-Ended Questions How many customers‘ orders are

received per day?
Which language preference is mostly
used by customers?
What package do subscribers most often
Open-Ended Questions
have issue with?
What do you think often cause the

Probing Questions frequent drop calls?
What are some of the reactions you
receive from the subscribers after
attending to their customer care
requests?
Why?
Can you cite an example?
Can you explain that point in more
detail?
Table 5.3: Types of Questions
96
No type of question is better than another, and usually a combination of questions is used
during an interview. At the initial stage of an Information System development project the
current process can be unclear, so the interview process begins with unstructured interviews,
interviews that seek a broad and roughly defined set of information. In this case, the
interviewer has a general sense of the information needed, but few closed-ended questions to
ask. These are the most challenging interviews to conduct because they require the
interviewer to ask open-ended questions and probe for important information right from the
onset.
As the project progresses, the analyst comes to understand the business process much better,
and he or she needs very specific information about how business processes are performed .
At this time, the analyst conducts structured interviews in which specific sets of questions are
developed prior to the interviews. There usually are more closed-ended questions in a
structured interview than in the unstructured approach.
No matter what kind of interview is being conducted, interview questions must be organized
into a logical sequence so that the interview flows well.
There are two fundamental approaches to organizing the interview questions: top-down or
bottom-up; as depicted in figure 5.2. With the top-down interview, the interviewer starts with
broad, general issues and gradually works towards more specific ones. With the bottom-up
interview, the interviewer starts with very specific questions and moves to broad questions. In
practice, analysts mix the two approaches, starting with broad general issues, moving to
specific questions, and then back to general issues.
The top-down approach is an appropriate strategy for most interviews and it is certainly the
most common approach. The top-down approach enables the interviewee to become
accustomed to the topic before he or she needs to provide specifics. It also enables the
interviewer to understand the issues before moving to the details, because the interviewer
may not have sufficient information at the start of the interview to ask very specific
questions. Perhaps most importantly, the top-down approach enables the interviewee to raise
a set of big-picture issues before becoming enmeshed in details, so the interviewer is less
likely to miss important issues.
97
One case in which the bottom-up strategy may be preferred is when the analyst already has
gathered a lot of information about issues and just needs to fill in some holes with details. Or,
bottom-up may be appropriate if lower-level staff members feel threatened or are unable to
answer high-level questions. For example, ―How can we improve customer service?‖ may be
too broad a question for a customer service clerk, whereas a specific question is readily
answerable (e.g., ―How can we speed up customer returns?‖).
Top-Down
How can order processing be improved?

High-level: very general
Medium-level:
How can we reduce the number of times that
moderately specific customers return items they‘ve ordered?
Low-level: very specific Bottom-Up

How can we reduce the number of errors in
order processing?
Figure 5.2: Top-Down and Bottom-Up Questioning Strategies
In all circumstances, all interviews should begin with non-controversial questions first and
then gradually move into more contentious issues after the interviewer has developed some
rapport with the interviewee.
Preparing for the Interview: It is important to have a good preparation before commencing
the interview. You should have a general interview plan which lists the questions that you
will ask in the appropriate order; anticipates possible answers and provides how you will
follow up with them; and identifies transitions between related topics. Confirm the areas in
which the interviewee has knowledge so you do not ask questions that he or she cannot
answer. Review the topic areas, the questions, and the interview plan, and clearly decide
which ones have the greatest priority in case you run out of time.
In general, structured interviews with closed-ended questions take more time to prepare than
unstructured interviews. However, using only unstructured interviews is very dangerous and
often counterproductive, because any information not gathered in the first interview would
98
have to be obtained by follow-up efforts, and most people do not like to be interviewed
repeatedly about the same issues.
Be sure to prepare the interviewee as well. When you schedule the interview, inform the
interviewee in advance about the reason for the interview and the areas you will be discussing
so that he or she has time to think about the issues and organize his or her thoughts. This is
particularly important when you are an outsider to the organization and for interviewing
lower-level employees who often are not asked for their opinions and who may be uncertain
about why you are interviewing them.
Conducting the Interview When you start the interview, the first goal is to build rapport
with the interviewee so that he or she trusts you and is willing to tell you the whole truth, not
just give the answers that he or she thinks you want. You should appear to be professional
and an unbiased, independent seeker of information.
The interview should start with an explanation of why you are there and why you have
chosen to interview the person, and then move into your planned interview questions.
It is critical to carefully record all the information that the interviewee provides.
A very good approach is to take careful notes i.e. write down everything the interviewee says,
even if it does not appear immediately relevant.
Don‘t be afraid to ask the person to slow down or to pause while you write, because this is a
clear indication that the interviewee‘s information is important to you. One potentially
controversial issue is whether or not to tape-record the interview. Recording ensures that you
do not miss important points, but it can be intimidating for the interviewee. Most
organizations have policies or generally accepted practices about the recording of interviews,
so find out what their policies are before you start an interview. If you are worried about
missing information and cannot record the interview on tape, then bring along a second
person to take detailed notes.
As the interview progresses, it is important that you understand the issues that are discussed.
If you do not understand something, be sure to ask. Don‘t be afraid to ask ―dumb questions,‖
because the only thing worse than appearing ―dumb‖ is to be ―dumb‖ by not understanding
something that you could have cleared up by questioning.
If you don‘t understand something during the interview, you certainly won‘t understand it
afterward. Try to recognize and define jargon, and be sure to clarify jargon you do not
understand. One good strategy to increase your understanding during an interview is to
periodically summarize the key points that the interviewee is communicating. This avoids
misunderstandings and also demonstrates that you are listening.
99
Finally, be sure to separate facts from opinion. The interviewee may say, for example, ―We
process too many credit card requests.‖ This is an opinion, and it is useful to follow this up
with a probing question requesting support for the statement (e.g., ―Oh, how many do you
process in a day?‖). It is helpful to check the facts because any differences between the facts
and the interviewee‘s opinions can point out key areas for improvement. Suppose that the
interviewee complains about a high or increasing number of errors, but the logs show that
errors have been decreasing. This suggests that errors are viewed as a very important problem
that should be addressed by the new system, even if they are declining.
As the interview draws to a close, be sure to give the interviewee time to ask questions or
provide information that he or she thinks is important but was not part of your interview plan.
In most cases, the interviewee will have no additional concerns or information, but in some
cases this will lead to unanticipated, but important information. Make sure that the interview
ends on time.
As a last step in the interview, briefly explain what will happen next. You don‘t want to
prematurely promise certain features in the new system or a specific delivery date, but you do
want to reassure the interviewee that his or her time was well spent and very helpful to the
project.
Inexperienced systems analysts may naively think that conducting an interview is as easy as
conversing with a friend. Unfortunately, this is almost never true.
Interviewees often are not able or willing to hand over the needed information in a neat,
organized fashion. In some cases, they may not want to share what they know at all. Analysts
should hone their interpersonal skills to improve their interviewing success.
Post-interview Follow-up: After the interview is over, the analyst needs to prepare an
interview report that describes the information from the interview (Figure 5.3).
The report contains interview notes, information that was collected over the course of the
interview and is summarized in a useful format. In general, the interview report should be
written within 48 hours of the interview, because the longer you wait, the more likely you are
to forget information.
100
Interview Notes Approved by: Danjuma Jude
Person Interviewed: Danjuma Jude,

Manager, Human Resources
Interviewer: Adewale Johnson

Purpose of Interview:
 Understand reports produced for Human Resources by the current
system.
 Determine information requirements for future system.
Summary of Interview:
 Sample reports of all current HR reports are attached to this report. The
information that is not used and missing information are noted on the
reports.
 Two biggest problems with the current system are:
i. The data are not recent. (The HR Department needs information within
2 days of month end; currently information is provided to them after a 4-
week delay.)
ii. The data are of poor quality, (Often, reports must be reconciled with
the HR departmental database.)
 The most common data errors found in the current system include
incorrect job-level information and missing salary information.
Open Items:
 Get current employees roster report from Folasade Olusola(Room 10)
 Verify calculations used to determine vacation time with Folasade
Olusola
 Schedule interview with Babatunde Ige(Room09) regarding the reasons
for data quality problems.
Detailed Notes: See attached transcript

Figure 5.3: Interview Report
101
Often, the interview report is sent to the interviewee with a request to read it and inform the
analyst of clarifications or updates. Make sure the interviewee is convinced that you
genuinely want his or her corrections to the report. Usually, there are few changes, but the
need for any significant changes suggests that a second interview will be required. Never
distribute someone‘s information without prior approval.
5.5.2 Joint Application Development (JAD)

Joint application development (or JAD as it is more commonly known) is an information
gathering technique that allows the project team, users, and management to work together to
identify requirements for the system. IBM (International Business Machines) developed the
JAD technique in the late 1970s, and it is often the most useful method for collecting
information from users. Capers Jones claims that JAD can reduce scope creep by 50%, and it
prevents the requirements for a system from being too specific or too vague, both of which
can cause trouble during later stages of the SDLC. JAD is a structured process in which 10 to
20 users meet under the direction of a facilitator skilled in JAD techniques. The facilitator is a
person who sets the meeting agenda and guides the discussion, but does not join in the
discussion as a participant. He or she does not provide ideas or opinions on the topics under
discussion and remains neutral during the session. The facilitator must be an expert in both
group process techniques and systems analysis and design techniques. One or two scribes
assist the facilitator by recording notes, making copies, and so on. Often, the scribes will use
computers and CASE tools to record information as the JAD session proceeds.
The JAD group meets for several hours, several days, or several weeks until all of the issues
have been discussed and the needed information is collected. Most JAD sessions take place in
a specially prepared meeting room, away from the participants‘ offices, so that they are not
interrupted. The meeting room is usually arranged in a U shape so that all participants can
easily see each other (See Figure 5.4). At the front of the room (the open part of the ―U‖),
there is a whiteboard, flip chart and/or overhead projector for use by the facilitator, who leads
the discussion.
One problem with JAD is that it suffers from the traditional problems associated with groups:
Sometimes people are reluctant to challenge the opinions of others (particularly their boss), a
few people often dominate the discussion, and not everyone participates. In a 10-member
group, for example, if everyone participates equally, then each person can talk for only 6
102
minutes each hour and must listen for the remaining 54 minutes—not a very efficient way to
collect information.
Electronic JAD, or e-JAD, attempts to overcome these problems by the use of groupware. In
an e-JAD meeting room, each participant uses special software on a networked computer to
anonymously submit ideas, view all ideas generated by the group, and rate and rank ideas
through voting. The facilitator uses the electronic tools of the e-JAD system to guide the
group process, maintaining anonymity and enabling the group to focus on each idea‘s merits
and not the power or rank of the person who contributed the idea. In this way, all participants
can contribute at the same time, without fear of reprisal from people with differing opinions.
Initial research suggests that e-JAD can reduce the time required to run JAD sessions by
50%–80%.
Figure 5.4: Joint Application Development Meeting Room
103
Just like Interview, JAD also has five steps
Selecting Participants: Selecting JAD participants is done in the same basic way as
selecting interview participants. Participants are selected on the basis of information they can
contribute, to provide a broad mix of organizational levels, and to build political support for
the new system. The need for all JAD participants to be away from their offices at the same
time can be a major problem. The office may need to be closed or run with a skeleton staff
until the JAD sessions are complete.
Ideally, the participants who are released from regular duties to attend the JAD sessions
should be the very best people in that business unit. However, without strong management
support, JAD sessions can fail, because those selected to attend the JAD session are people
who are less likely to be missed (i.e., the least competent people).
The facilitator should be someone who is an expert in JAD or e-JAD techniques and, ideally,
someone who has experience with the business under discussion.
In many cases, the JAD facilitator is a consultant external to the organization because the
organization may not have a regular day-to-day need for JAD or e-JAD expertise. Developing
and maintaining this expertise in-house can be expensive.
Designing the JAD Session: JAD sessions can run from as little as a half day to several
weeks, depending upon the size and scope of the project. Most JAD sessions tend to last 5 to
10 days spread over a 3-week period. Most e-JAD sessions tend to last 1 to 4 days in a 1-
week period. JAD and e-JAD sessions usually move beyond the collection of information
into producing analysis deliverables. For example, the users and the analysts collectively can
create use cases, process models, or the requirements definition.
As with interviewing, JAD success depends upon a careful plan. JAD sessions usually are
designed and structured along the same principles as interviews. Most JAD sessions are
designed to collect specific information from users, and this requires the development of a set
of questions prior to the meeting. A difference between JAD and interviewing is that all JAD
sessions are structured—they must be carefully planned. In general, closed-ended questions
are seldom used, because they do not spark the open and frank discussion that is typical of
JAD. It is better to adopt the top-down approach in JAD sessions when gathering
information.
Typically, 30 minutes is allocated to each separate agenda item, and frequent breaks are
scheduled throughout the day because participants get tired easily.
104
Preparing for the JAD Session: As with interviewing, it is important to prepare the analysts
and participants for the JAD session. Because the sessions can go beyond the depth of a
typical interview and usually are conducted off-site, participants can be more concerned
about how to prepare. It is important that the participants understand what is expected of
them. If the goal of the JAD session, for example, is to develop an understanding of the
current system, then participants can bring procedure manuals and documents with them. If
the goal is to identify improvements for a system, then they can think about how they would
improve the system prior to the JAD session.
Conducting the JAD Session: Most JAD sessions try to follow a formal agenda, and most
have formal ground rules that define appropriate behaviour. Common ground rules include
following the schedule, respecting others‘ opinions, accepting disagreement, and ensuring
that only one person talks at a time.
The role of the JAD facilitator can be challenging. Many participants come to the JAD
session with strong feelings about the system being discussed. Channelling these feelings so
that the session moves forward in a positive direction and getting participants to recognize
and accept—but not necessarily agree on—opinions and situations different from their own
requires significant expertise in systems analysis and design, JAD, and interpersonal skills.
Few systems analysts attempt to facilitate JAD sessions without being trained in JAD
techniques, and most apprentices with a skilled JAD facilitator before they attempt to lead
their first session.
The JAD facilitator performs three key functions.

First, he or she ensures that the group sticks to the agenda. The only reason to digress from
the agenda is when it becomes clear to the facilitator, project leader, and project sponsor that
the JAD session has produced some new information that is unexpected and requires the JAD
session (and perhaps the project) to move in a new direction. When participants attempt to
divert the discussion away from the agenda, the facilitator must be firm, but polite, in leading
the discussion back to the agenda and getting the group back on track.
Second, the facilitator must help the group understand the technical terms and jargon that
surround the system development process and help the participants understand the specific
analysis techniques used. Participants are experts in their business area, but they probably are
105
not experts in systems analysis. The facilitator must therefore minimize the learning required
and teach participants how to effectively provide the right information.
Third, the facilitator records the group‘s input on a public display area, which can be a
whiteboard, flip chart, or computer display. He or she structures the information that the
group provides and helps the group recognize key issues and important solutions.
Under no circumstance should the facilitator insert his or her opinions into the discussion.
The facilitator must remain neutral at all times and simply help the group through the process.
The moment the facilitator offers an opinion on an issue, the group will no longer see him or
her as a neutral party, but rather as someone who could be attempting to sway the group into
some predetermined solution.
However, this does not mean that the facilitator should not try to help the group resolve
issues. For example, if two items appear to be the same to the facilitator, the facilitator should
not say, ―I think these may be similar.‖ Instead, the facilitator should ask, ―Are these
similar?‖ If the group decides that they are, the facilitator can combine them and move on.
However, if the group decides that they are not similar (despite what the facilitator believes),
the facilitator should accept the decision and move on. The group is always right, and the
facilitator has no opinion.
It is common for the JAD participants to make use of a number of tools during the JAD
session in order to fully define the new system. Use cases may be created to describe how the
users will interact with the new system. Prototypes may be created to more fully understand
the user interface or navigation through the system. Process models can be constructed to
understand the software that will be developed, while a data model can be used to describe
the data that will be captured and maintained. The facilitator and the analysts on the project
team should use every tool at their disposal to help the participants clarify and define their
needs for the new system.
Post-JAD Follow-up: As with interviews, a JAD post-session report is prepared and

circulated among session attendees. The post-session report is essentially the same as the
interview report in figure 5.3. Since the JAD sessions are longer and provide more
information, it usually takes a week or two after the JAD session before the report is
complete.
106
5.5.3 Questionnaires
A questionnaire is a set of written questions for obtaining information from individuals.
Questionnaires often are used when there is a large number of people from whom information
and opinions are needed. Questionnaires are commonly used for systems intended for use
outside of the organization (e.g., by customers or vendors) or for systems with business users
spread across many geographic locations. Most people automatically think of paper when
they think of questionnaires, but today more questionnaires are being distributed in electronic
form, either via e-mail or on the Web. Electronic distribution can save a significant amount of
money, compared with distributing paper questionnaires.
Selecting Participants: As with interviews and JAD sessions, the first step is to select the
individuals to whom the questionnaire will be sent. However, it is not usual to select every
person who could provide useful information. The standard approach is to select a sample, or
subset, of people who are representative of the entire group. Sampling guidelines are not
within the scope of this text; however, they are discussed in most statistics books, so we will
not discuss them here.
The important point in selecting a sample, however, is to realize that not everyone who
receives a questionnaire will actually complete it. On average, only 30%–50% of paper and e-
mail questionnaires are returned. Response rates for Web-based questionnaires tend to be
significantly lower (often, only 5%–30%).
Designing the Questionnaire: Developing good questions is critical for questionnaires

because the information on a questionnaire cannot be immediately clarified for a confused
respondent. Questions on questionnaires must be clearly written and must leave little room
for misunderstanding; therefore, closed-ended questions tend to be most commonly used.
Questions must enable the analyst to clearly separate facts from opinions. Opinion questions
often ask the respondent the extent to which they agree or disagree (e.g., ―Are network
problems common?‖), while factual questions seek more precise values (e.g., ―How often
does a network problem occur: once an hour, once a day, or once a week?‖).
Perhaps the most obvious issue—but one that is sometimes overlooked—is to have a clear
understanding of how the information collected from the questionnaire will be analyzed and
used. You must address this issue before you distribute the questionnaire.
107
Questions should be relatively consistent in style so that the respondent does not have to read
instructions for each question before answering it. It is generally a good practice to group
related questions together to make them simpler to answer. Some experts suggest that
questionnaires should start with questions important to respondents, so that the questionnaire
immediately grabs their interest and induces them to answer it. Perhaps the most important
step is to have several colleagues review the questionnaire and then pre-test it with a few
people drawn from the groups to whom it will be sent. It is surprising how often seemingly
simple questions can be misunderstood.
Guidelines on good questionnaire design.

i. Begin with non-threatening and interesting questions
ii. Group items into logically coherent sections.
iii. Do not put important items at the very end of the questionnaire.
iv. Do not crowd a page with too many items.
v. Avoid abbreviations.
vi. Avoid biased or suggestive items or terms.
vii. Number questions to avoid confusion.
viii. Pre-test the questionnaire to identify confusing questions.
ix. Provide anonymity to respondents.
Administering the Questionnaire: The key issue in administering the questionnaire is

getting participants to complete the questionnaire and send it back. Commonly used
techniques to achieve this include clearly explaining why the questionnaire is being
conducted and why the respondent has been selected; stating a date by which the
questionnaire is to be returned; and offering to supply a summary of the questionnaire
responses.
Systems analysts have additional techniques to improve responses rates inside the
organization, such as personally handing out the questionnaire and personally contacting
those who have not returned them after a week or two, as well as requesting the respondents‘
supervisors to administer the questionnaires in a group meeting.
Questionnaire Follow-up: It is helpful to process the returned questionnaires and develop a

questionnaire report soon after the questionnaire deadline. This ensures that the analysis
process proceeds in a timely fashion and that those respondents who requested copies of the
results receive them promptly.
108
5.5.4 Document Analysis
Project teams often use document analysis to understand the current system. Under ideal
circumstances, the project team that developed the existing system will have produced
documentation, which was then updated by all subsequent projects. In this case, the project
team can start by reviewing the documentation and examining the system itself.
Unfortunately, most systems are not well documented, because project teams fail to
document their projects along the way, and when the projects are over, there is no time to go
back and document. Therefore, there may not be much technical documentation about the
current system available, or it may not contain updated information about recent system
changes. However, there are many helpful documents that do exist in the organization: paper
reports, memorandums, policy manuals, user training manuals, organization charts, and
forms.
Problem reports filed by the system users can be another rich source of information about
issues with the existing system. But these documents (forms, reports, policy manuals,
organization charts) only tell part of the story. They represent the formal system that the
organization uses. Quite often, the ―real,‖ or informal system differs from the formal one, and
these differences, particularly large ones, give strong indications of what needs to be
changed. For example, forms or reports that are never used likely should be eliminated.
Likewise, boxes or questions on forms that are never filled in (or are used for other purposes)
should be rethought. See figure 5.5 for an example of how a document can be interpreted.
The most powerful indication that the system needs to be changed is when users create their
own forms or add additional information to existing ones. Such changes clearly demonstrate
the need for improvements to existing systems. Thus, it is useful to review both blank and
completed forms to identify these deviations.
Likewise, when users access multiple reports to satisfy their information needs, it is a clear
sign that new information or new information formats are needed.
5.5.5 Observation
Observation, the act of watching processes being performed, is a powerful tool to gain insight
into the current system. Observation enables the analyst to see the reality of a situation, rather
than listening to others describe it in interviews or JAD sessions.
Several research studies have shown that many managers really do not remember how they
work and how they allocate their time.
109
Observation is a good way to check the validity of information gathered from other sources
such as interviews and questionnaires. The goal is to keep a low profile, to not interrupt those
working, and to not influence those being observed. Nonetheless, it is important to
understand that what analysts observe may not be the normal day-to-day routine because
people tend to be extremely careful in their behaviour when they are being watched. Even
though normal practice may be to break formal organizational rules, the observer is unlikely
to see this. Thus, as an analyst, what you see may not be what you really want.
Observation is often used to supplement interview information. The location of a person‘s

office and its furnishings gives clues as to their power and influence in the organization, and
such clues can be used to support or refute information given in an interview. For example,
an analyst might become sceptical of someone who claims to use the existing computer
system extensively if the computer is never turned on while the analyst visits. In most cases,
observation will support the information that users provide in interviews. When it does not, it
is an important signal that extra care must be taken in analyzing the business system.
The parent of the sick child made a

mistake. This should be labelled
Patient’s Name to prevent confusion.
ST. JUDE’S MEDICAL CENTRE

Patient Information Card
Name: Bolaji Boluwaji Samson
Address: 2, Adeoti Street, Felele, Ibadan. Boluwaji

Samson
Date of Birth: April 14, 2014
Blood Group: O+
Phone Number: 080540969993
The customer wrote more than 11-

digits as phone number. This should be
corrected in the proposed system using
11 boxes to depict where each number
will be written to avoid such mistake.
Figure 5.5: Performing a Document Analysis
110
o ----------------- is a set of written questions for obtaining information from individuals
 A questionnaire
Now that you are able to explain the Requirements Gathering Techniques, let us learn the
criteria for selecting the appropriate requirements gathering techniques.
5.6 Criteria for Selecting the Appropriate Requirement Gathering Techniques

Each of the requirements gathering techniques just discussed has strengths and weaknesses.
No one technique is always better than the others, and in practice most projects benefit from a
combination of techniques. Thus, it is important to understand the strengths and weaknesses
of each technique and when to use each (See table 5.4). In general, document analysis and
observation require the least amount of training, while JAD sessions are the most
challenging.
The following criteria are important in considering the techniques to adopt:
 Type of Information
 Depth of Information
 Breadth of Information
 Integration of Information
 User Involvement and
 Cost
Type of Information: Some techniques are more suited for use at different stages of the
analysis process, whether understanding the current system, identifying improvements, or
developing the proposed system. Interviews and JAD are commonly used in all three stages.
111
Interviews Joint Questionnaire Documen Observatio
Application s t Analysis n
Design
Type of Current, Current, Current, Current Current
Information Improvements Improvements Improvements
, Proposed , Proposed
Depth of High High Medium Low Low
Information
Breadth of Low Medium High High Low
Information
Integration Low High Low Low Low
of
Information
User Medium High Low Low Low
Involvemen
t
Cost Medium Low-Medium Low Low Low-
Medium
Table 5.4 Comparing Requirement Gathering Techniques
In contrast, document analysis and observation usually are most helpful for understanding the
current system, although they occasionally provide information about improvements.
Questionnaires are often used to gather information about the current system, as well as
general information about improvements.
Depth of Information: The depth of information refers to how rich and detailed the
information is that the technique usually produces and the extent to which the technique is
useful at obtaining not only facts and opinions, but also an understanding of why those facts
and opinions exist. Interviews and JAD sessions are very useful at providing a good depth of
rich and detailed information and helping the analyst to understand the reasons behind them.
At the other extreme, document analysis and observation are useful for obtaining facts, but
little beyond that. Questionnaires can provide a medium depth of information, soliciting both
facts and opinions with little understanding of why.
112
Breadth of Information: Breadth of information refers to the range of information and
information sources that can be easily collected by that technique. Questionnaires and
document analysis both are easily capable of soliciting a wide range of information from a
large number of information sources. In contrast, interviews and observation require the
analyst to visit each information source individually and, therefore, take more time. JAD
sessions are in the middle because many information sources are brought together at the same
time.
Integration of Information: One of the most challenging aspects of requirements gathering

is the integration of information from different sources. Simply put, different people can
provide conflicting information. Combining this information and attempting to resolve
differences in opinions or facts is usually time consuming because it means contacting each
information source in turn, explaining the discrepancy, and attempting to refine the
information. In many cases, the individual wrongly perceives that the analyst is challenging
his or her information, when in fact the source of conflict is another user in the organization.
This can make the user defensive and make it hard to resolve the differences.
All techniques suffer integration problems to some degree, but JAD sessions are designed to
improve integration because all information is integrated when it is collected, not afterward.
If two users provide conflicting information, the conflict becomes immediately obvious, as
does the source of the conflict. The immediate integration of information is the single most
important benefit of JAD that distinguishes it from other techniques, and this is why most
organizations use JAD for important projects.
User Involvement: User involvement refers to the amount of time and energy the intended
users of the new system must devote to the analysis process. It is generally agreed that, as
users become more involved in the analysis process, the chance of success increases.
However, user involvement can have a significant cost, and not all users are willing to
contribute valuable time and energy. Questionnaires, document analysis, and observation
place the least burden on users, while JAD sessions require the greatest effort.
Cost: Cost is always an important consideration. In general, questionnaires, document

analysis, and observation are low-cost techniques (although observation can be quite time
consuming). The low cost does not imply that they are more or less effective than the other
techniques. We regard interviews and JAD sessions as having moderate costs. In general,
JAD sessions are much more expensive initially, because they require many users to be
113
absent from their offices for significant periods, and they often involve highly paid
consultants. However, JAD sessions significantly reduce the time spent in information
integration and thus cost less in the long term.

o ----------------- is referred to the range of information and information sources that can
be easily collected by a technique.
 Breadth of information
Now that you are able to explain the Requirements Gathering Techniques, let us learn the
analysis strategies.
5.6.1 Requirements Analysis Strategies

In the previous sub-session you learned five essential techniques that analysts will use to
interact with stakeholders in the system development project to gather and define
requirements. Here, you will learn several strategies that the analyst can employ with the
stakeholders to accomplish his/her goal.
a. Problem Analysis
The most straightforward (and probably the most commonly used) requirements analysis
strategy is problem analysis. Problem analysis means asking the users and managers to
identify problems with the current system and to describe how to solve them in the proposed
system. Most users have a very good idea of the changes they would like to see, and most
will be quite vocal about suggesting them. Most changes tend to solve problems rather than
capitalize on opportunities, but this is possible, too. Improvements from problem analysis
tend to be small and incremental (e.g., add a field to store the customer‘s cell phone number;
provide a new report that currently does not exist).
This type of improvement often is very effective at improving a system‘s efficiency or ease
of use. However, it often provides only minor improvements in business value i.e. the new
system is eventually better than the old, but it may be hard to identify significant monetary
benefits from the new system.
114
b. Root Cause Analysis
The ideas produced by problem analysis tend to be solutions to problems. All solutions make
assumptions about the nature of the problem, assumptions that may or may not be valid.
Users and most people in general tend to jump quickly to solutions without fully considering
the nature of the problem. Sometimes the solutions are appropriate, but many times they
address a symptom of the problem, not the true problem or root cause itself. For example,
suppose that the users report that ―inventory stock-outs happen frequently.‖ Inventory stock-
outs are not good, of course, and one obvious way to reduce their occurrence is to increase
the quantity of items kept in stock. This action incurs costs, however, so it is worthwhile to
investigate the underlying cause of the frequent stock-outs instead of jumping to a quick-fix
solution. The solutions that users propose (or systems that analysts consider) may address
either symptoms or causes, but without careful analysis, it is difficult to tell which one.
Finding out later that you‘ve just spent millions of naira and have not fixed the underlying
problem is a horrible feeling!
Root cause analysis focuses on problems first rather than solutions. The analyst starts by
having the users generate a list of problems with the current system, then prioritizes the
problems in order of importance. Starting with the most important, the users and/or analysts
generate all possible root causes for the problem.
As shown in figure 5.6, the problem of ―too frequent stock-outs‖ has several potential root
causes (inaccurate on-hand counts; incorrect reorder points; lag in placing supplier orders).
Each possible root cause is investigated and additional root causes are identified. As figure
5.6 shows, it is sometimes useful to display the potential root causes in a tree-like hierarchy.
Ultimately, the investigation process reveals the true root cause or causes of the problem,
enabling the team to design the system to correct the problem with the right solution. The key
point in root cause analysis is to always challenge the obvious and dig into the problem
deeply enough that the true underlying cause(s) is revealed.
115
Frequent Inventory
stock-outs
Supplier order lag Inaccurate on-hand Incorrect reorder

counts quantities
Lag in supplier order Lag in recording sold Reorder point too

approval inventory low
Lag in identifying Infrequent manual

Economic Order
best supplier count reconciliation
Quantity (EOQ) too
low
Lag in sending order

Lag in recording
to supplier items received from
suppliers
Figure 5.6: Root Cause Analysis for Inventory Stock Outs
c. Duration Analysis
Duration analysis requires a detailed examination of the amount of time it takes to perform
each process in the current system. The analysts begin by determining the total amount of
time it takes, on average, to perform a set of business processes for a typical input. They then
time each of the individual steps (or sub-processes) in the business process. The time to
complete the basic steps are then totalled and compared with the total for the overall process.
A significant difference between the two and the total time often can be 10 or even
100 times longer than the sum of the parts—indicates that this part of the process is badly in
need of a major overhaul.
For example, suppose that the analysts are working on a home mortgage system and discover
that, on average, it takes 30 days for the bank to approve a mortgage.
They then look at each of the basic steps in the process (e.g., data entry, credit check, title
search, appraisal, etc.) and find that the total amount of time actually spent on each mortgage
116
is about 8 hours. This is a strong indication that the overall process is badly broken, because
it takes 30 days to perform 1 day‘s work.
These problems likely occur because the process is badly fragmented. Many different people
must perform different activities before the process is complete. In the mortgage example, the
application probably sits on many peoples‘ desks for long periods of time before it is
processed. Processes in which many different people work on small parts of the inputs are
prime candidates for process integration or parallelization.
Process integration means changing the fundamental process so that fewer people work on
the input, which often requires changing the processes and retraining staff to perform a wider
range of duties. Process parallelization means changing the process so that all the individual
steps are performed at the same time. For example in the mortgage application example, there
is probably no reason that the credit check cannot be performed at the same time as the
appraisal and title check.
d. Activity-Based Costing
Activity-based costing is a similar analysis that examines the cost of each major process or
step in a business process rather than the time taken. The analysts identify the costs
associated with each of the basic functional steps or processes, identify the most costly
processes, and focus their improvement efforts on them.
Assigning costs is conceptually simple. You just examine the direct cost of labour and
materials for each input. Materials costs are easily assigned in a manufacturing process, while
labour costs are usually calculated on the basis of the amount of time spent on the input and
the hourly cost of the staff. However, as you may recall from a managerial accounting course,
there are indirect costs such as rent, depreciation, and so on that also can be included in
activity costs.
e. Informal Benchmarking
Benchmarking refers to studying how other organizations perform a business process in order
to learn how your organization can do something better. Benchmarking helps the
organization by introducing ideas that employees may never have considered, but that have
the potential to add value.
117
Informal benchmarking is fairly common for ―customer-facing‖ business processes (i.e.,
those processes that interact with the customer). With informal benchmarking, the managers
and analysts think about other organizations, or visit them as customers to watch how the
business process is performed. In many cases, the business studied may be a known leader in
the industry or simply a related firm.
For example, suppose that the team is developing a Web site for a car dealer. The project
sponsor, key managers, and key team members would likely visit the Websites of
competitors, those of others in the car industry (e.g., manufacturers, accessories suppliers),
and those of other industries that have won awards for their Websites.
f. Outcome Analysis
Outcome analysis focuses on understanding the fundamental outcomes that provide value to
customers. While these outcomes sound as though they should be obvious, they often aren‘t.
For example, suppose that you are an insurance company and one of your customers has just
had a car accident. What is the fundamental outcome from the customer‘s perspective?
Traditionally, insurance companies have answered this question by assuming that the
customer wants to receive the insurance payment quickly. To the customer, however, the
payment is only a means to the real outcome: a repaired car. The insurance company might
benefit by extending its view of the business process past its traditional boundaries to include,
not simply paying for repairs, but performing the repairs or contracting with an authorized
body shop to do them.
With this approach, the system analysts encourage the managers and project sponsor to
pretend that they are customers and to think carefully about what the organization‘s products
and services enable the customers to do—and what they could enable the customer to do.
g. Technology Analysis
Many major changes in business over the past decade have been enabled by new
technologies. Technology analysis therefore starts by having the analysts and managers
develop a list of important and interesting technologies. Then the group systematically
identifies how each and every technology could be applied to the business process and
identifies how the business would benefit.
For example, one useful technology might be the Internet. A manufacturer could develop an
extranet application for its suppliers. Rather than ordering parts for its products, the
118
manufacturer makes its production schedule available electronically to its suppliers, who ship
the needed parts so that they arrive at the plant just in time.
This saves significant costs because it eliminates the need for people to monitor the
production schedule and issue purchase orders.
h. Activity Elimination
Activity elimination is exactly what it sounds like. The analysts and managers work together
to identify how the organization could eliminate each and every activity in the business
process, how the function could operate without it, and what effects are likely to occur.
Initially, managers are reluctant to conclude that processes can be eliminated, but this is a
―force-fit‖ exercise in that they must eliminate each activity. In some cases the results are
silly; nonetheless, participants must address each and every activity in the business process.
For example, in a home mortgage approval process, the managers and analysts would start by
eliminating the first activity, entering the data into the mortgage company‘s computer. This
leads to one of two obvious possibilities:
(1) Eliminate the use of a computer system or (2) make someone else do the data entry (e.g.,
the customer, over the Web). They would then eliminate the next activity, the credit check.
Does it sound silly? After all, making sure the applicant has good credit is critical in issuing a
loan, isn‘t it? Not really. The real answer depends upon how many times the credit check
identifies bad applications. If all or almost all applicants have good credit and are seldom
turned down by a credit check, then the cost of the credit check may not be worth the benefit
of the few bad loans it prevents. Eliminating it may actually result in lower costs, even with
the cost of bad loans, unless the number of applicants with poor credit greatly increases.

o ------------- is the process of asking the users and managers to identify problems with
the current system and to describe how to solve them in the proposed system.
 Problem analysis
Now that you are able to explain the Requirements analysis strategies, let us compare some
requirement analysis strategies.
119
5.6.2 Comparing Requirement Analysis Strategies
Each of the requirements analysis strategies discussed here has its own purpose. No one
technique is inherently better than the others. Remember that an organization will likely have
a wide range of projects in its portfolio; the requirements analysis strategy should be chosen
to fit the nature of the project. Problem analysis and root cause analysis tend to be most
useful in situations with a narrow focus where efficiency gains are sought. Duration analysis
and activity-based costing strategies help the team find the most ―broken‖ business processes
so that those processes can be redesigned and improved. Outcome analysis, technology
analysis, and informal benchmarking help the team think ―outside the box‖ and are very
useful when the team is trying to create completely new ways of accomplishing the business
processes.

o ----------------- and -------- strategies help a team to find the most ―broken‖ business
processes so that those processes can be redesigned and improved.
 Duration analysis and activity-based costing
In the study session 5, you learned about analysis and its requirement strategies. In the
following session 6, you will learn about information system modelling and analysis.
Activity 5.1 The analysis Phase

and knowing that the systems analyst works extensively with the business users of the new
system to understand their needs from a proposed system, note down some of the key steps
involve in basic process of analysis?

The basic process of analysis involves three steps: these are: Understand the existing system,
Identify improvements and Define requirements for the new system
Take a look at sub-session 5.1; it describes in details the three basic steps involve in the
process of analysis.
120
 For us to meaningfully learn about a system there is a need to understand its
requirement analysis. In other words the meaning of analysis and its strategies are
explained in Box 5.1
Box 5.1: Meaning of requirement analysis and its strategies
Analysis is referred to breaking a whole into its parts with the intent of
understanding the parts‘ nature, function, and interrelationships.
 The three basic process of analysis which are:
i Understanding the existing system (the as-is system).
ii Identifying improvements.
iii Defining requirements for the new system (the to-be system).
 That, a requirement is simply a statement of what the system must do or
what characteristics does it need to have.
 That the traditional methods of requirement gathering are:
i. Interviews
ii. Questionnaires
iii. Observation
iv. Document Analysis

i. Joint Application Development JAD
ii. Prototyping
 Requirements Gathering Techniques are Interviews, Joint Application

Development (JAD) Questionnaires, Document Analysis, and Observation
 Five JAD steps are: Selecting Participants, Designing the JAD Session,
Preparing for the JAD Session, Conducting the JAD Session, Post-JAD
Follow-up

1. Analysis is referred to breaking a whole into its parts with the intent of understanding the
parts‘ nature, function, and interrelationships.
2. The systems analyst need to works extensively with the business users of the new system
to understand their needs from the new/proposed system.
3.The basic process of analysis involves three steps, which are: understanding the existing
system, identifying improvements and defining requirements for the new system.
4. There are various techniques for requirement elicitation that can be used to acquire
information for a system, they are broadly categorised as traditional and modern methods.
121

Can you explain the term analysis phase of a system development?
Can you define requirement?
Can you enumerate the techniques that can be used to acquire information for a system?
SAQ 5.4 ((tests learning outcome 5.4)
Can you state the two group of requirement?
SAQ 5.5. (tests learning outcome 5.5.)
Can you list the three types of interview questions?
Can you state five criteria to consider for requirement gathering techniques?
SAQ 5.1: Analysis is referred to breaking a whole into its parts with the intent of
understanding the parts‘ nature, function, and interrelationships.
SAQ 5.2: A requirement is simply defined as a statement of what the system must do or
what characteristics does it need to have
SAQ 5.3: The various techniques that can be used to acquire information for a system are
broadly categorized as traditional and modern methods. The traditional methods of
requirement gathering are:
 Interviews
 Questionnaires
 Observation
 Document Analysis
122
 Joint Application Development (JAD)
 Prototyping
SAQ 5.4: The requirements for analysis are grouped into functional and non-functional
groupings.
SAQ 5.5: The three types of interview questions are:

i Closed-Ended Questions
ii Open-Ended Questions
iii Probing Questions
SAQ 5.6: The following criteria should be considered while deciding which techniques to
adopt:
i Type of Information
ii Depth of Information
iii Breadth of Information
iv Integration of Information
v User Involvement and
vi Cost
References
Sacha M., Aybüke A., Ross J., and Barbara P., (2002): Requirements Engineering Process
Models in Practice. School of Information Systems, Technology and Management,
University of New South Wales.
123
Study Session 6: Modelling and Analysis of Information System
Introduction
In the previous study session, you learned the different types of requirements and the stage in
the SDLC at which they are defined. You have also learned about the SDLC's planning phase
(see study session 3 and 6). There are statements in the system request that indicate the
reasons for proposing the systems development project. This session teaches in depth what
you need to know about the concept of information system modelling and analysis.

6.1 Define logical process models (SAQ 6.1)
6.2 Describe the applicability of use-case modelling (SAQ 6.2)
6.3. Describe the term include relationship (SAQ 6.3.)
6.4 Define process modelling (SAQ 6.4)
6.5 Describe Data Flow Diagram (DFD) (SAQ 6.5)
6.1 Data Flow Diagram (DFD)

In system development life cycle (SDLC), a system model can be developed using Data Flow
Diagram (DFD). DFD is graphical diagrams for specifying, constructing and visualizing the
model of a system. DFD is used in defining the requirements in a graphical view. It is
important to start with a business process model which fully articulates the vision and goals
for the new process (at whichever level the process is within the organisation) when
producing software. Furthermore, these goals need to be auditable through the process to
ensure the developed system assists attainment of the process and its goals. Models provide a
mechanism for decomposition and expressing specifications. Modelling is a popular approach
in structured system analysis and design. The essence of modelling is to organize the
requirements in a systematic and comprehensible manner. In this unit, our focus is on logical
124
process models, which are models that describe processes, without suggesting how they are
conducted. By focusing on logical processes first, analysts can focus on how the business
should run, without being distracted by implementation details. The physical details are
defined during the design phase when these logical models are refined into physical models,
which provide information that is needed to ultimately build the system.

o The essence of modelling is to ----------- in a systematic and comprehensible manner.
 Organize the requirements
6.2.1 Use-Case Modelling

In order to model a system, it is important to capture the behaviour of the system when it is in
operation. When requirements are documented using use cases, textual descriptions are used
along with the use case diagrams. The use case diagram is a part of the Unified Modelling
Language (UML). UML is a modelling language or graphical notation for object-oriented
programming- a way to express the blueprints of your system. In UML, there are several
types of diagrams available to model the behaviour/dynamic nature of a system; these include
Use-cases (for requirements), activity diagram (models object activities), class diagram
(captures static structural aspects, objects and relationships), sequence diagram (models
object interaction over time, it is used for object-oriented design), collaboration diagram
(models component interaction and structural dependencies i.e. expresses the flow of
messages between objects) and state diagram (dynamic state behaviour).
Use-case modelling is widely used in modern software development methods as an approach

for describing a system‘s requirements. They are used to explain and document the
interaction that is required between the user and the system to accomplish the user‘s task. Use
cases are created to help the development team understand more fully the steps that are
involved in accomplishing the user‘s goals. Once created, use cases often can be used to
derive more detailed functional requirements for the new system.
From the use case model, it is possible to determine other representations of the system at the
same level of abstraction as well as representations at lower levels of abstraction. Use case
model presents the external view, also known as black box view of the system. Views that
address the internals of the system are white box views; they are at lower levels of
abstraction.
125
Use case diagrams are considered for high level requirement analysis of a system. So when
the requirements of a system are analyzed, the functionalities are captured in use cases.
When requirements are documented using use cases, these use case are then valuable during
the next steps in the system development project, such as in the design and testing activities.
Also, it will be easier to write the user manual if requirements are documented by means of
use cases.
When we are planning to draw a use case diagram we should have the following items
identified:
 Functionalities to be represented as a use case
 Actors
 Relationships among the use cases and actors.
Use case diagrams are drawn to capture the functional requirements of a system. So after
identifying the above items we have to follow the guidelines listed below in order to draw an
efficient use case diagram.
i. The name of a use case is very important. So the name should be chosen in such a
way so that it can identify the functionalities performed.
ii. Give a suitable name for actors.
iii. Show relationships and dependencies clearly in the diagram.
iv. Do not try to include all types of relationships. Because the main purpose of the
diagram is to identify requirements.
v. Use note whenever required to clarify some important points.
A use case model consists of use case diagrams depicted in UML and use case descriptions.
The UML model depicts the use case, actors, communication associations between actors and
use cases, and use case relationships, in particular the <<extends>> and <<includes>>
relationships. The default relationship between an actor and a use case is the
<<communication>>relationship, denoted by a line with a small circle. The UML notation
does not address the use case description, which is in many ways the most important part of
the use case model. The description includes the preconditions, postconditions, the
description of the main sequence of the use case and the description of alternative sequences.
Thus a use case describes several scenarios. The main scenario describes a successful
sequence of events, and the alternative scenarios describe a sequence of events that differ
from a typical usage of the system. A typical usage of the system may be less frequently
taken interactions or unsuccessful terminations that can be detected and resolved by the
application; alternative system outputs; or alternative ways of entering system input.
126
The UML notation for use case is shown thus:
Use case is a narration of the sequence of events (function) of an actor using a system. A use
case should correspond to one or more scenarios. The name of a use case should begin with a
verb in order to emphasize that it is a process e.g. Buy items, Enter an order, Reduce
inventory etc.
The UML notation for actor is depicted as:
Actor is an entity external to the system that in some way participates in the use case.
An actor typically stimulates the system with input events or receives outputs from the
system or does both.
Primary Actor: an entity external to the system that uses system services in a direct manner.
Supporting Actor: an actor that provides services to the system being built.
Hardware, software applications, individual processes, can all be actors.
While choosing actors,

i. Identify system boundary
ii. Identify entities, human or otherwise, that will interact with the system, from outside the
boundary. For instance, a temperature sensing device is an actor for a temperature monitoring
application.
Identification of Use Cases

To identify use cases, focus on elementary business processes (EBP). Elementary business
process is a task performed by one person in one place at a time, in response to a business
event. This task adds measurable business value and leaves data in a consistent state.
Three methods can be used to identify use cases for a system:

i. Actor based
Identify the actors related to the system, identify the scenarios these actors initiate or
participate in.
ii. Event based
127
Identify the external events that a system must respond to, relate the events to actors and use
cases.
iii. Goal based

All actors in the system have goals, find user goals by preparing actor-goal list, and define a
use case for each goal.
A common mistake in use case modelling is trying to represent individual steps as use cases,
for instance, printing a receipt. Rather than designating this as a use case, what should be
considered is why is the printing being done?
Let‘s consider the following use cases:
 Log out
 Handle payment
 Negotiate contract with a supplier.
These use cases are at different levels i.e. High or low levels, an important question to ask
before using them as use cases is, are they all valid? To verify this, use the definition of
elementary business process we mentioned earlier in this section.
Now, let‘s analyse each of them:
Log out: A secondary goal, it is necessary to do something but not useful in itself.
Handle payment: A necessary EBP, hence a primary goal.
Negotiate contract: Most likely this is too high a level. It is composed of several EBPs and
hence must be broken down further.
6.2.2 A Use Case Example

A section of the use case model and some system view are described for an example hotel
system. Part of the use case model for a hotel system that contains the Login, Make
reservation and Cancel reservation use cases is shown in figure 6.1. A use case description of
the Make reservation use case is shown in table 6.1.
128
Login
Make reservation
Reservation Clerk
Cancel reservation
Figure 6.1: Section of a use case model for a hotel system
Name Make reservation

Summary Reservation clerk reserves a room for a hotel guest
Actor Reservation clerk
Precondition Reservation clerk has logged into the Hotel system
Description
1. Guest gives personal details to reservation clerk, such as name, room type,
number of occupants, and dates and times of arrival and departure.
2. Reservation clerk enters information into the system and looks up
availability and room reservation rate.
3. If room is available, clerk requests the guest to guarantee the reservation
with a credit card number.
4. The clerk enters the guest‘s credit card number to guarantee the
reservation.
5. If credit card number is valid, the clerk updates the reservation as
guaranteed.
Alternatives Room not available: Line 3: If a room is not available, clerk requests the
customer for another date and/or time of arrival and departure.
Invalid card: Line 5: If the credit card number is not valid, the clerk requests
the customer for another credit card number.
Postcondition The reservation is created for the guest.
Table 6.1: Use case description of Make reservation use case
129
o Can you list the three methods that can be used to identify cases for a system?
 Actor Based, Event based, and Goal based
6.3.1 Use Case Relationships

There are several different kinds of relationships between actors and use cases. Earlier, we
said that the default relationship is the communication relationship. The communication
relationship indicates that one of these entities initiated communication or invoked request of
the other. Obviously, an actor communicates with use cases because actors want measurable
results. It might not be quite as obvious that use cases can communicate with other use cases.
This happens when a use case needs information from or to initiate action of another use
case. When a line or an arrow is drawn on a diagram and there is no label on the arrow, it is,
by default, a communication relationship.
There are two other kinds of relationships between use cases (not between actors and use
cases) that you might find useful. These are the include relationship and the extend
relationship, both of which we will describe in this section.
6.3.2 The include Relationship

The include relationship signifies that one use case is included in another‘s functionality.
You use the include relationship when a chunk of behaviour is similar across more than one
use case and you don‘t want to keep copying the description of that behaviour. This is similar
to breaking out re-used functionality in a program into its own methods that other methods
invoke for that functionality. For example, suppose many actions of a system require the user
to log into the system before the functionality can be performed. These use cases would
include the Login use case. Here‘s a hint. You should not break out a use case to be included
by other use cases unless more than one other use case will include it (i.e. in a case diagram
there should be more than one arrow coming into the included use case).
The include relationship is not the default relationship. Therefore, in a use case diagram, the
arrow is labelled with «include» when one use case makes full use of another use case, as
shown in Figure 6.2. The Draw Card and the Buy House both use the View Information
functionality. Whenever a use case includes functionality of another use case, the use case
flow-of-events will call the included use case.
130
Draw card
<<include>
>
View Info
<<include>
>
Player
Buy House
Figure 6.2: The Include Relationship between Use Cases
6.3.3 The extend Relationship

You use the extend relationship when you are describing a variation on normal behaviour or
behaviour that is only executed under certain, stated conditions. You might wonder how this
is different from simply stating alternative flows. The extend relationship is similar to the
alternative flows of a use case. However, the extend relationship is used when the alternative
flow is fairly complex and/or multi-stepped, possibly with sub-flows and alternative flows.
For example, consider a scenario described below:
A player moves on the board because he or she has to go to jail.

A player moves on the board because he or she has to go to Free Parking.
This scenario involves a player moving. However, sometimes a player has to deal with
―exceptional‖ situations – rather than just moving to a new property cell. Therefore, we can
extend the Move use case with the Go to Jail and the Go to Free Parking use case (and some
others) as shown in Figure 6.3. In this diagram the extend relationship is signified by writing
«extend» below a dotted line whose arrow points toward the use case that is being extended.
Move Go to Jail
<<extend>>
Figure 6.3: The Extend Relationship between Use Cases
131
6.3.4 Include Versus extend
Frequently, system analyst and developers are confused as to whether to use the include
relationship or the extend relationship. Consider the following distinctions between the two:
• Use Case X includes Use Case Y:
This means that X has a multi-step subtask Y. In the course of doing X or a subtask of X, Y
will always be completed.
• Use Case X extends Use Case Y:
This means that Y performs a sub-task and X is a similar but more specialized way of
accomplishing that subtask (e.g. going to jail is a sub-task of Y; X provides an alternative
means of moving). X only happens in an exception situation. Y can complete without X ever
happening.
In general, the extend relationship makes use cases difficult to understand. It is suggested that
analysts and developers use this relationship sparingly.

o When a line or an arrow is drawn on a diagram and there is no label on the arrow, it
is, by default, called ------------.
 A communication relationship
132
6.4 Process Modelling
Process modelling is a technique for organizing and documenting the structure and flow of
data through a system‘s processes and/or the logic, policies, and procedures to be
implemented by a system‘s processes. A process model graphically represents the processes
that capture, manipulate, store and distribute data between a system and its environment and
among system components. A system analysis process model consists of data flow diagrams
(DFDs); it describes business processes i.e. the activities that people do. Process models are
developed for the current system and/or the proposed system. In unit five, we discussed
requirement gathering, methods and approaches etc, these requirements can be well clarified
through process modelling. This section describes data flow diagramming, one of the most
commonly used process modelling techniques.

o ---------- Graphically represents the processes that capture, manipulate, store and
distribute data between a system and its environment and among system components.
 A process model
6.5 Data Flow Diagrams (DFD)

DFD graphically illustrates the movement of data between external entities, the processes and
data stores within a system. A data flow diagram (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. Because data-
flow diagrams concentrate on the movement of data between processes, these diagrams are
called process models. Process modelling and creating DFDs in particular are among the
most important technical skills needed by systems analysts.
Data flow diagrams are constructed using only a few symbols, hence, they are easier to
understand than typical flowcharts; although there are certain similarities. A flowchart is
much less specific with regard to how pieces of data are broken down, combined, and moved
around the system than is a DFD. On the other hand, a flowchart is much more specific and
physical than a DFD with regard to how processing is performed. A data flow diagram is
more flexible and has a more general applicability than does a flowchart.
133
Modelling a system‘s process utilizes information gathered during requirements
determination and the structure of the data is also modelled in addition to the processes. The
deliverables and outcomes of these process modelling include:
i. Set of coherent, interrelated data flow diagrams
ii. Context data flow diagram (DFD): Scope of system
iii. DFDs of current system: Enables analysts to understand current system
iv. DFDs of new logical system: it is technology independent and it shows data flows,
structure and functional requirements of new system
v. Project dictionary and CASE repository.

o -----------------is a collection of computer systems used by an organization.
 Information technology
In the next study session, we discuss modelling and information system in details.
Activity 6.1: Modelling and Analysis of Information System--I

and knowing that modelling and analysis has a wide scope, note down the three methods used
in identifying use-cases for a system?
Activity 6.1 Feedback: The following methods are used to identify system use cases:
i. Actor based: Identify the actors related to the system, identify the scenarios these actors
initiate or participate in.
ii. Event based: Identify the external events that a system must respond to, relate the events to
actors and use cases.
iii. Goal based: All actors in the system have goals, find user goals by preparing actor-goal
list, and define a use case for each goal.
 For us to meaningfully learn about modelling and analysis of information system

there is a need to understand some concepts of a modelling and DFD. In other words
the meaning and concept of a modelling and DFD are explained in Box 6.1
134
Box 6.1: Modelling and data flow diagram (DFD)
DFD is graphical diagrams for specifying, constructing and visualizing the model of a
system.
A system analysis process model consists of data flow diagrams (DFDs); it describes
business processes i.e. the activities that people do.

 DFD is used in defining the requirements in a graphical view.
 The essence of modelling is to organize the requirements in a systematic and
comprehensible manner.
 The use case diagram is a part of the Unified Modelling Language (UML).
 UML is a modelling language or graphical notation for object-oriented
programming- a way to express the blueprints of your system.
 Three methods are used to identify use cases for a system, these are:
i. Actor based
ii. Event based
iii. Goal based
 There are several different kinds of relationships between actors and use cases.
A process model graphically represents the processes that capture, manipulate, store and
distribute data between a system and its environment and among system components.

1. DFDs are graphical diagrams for specifying, constructing and visualizing the model of a
system.
2. Logical process models are models that describe processes, without suggesting how they
are conducted.
Process modelling is a technique for organizing and documenting the structure and flow of
data through a system‘s processes.
3. Use-case diagram is part of the Unified Modelling Language (UML) that are used to
explain and document the interaction that is required between the user and the system to
accomplish the user‘s task,
4. A data flow diagram (DFD) illustrates the movement of data between the external entities,
the processes and data stored within an information system, without showing program logic
or processing steps.
135

Can you describe logical process model?
Can you describe the applicability of use-case modelling?
Can you describe the terms include relationship?
Can you define Process modelling?
Can you describe data flow diagrams?
SAQ 6.1: Logical process models can be described as models that describe processes,
without suggesting how they are conducted
SAQ 6.2: Use-case modelling is widely used in modern software development methods as
an approach for describing a system‘s requirements.
SAQ 6.3: The term ‗‘include relationship‘‘ signifies that one use case is included in
another‘s functionality
SAQ 6.4: The Process modelling is a technique for organizing and documenting the
structure and flow of data through a system‘s processes and / or the logic, policies,
and procedures to be implemented by a system‘s processes
SAQ 6.5: A data flow diagram (DFD) illustrates the movement of data between the external
entities, the processes and data stored within an information system, without
showing program logic or processing steps.
136
References
Denise D., and Dr. Ken L. (n.d.): Analysis and Design for Process Support Systems using
Goal oriented Business Process Modelling. School of Computing & Mathematics, University
of Huddersfield, England
Hassan G., and Erika Mir O. (n.d.): The Role of Use Cases in Requirements and Analysis
Modelling. Department of Information and Software Engineering, George Mason University,
Fairfax, VA
Professor Yong Tan (n.d.): Lecture 11: Process Modelling. IS 460 Notes
Rosziati I., and Siow Y. Y. (2010): Formalization of the Data Flow Diagram Rules for
Consistency Check. International Journal of Software Engineering & Applications (IJSEA),
Vol.1, No.4.
William Y. Arms (n.d.): CS 5150 Software Engineering: Requirements Analysis. Cornell

University of Computing and Information Science
137
Study Session 7: Modelling and Analysis of Information System-
II
Introduction
In the previous study session, you learned the meaning of modelling and DFD. You have also
learned about the SDLC's planning phase (see study session 3 and 6). There are statements in
the system request that indicate the reasons for proposing the systems development project.
This session teaches in depth what you need to know about the concept of information system
modelling and analysis.
7.1 Highlight the elements of data flow diagrams (SAQ 7.1)
7.2 Describe the decomposition of DFDs (SAQ 7.2)
7.3 List guidelines for drawing a context diagram (SAQ 7.3)
7.4 Explain how to Validate DFDs (SAQ 7.4)
7.5 Explain the concepts of modelling an Information System using use-case Diagrams (SAQ
7.5)
7.1 Elements / Symbols of Data Flow Diagrams

i. Data Flows & Control Flows
A data flow represents an input of data to a process, or the output of data from a process. It is
a path for data to move from one part of the information system to another. A data flow may
also be used to represent the creation, reading, deletion, or updating of data in a file or
database (data store).
138
A composite data flow is a data flow that consists of other data flows.
A control flow represents a condition or non-data event that triggers a process. Control flows
are not frequently used on DFDs.
Although the DFD does not show the detailed contents of a data flow, that information is
included in the data dictionary. Data flow is represented with an arrow
ii. Data Store

A data store is an inventory of data which one or more processes need to use at a later time.
Data store is frequently implemented as a file or database. It is ―data at rest‖ compared to a
data flow that is ―data in motion.‖ A data store must be connected to a process with a data
flow. The data store has at least one incoming and one outgoing data flow and is connected to
a process symbol with a data flow. A DFD does not show the detailed contents of data store
but its specific structure and data elements are defined in the data dictionary.
Any of the following could represent data store in an information system:
 Persons (or groups of persons)
 Places
 Objects
 Events (about which data is captured)
 Concepts (about which data is important)
All instances of data entities that are depicted on an entity-relationship diagram are also
depicted on the data stores of DFD
Data Store
iii. External Agents /Entities

An external agent defines a person, organization unit, or other organization that lies outside
of the scope of the project but that interacts with the system being studied. External agents
define the boundary or scope of a system being modelled. As the scope of a system changes,
external agents can become processes, and vice versa.
An external entity must be connected by a data flow to a process, and not directly to a data
store or to another external entity.
Often, any of the following could be an external agent in an information system:
139
 Office, department, division inside the business but outside the system scope.
 An external organization or agency.
 Another business or another information system.
 One of your system‘s end-users or managers
Alternatively, external entities are referred to as Source/Sink. Source/Sink depicts the origin
and/or destination of the data. They are drawn as a square symbol. The name of the
source/sink states what the external agent is, however, because they are external, many
characteristics are not of interest to us.
External Agent
iv. Process Concepts

A process is work performed on, or in response to, incoming data flows or conditions so that
they are transformed, stored or distributed. When modelling the data processing of a system,
it doesn‘t matter whether a process is performed manually or by a computer.
A
Process

o A data flow represents an input of data to a process, or the output of data from a
process. True/False
 True
7.2 Process Decomposition

Most business processes are too complex to be explained in one DFD. Most process models
are therefore composed of a set of DFDs. The first DFD provides a summary of the overall
system, with additional DFDs providing more and more detail about each part of the overall
business process. Thus, one important principle in process modelling with DFDs is the
decomposition of the business process into a hierarchy of DFDs, with each level down the
hierarchy representing less scope but more detail. Figure 6.4 shows how one business process
can be decomposed into several levels of DFDs.
140
CONTEXT DIAGRAM
0
X Z
Information Entity B
Entity A
System
LEVEL 0 DFD
1
X Entity B
Entity A
Process T
Z
Y B
2 3
M
D1 Data Store N Process U Process V
A
N
141
LEVEL 1 DFD
for Process 2 2.1
B J
Process D
K H
2.2 2.3
G A
M Process E Process F
D1 Data Store N
N C Y
LEVEL 2 DFD
for Process 2.2 2.2.1
K G
Process K
2.2.2
H
Process L
2.2.3
N C
Process M
D1 Data Store
N
M
Figure 6.4: Relationships among levels of Data Flow Diagrams (DFDs)
7.2.1. Decomposition of DFDs

A decomposition diagram or hierarchy chart shows the top-down, functional decomposition
of a system. It also shows numbering scheme.
7.2.2 Functional decomposition

Functional decomposition is a repetitive process of breaking the description or perspective of
a system down into finer and finer detail. This process creates a set of hierarchically related
charts in which one process on a given chart is explained in greater detail on another chart.
The lowest level is called a primitive DFD
142
7.2.3 Level-N Diagrams
A DFD that is the result of n nested decompositions of a series of sub-processes from a
process on a level-0 diagram.
7.2.4 Context Diagram

Context diagram is a data flow diagram (DFD) of the scope of an organizational system that
shows the system boundaries, external entities that interact with the system and the major
information flows between the entities and the system. It is a top-level view of an information
system. The context diagram is the highest level DFD, and it consists of one and only one
process, and absolutely zero data stores. It gives a very high level view of the system.
A context diagram is followed by a level 0 diagram, then a level 1 diagram, and so forth. The
lowest level DFD is known as a ―primitive‖ data flow diagram.
A context diagram shows:

i. The context into which the business process fits
ii. The overall business process as just one process
iii. All the outside entities that receive information from or contribute information to the
system.
External
To draw a context diagram, you start by placing a single process symbol in the centre of the
page. The symbol represents the entire information system, and you identify it as process 0.
You do not need to show any data stores in a context diagram because data stores are internal
to the system. You begin by reviewing the system requirements to identify all external data
sources and destinations.
143
ORDER
WAREHOUS E
CUSTOMER PICKING
LIST
ORDER
REJECT
NOTICE
INVOICE
0 COMPLETED
ORDER
PAYMENT
ORDER
SYSTEM
CASH
RECEIPTS
BANK ENTRY
COMMISSION
DEPOSIT
ACCOUNTING
SALES REP BANK
FINAL SUBMITTED
STUDENT
GRADE WORK
RECORDS STUDENT
SYSTEM
Figure 6.5: Context Diagram DFD for an Order System
CLASS 0 GRADED
ROSTER WORK
GRADING
SYSTEM
GRADING GRADE
PARAMETERS REPORT
INSTRUCTOR
Figure 6.6: Context Diagram DFD for a Grading System
144
o --------------------- is a repetitive process of breaking the description or perspective of a
system down into finer and finer detail.
 Functional decomposition
7.2.5 Rules for Stopping Decomposition

i. When each process has been reduced to a single decision, calculation or a single database
operation, such as retrieve, update, create, delete, or read.
ii. When each data store represents data about a single entity such as a student, a product, an
employee, or a customer etc.
iii. When the system user does not care to see any more detail, or when you and other
analysts have documented sufficient detail to do subsequent systems development tasks.
iv. When every data flow does not need to be split further to show that data are handled in
various ways.
v. When you are sure that you have shown each business form or transaction, online display
and report as a single data flow e.g. each system display and report title corresponds to the
name of an individual data flow.
vi. When you are sure that there is a separate process shown for each choice on all lowest-
level menu options.
7.3 Guidelines for Drawing a Context Diagram

When you draw a context diagram, you should follow certain guidelines:
1. Draw the context diagram so it fits on one page.
2. Use the name of the information system as the process name in the context diagram.
3. Use unique names within each set of symbols.
4. Do not cross lines.
5. Provide a unique name and reference number for each process. The context diagram
contains process 0, the next level of detail inside process 0, you must create a DFD named
diagram 0
6. Reviewing models with users allows you to obtain their feedback and approval for the
logical design of the system.
145
Level 0 Diagram
Level 0 diagrams are data flow diagrams (DFD) that represent a system‘s major processes,
data flows and data stores at a higher level. The purpose of the level 0 DFD is to show all the
major high-level processes of the system and how they are interrelated. All process models
have one and only one level 0 DFD.
Level 0 diagrams show:

i. All the processes that comprise the overall system
ii. How information moves from and to each process and
iii. Adds data stores
A key principle in creating sets of DFDs is balancing. Balancing means ensuring that all
information presented in a DFD at one level is accurately represented in the next-level DFD.
This doesn‘t mean that the information is identical, but that it is shown appropriately
Level 1 Diagrams
i. All the processes that comprise a single process on the level 0 diagram
ii. How information moves from and to each of these processes
iii. Shows in more detail the content of higher level process
Level 1 diagram may not be needed for all level 0 processes.
Level 2 Diagrams
i. All processes that comprise a single process on the level 1 diagram
ii. How information moves from and to each of these processes
Level 2 diagrams may not be needed for all level 1 processes
Numbering each process correctly helps the user understand where the process fits into the
overall system.

o Balancing does not mean that all information presented in a DFD at one level is
accurately represented in the next-level DFD. True/False
 False
146
7.3.1 Diverging and Converging Data Flows
A diverging data flow is one that splits into multiple data flows. It is useful for illustrating
data that starts out naturally as one flow, but needs to be routed to parallel processes.
It is also useful for illustrating multiple copies of the same output going to different
destinations.
A converging data flow on the other hand is the merger of multiple data flows into a single
packet. A converging data flow is useful for illustrating data from multiple sources that must
come back together for some subsequent processing
7.3.2 Alternative Data Flows

Where a process can produce different data given different conditions, we show both data
flows and use the process description to explain why they are alternatives.
It should be noted that alternative data flows often accompany processes with IF statements.
Rules for the various Elements / Symbols of DFD
Rules for Process

i. No process can have only outputs (a miracle)
ii. No process can have only inputs (black hole)
iii. A process has a verb phrase label
Rules for Data Store

i. Data cannot be moved from one store to another
ii. Data cannot move from an outside source to a data store
iii. Data cannot move directly from a data store to a data sink.
iv. Data store has a noun phrase label
Rules for Source / Sink

i. Data cannot move directly from a source to a sink
ii. A source / sink has a noun phrase label
Rules for Data Flow

i. A data flow has only one direction of flow between symbols
147
ii. A fork means that exactly the same data go from a common location to two or more
processes, data stores or sources/sinks.
iii. A join means that exactly the same data come from any two or more different processes,
data stores or sources / sinks to a common location
iv. A data flow cannot go directly back to the same process it leaves
v. A data flow to a data store means update
vi. A data flow from a data store means retrieve or use
vii. A data flow has a noun phrase label
7.3.3 Balancing DFDs

When decomposing a DFD, you must conserve inputs to and outputs from a process at the
next level of decomposition. In other words, Process 1.0, which appears in a level-0 diagram,
must have the same inputs and outputs when decomposed into a level-1 diagram this
conversation of inputs and outputs is called balancing. We can split a data flow into separate
data flows on a lower level diagram.
Let‘s look at an example of balancing a set of DFDs. Figure 6.7, the context diagram for
Temi‘s food-ordering system, shows one input to the system, the customer order, which
originates with the customer. Note that the diagram shows three outputs: the customer
receipt, the food order intended for the kitchen, and management reports. Now look at Figure
6.7, the level 0 diagram for the food-ordering system. Remember that all data stores and
flows to or from them are internal to the system. It can be seen that the same single input to
the system and the same three outputs represented in the context diagram also appear at level
0. Also, no new inputs to or outputs from the system have been introduced. Therefore, we can
say that the context diagram and level 0 DFDs are balanced.
148
CUSTOMER
KITCHEN
Food Ordering
Receipts Food Order
System
Management Reports
RESTAURANT
MANAGER
Figure 6.7: Context Diagram of Temi‘s Food Ordering System
149
Receipt Food Order
1.0 KITCHEN
CUSTOMER
Customer Receive and

Order Transform
Customer Food
Goods Sold Data Orders
3.0
2.0 Inventory Data Update
Inventory
Update Goods File
Sold File
Formatted Inventory Data

Formatted Goods Sold Data Daily Inventory
Daily Goods Depletion Amounts
Sold Amounts D1 Inventory File
D2 Goods Sold File
4.0
Produce
Management
Report
Management Reports
RESTAURANT
MANAGER
Figure 6.8: Four Separate Processes of the Temi‘s Food Ordering System
150
Four Additional Advanced Rules Due to Balancing DFDs
1. A composite data flow on one level can be split into component data flows at the next
level, but no new data can be added and all data in the composite must be accounted for in
one or more sub-flows.
2. The input to a process must be sufficient to produce the outputs (including data placed in
data stores) from the process. Thus all outputs can be produced, and all data in inputs move
somewhere, either to another process or to a data store outside the process or on a more
detailed DFD showing a decomposition of that process.
3. At the lowest level of DFDs, new data flows can be added to represent data that are
transmitted under exceptional conditions; these data flows typically represent error messages
or confirmation notices.
4. To avoid having data flow lines cross each other, you may repeat data store, source/sink on
a DFD. Use an additional symbol, like a double line on the middle vertical line of a data store
symbol, or a diagonal line of a sink/source square, to indicate repeated symbol.
7.3.4 General Guidelines for Drawing DFD

In this section, we consider additional guidelines for drawing DFDs that extend beyond the
simple rules for each of the elements of the DFD and these guidelines will ensure that all the
rules listed above in sections 6.9, 6.10, 6.13 and 6.14 are followed. These general guidelines
include:
1. Completeness
2. Consistency
3. Timing considerations
4. The iterative nature of drawing DFDs
5. Drawing primitive DFDs
Completeness: The concept of DFD completeness refers to whether your DFDs include all
of the components necessary for the system you are modelling.
If your DFD contains data flows that do not lead anywhere, or data stores, processes, or
external entities that are not connected to anything else, your DFD is not complete. Most
CASE tools have built-in facilities to help find incompleteness in your DFDs. When you
draw many DFDs for a system, it is not uncommon to make errors; either CASE-tool analysis
functions or walkthroughs with other analysts can help you identify such problems.
151
Not only must all necessary elements of a DFD be present, each of the components must be
fully described in the project dictionary. For most CASE tools, when you define a process,
data flow, source/sink, or data store on a DFD, an entry is automatically created in the tool‘s
repository for that element. You must then enter the repository and complete the element‘s
description. Different descriptive information can be kept about each of the four types of
elements on a DFD, and each CASE tool has different entry information. A data-flow
repository entry includes:
 The label or name for the data flow as entered on DFDs
 A short description defining the data flow
 A list of other repository objects grouped into categories by type of object
 The composition or list of data elements contained in the data flow
 Notes supplementing the limited space for the description that go beyond defining the
data flow to explaining the context and nature of this repository object
 A list of locations (the names of the DFDs) on which this data flow appears and the
names of the sources and destinations for the data flow on each of these DFDs.
Consistency: The concept of DFD consistency refers to whether the depiction of the system
shown at one level of a DFD is compatible with the depictions of the system shown at other
levels. A gross violation of consistency would be a level-1 diagram with no level-0 diagram.
Another example of inconsistency would be a data flow that appears on a higher-level DFD
but not on lower levels (a violation of balancing). Yet, another example is a data flow
attached to one object on a lower-level diagram but attached to another object at a higher
level. For example, a data flow named Payment, which serves as input to Process 1 on a
level-0 DFD, appears as input to Process 2.1 on alevel-1 diagram for Process 2.
You can use the analysis facilities of CASE tools to detect such inconsistencies across nested
(or decomposed) data-flow diagrams. For example, to avoid making DFD consistency errors
when you draw a DFD using a CASE tool, most tools will automatically place the inflows
and outflows of a process on the DFD you create when you inform the tool to decompose that
process. In manipulating the lower-level diagram, you could accidentally delete or change a
data flow, which would cause the diagrams to be out of balance; thus, a consistency check
facility with a CASE tool is quite helpful.
152
Timing: You may have noticed in some of the DFD examples we have presented that DFDs
do not do a good job of representing time. A given DFD provides no indication of whether a
data flow occurs constantly in real time, once per week, or once per month. No indication of
when a system would run is given either. For example, many large transaction-based systems
may run several large, computing-intensive jobs in batch mode at night, when demands on
the computer system are lighter. A DFD has no way of indicating such overnight batch
processing. When you draw DFDs, then, draw them as if the system you are modelling has
never started and will never stop.
Iterative Development: The first DFD you draw will rarely perfectly capture the system you
are modelling. You should count on drawing the same diagram over and over again, in an
iterative fashion. With each attempt, you will come closer to a good approximation of the
system or aspect of the system you are modelling. Iterative DFD development recognizes that
requirements determination and requirements structuring are interacting, not sequential, sub-
phases of the analysis phase of the SDLC. One rule of thumb is that it should take you about
three revisions for each DFD you draw. Fortunately, CASE tools make revising drawings a
lot easier than if you had to draw each revision with pencil and template.
Primitive DFDs: One of the more difficult decisions you need to make when drawing DFDs
is when to stop decomposing processes. One rule is to stop drawing when you have reached
the lowest logical level; however, it is not always easy to know what the lowest logical level
is. Other more concrete rules for when to stop decomposing are as stated in section 6.9
By the time you stop decomposing DFDs, a DFD can become quite detailed. Seemingly
simple actions, such as generating an invoice, may pull information from several entities and
may also return different results depending on the specific situation. For example, the final
form of an invoice may be based on the type of customer (which would determine such things
as discount rate), where the customer lives (which would determine such things as sales tax),
and how the goods are shipped (which would determine such things as the shipping and
handling charges). At the lowest-level DFD, called a primitive DFD, all of these conditions
would have to be met. Given the amount of detail required in a primitive DFD, perhaps you
can see why many experts believe analysts should not spend their time diagramming the
current physical information system completely: much of the detail will be discarded when
the current logical DFD is created.
153
Using these guidelines will help you create DFDs that are more than just mechanically
correct. Your data-flow diagrams will also be robust and accurate representations of the
information system you are modelling. Such primitive DFDs also facilitate consistency
checks with the documentation produced from other requirements structuring techniques, as
well as make it easy for you to transition to system design steps. Having mastered the skills
of drawing good DFDs, you can now use them to support the analysis process.

o All of the following are general guidelines for drawing DFD. True/False
a. Completeness
b. Consistency
c. Timing considerations
d. The iterative nature of drawing DFDs
e. Drawing primitive DFDs
 True
7.4 Validating the Data Flow Diagrams

Once you have created a set of DFDs, it is important to check them for quality. All the rules
stated above provide a quick checklist for identifying the most common errors. There are two
fundamentally different types of problems that can occur in DFDs: syntax errors and
semantics errors. Syntax here, refers to the structure of the DFDs and whether the DFDs
follow the rules of the DFD language. Syntax errors can be thought of as grammatical errors
made by the analyst when he or she creates the DFD. Semantics refers to the meaning of the
DFDs and whether they accurately describe the business process being modelled. Semantics
errors can be thought of as misunderstandings by the analyst in collecting, analyzing, and
reporting information about the system.
In general, syntax errors are easier to find and fix than are semantics errors, because there are
clear rules that can be used to identify them (e.g., a process must have a name). Most CASE
tools have syntax checkers that will detect errors within one page of a DFD in much the same
way that word processors have spelling checkers and grammar checkers. Finding syntax
errors that span several pages of a DFD (e.g., from a level 1 to a level 2 DFD) is slightly
more challenging, particularly for consistent viewpoint, decomposition, and balance. Some
CASE tools can detect balance errors, but that is about all. In most cases, analysts must
154
carefully and painstakingly review every process, external entity, data flow, and data store on
all DFDs by hand to make sure that they have a consistent viewpoint and that the
decomposition and balance are appropriate.
7.5. Creating DFDs from Use Cases

DFDs start with the use cases and requirements definition; generally, the DFDs integrate the
use cases. Names of use cases become processes, inputs and outputs become data flow;
―small‖ data inputs and outputs are combined into a single flow.
Steps in Building DFDs

i. Build the context diagram
ii. Create DFD fragments for each use case
iii. Organize DFD fragments into level 0 diagram
iv. Decompose level 0 processes into level 1 diagrams as needed; decompose level 1
processes into level 2 diagrams as needed; etc.
v. Validate DFDs with user to ensure completeness and correctness
Build the Context Diagram

i. Draw one process representing the entire system (process 0)
ii. Find all inputs and outputs listed at the top of the use cases that come from or go to
external entities; draw as data flows
iii. Draw in external entities as the source or destination of the data flows
Creating DFD Fragments

i. Each use case is converted into one DFD fragment
ii. Number the process the same as the use case number
iii. Change process name into verb phrase
iv. Design the processes from the viewpoint of the organization running the system
v. Add data flows to show use to data stores as sources and destinations of data
vi. Layouts typically place processes in the centre, inputs from the left, outputs to the right
and stores beneath the processes
155
Creating the Level 0 Diagram
i. Combine the set of DFD fragments into one diagram
ii. Generally move from top to bottom, left to right
iii. Minimize crossed lines
iv. Iterate as needed. DFDs are often drawn many times before being finished, even with very
experienced systems analysts.
Creating Level 1 Diagrams (and Below)

i. Each use case is turned into its own DFD
ii. Take the steps listed on the use case and depict each as a process on the level 1 DFD
iii. Inputs and outputs listed on use case become data flows on DFD
iv. Include sources and destinations of data flows to processes and stores within the DFD
v. It may also include external entities for clarity
vi. Input data flows shown on a parent DFD are often unbundled on the child diagram using
splits
vii. Output data flows shown on a child DFD are often bundled using joins and shown as a
larger data flow on the parent diagram
viii. When to stop decomposing DFDs? Ideally, a DFD has at least 3 processes and no more
than 7-9.

o Which of the following options is NOT a Step in Building DFDs?
A) Build the context diagram
B) Create DFD fragments for each use case
C) Organize DFD fragments into level 0 diagram
D) Decompose level 0 processes into level 1 diagrams as needed; decompose level 1
processes into level 2 diagrams as needed; etc.
F) Validate DFDs with user to ensure completeness and correctness
G) None of the above
 G- None of the options
156
In the next study session, we review data modelling and discuss how the data that flow
through the processes are organized and presented in business organisation.
Activity 7.1 Guideline for drawing Data flow diagram

you should be a to draw a data flow diagram, note down some of the steps involves in
drawing data flow diagram and how business process can be decomposed into DFDs?

Data flow diagram (DFD) is graphical diagrams for specifying, constructing and visualizing
the model of a system. Business process is decomposed into DFD levels.
Take a look at figure 6.4; it describes the various patterns of relationships among levels of
Data Flow Diagrams (DFDs) and how one business process can be decomposed into several
levels of DFDs
CONTEXT DIAGRAM
0
X Z
Information Entity B
Entity A
System
LEVEL 0 DFD
1
X Entity B
Entity A
Process T
Z
Y B
2 3
M
D1 Data Store N Process U Process V
A
N
157
LEVEL 1 DFD
for Process 2
2.1
B J
Process D
K H
2.2 2.3
G A
M Process E
D1 Data Store N Process F
C Y
N
LEVEL 2 DFD
for Process 2.2 2.2.1
K G
Process K
2.2.2
H
Process L
2.2.3
N C
Process M
D1 Data Store
N
M
Figure 6.4: Relationships among levels of Data Flow Diagrams (DFDs)
 For us to meaningfully learn about modelling and analysis of information system

there is a need to understand some elements of DFD and DFD validation, in other
words the elements DFD are highlighted in Box 7.1
158
Box 7.1: DFD elements and validation
The elements of data flow diagrams include i Data Flows & Control Flows; ii. Data
Store; iii. Source / Sink External Agents /Entities/ iv. Process Concept
A data flow represents an input of data to a process, or the output of data from a
process.
 A composite data flow is a data flow that consists of other data flows.
 A data store is an inventory of data which one or more processes need to use at
a later time.
 A decomposition diagram or hierarchy chart shows the top-down, functional
decomposition of a system
 Context diagram is a data flow diagram (DFD) of the scope of an
organizational system that shows the system boundaries, external entities that
interact with the system and the major information flows between the entities
and the system.
 These general guidelines for drawing DFD include:
1. Completeness
2. Consistency
There are two fundamentally different types of problems that can occur in DFDs:
these are syntax errors and semantics errors.

1 The elements of data flow diagrams include
i Data Flows & Control Flows
ii. Data Store
iii. Source / Sink External Agents /Entities/
2 A decomposition diagram or hierarchy chart shows the top-down, functional
decomposition of a system.
3 A data flow diagram (DFD) illustrates the movement of data between the external
entities, the processes and data stored within an information system, without showing
program logic or processing steps.
159
4 These general guidelines for drawing DFD include:
1. Completeness
2. Consistency

SAQ 7.1 ((tests learning outcome 7.1)

Can you highlight the elements of data flow diagrams?
Can you describe the decomposition of DFDs?
Can you list the guidelines for drawing a context diagram?
Can you explain how to validate DFDs?
SAQ 7.5 (tests learning outcome 7.3&7.5)
Can you differentiate Use-Case Diagrams from Data Flow Diagrams in modelling an
Information System?

SAQ 7.1: The elements of data flow diagrams include
i Data Flows & Control Flows
ii. Data Store
iii. Source / Sink External Agents /Entities/
SAQ 7.2: A decomposition diagram or hierarchy chart shows the top-down, functional
decomposition of a system. It also shows numbering scheme.
SAQ 7.3. The guidelines for drawing a context diagram are:
1 Draw the context diagram to fits on one page.
2.Use the name of the information system as the process name in the context diagram.
160
3. Use unique names within each set of symbols.
4. Do not cross lines.
5. Provide a unique name and reference number for each process. The context
diagram contains process 0, the next level of detail inside process 0, you must create a
DFD named diagram 0
6. Reviewing models with users allows you to obtain their feedback and approval for
the logical design of
SAQ 7.4: You can validate DFDs by comparing them to the quality or violation rules listed
below. The rules for process, data store, source / sink, and data flow are quick
checklists for identifying the most common problems.
SAQ 7.5: Use-case diagram is a part of the Unified Modelling Language (UML) that are used
to explain and document the interaction that is required between the user and the
system to accomplish the user‘s task, while a data flow diagram (DFD) illustrates the
movement of data between the external entities, the processes and data stored within
an information system, without showing program logic or processing steps.
References
Denise D., and Dr. Ken L. (n.d.): Analysis and Design for Process Support Systems using
Goal oriented Business Process Modelling. School of Computing & Mathematics, University
of Huddersfield, England
Hassan G., and Erika Mir O. (n.d.): The Role of Use Cases in Requirements and Analysis
Modelling. Department of Information and Software Engineering, George Mason University,
Fairfax, VA
Professor Yong Tan (n.d.): Lecture 11: Process Modelling. IS 460 Notes
Rosziati I., and Siow Y. Y. (2010): Formalization of the Data Flow Diagram Rules for
Consistency Check. International Journal of Software Engineering & Applications (IJSEA),
Vol.1, No.4.
William Y. Arms (n.d.): CS 5150 Software Engineering: Requirements Analysis. Cornell
University of Computing and Information Science
161
Study Session 8: Data Modelling--I
Introduction
You learnt about the analysis phase in prior sessions, and you know that analysts construct
process models to reflect how the business system would operate. Simultaneously, you
discovered that analysts must comprehend the information used and generated by the
business system. This session will teach you more, particularly about data modelling. Data
modelling is most likely one of the most time-consuming and labour-intensive aspects of the
system development process. The data model's purpose is to ensure that all data items
required by the system are fully and accurately represented.
Our focus here is on creating a logical data model. Although there are several ways to model
data, we will present to you one of the most commonly used techniques: entity relationship
diagramming, a graphic drawing technique developed by Peter Chen that shows all the data
components of a business system.

8.1 Describe data modelling (SAQ 8.1)
8.2 Explain the term entity relationship diagram (ERD) (SAQ 8.2)
8.3 List the three basic elements in the data modelling language (SAQ 8.3)
8.4 Describe metadata (SAQ 8.4)
8.5 State the steps involved in building an entity relationship diagram (SAQ 8.5)
8.1 Data model

A data model describes the data that flow through the business processes in an organization.
During the analysis phase, the data model presents the logical organization of data without
indicating how the data are stored, created, or manipulated so that analysts can focus on the
business without being distracted by technical details.
162
Later, during the design phase, the data model is changed to reflect exactly how the data will
be stored in databases and files. This section describes entity relationship diagramming, one
of the most common data modelling techniques used in industry.
A data model is a formal way of representing the data that are used and created by a business
system; it illustrates people, places, or things about which information is captured and how
they are related to each other. The data model is drawn by an iterative process in which the
model becomes more detailed and less conceptual over time. During analysis, analysts draw a
logical data model, which shows the logical organization of data without indicating how data
are stored, created, or manipulated. Because this model is free of any implementation or
technical details, the analysts can focus more easily on matching the diagram to the real
business requirements of the system.
Data modelling is seen by many system developers as the most important aspect of
information system requirements statement. This view is due to the following reasons:
i. The characteristics of data captured during data modelling are crucial in the design of
databases, programs, computer screens, and printed reports.
ii. Data rather than processes are the most complex aspects of many modern information
systems.
iii. The characteristics about data e.g. format and relationships with other data are rather
permanent. Unlike what we have in process modelling- who receives which data, the format
of reports, and what reports are used- all these change constantly over time.
iv. Structural information about data is essential to generate programs automatically.
In the design phase, analysts draw a physical data model to reflect how the data will
physically be stored in databases and files. At this point, the analysts investigate ways to store
the data efficiently and to make the data easy to retrieve.
Project teams usually use CASE tools to draw data models. Some of the CASE tools are data
modelling packages, such as ERwin by Platinum Technology, that help analysts create and
maintain logical and physical data models; they have a wide array of capabilities to aid
modellers, and they can automatically generate many different kinds of databases from the
models that are created. Other CASE tools are Oracle Designer and Visible Analyst
Workbench, in which data modelling is one of many capabilities, and the tool can be used
163
with many different databases. A benefit of the full-service CASE tool is that it integrates the
data model information with other relevant parts of the project.

o ----------- is a formal way of representing the data that are used and created by a
business system.
 Data model
Now that you are able to explain data model, let us learn an entity relationship diagram
(ERD) which is a conceptual model used by a business system.
8.2.1 The Entity Relationship Diagram

An entity relationship diagram (ERD) is a conceptual model which shows the information
that is created, stored, and used by a business system. An analyst can read an ERD to
discover the individual pieces of information in a system and how they are organized and
related to each other. On an ERD, similar kinds of information are listed together and placed
inside boxes called entities. Lines are drawn between entities to represent relationships
among the data, and special symbols are added to the diagram to communicate high-level
business rules that need to be supported by the system. The ERD implies no order, although
entities that are related to each other are usually placed close together.
For example, let us consider a Transcript Request System. This information system is used to
carry out academic transcript issuing process in the records unit of the computing centre of a
University. We will use it for our discussion on how to read an entity relationship diagram.
The DFD for the transcript request process is shown in Figure7.1*. Although we can
understand how the system works simply by studying the data flow diagram, however, we
can only have little understanding of the detailed information that flows through the system.
For instance, what exactly is a ―New transcript request‖? What pieces of data are captured in
a ―Transcript collection authorization‖?
164
Supply matricNo, Course,
Name, Year of
D1 Student‘s Departmental
Admission&Graduation, and Records
Grade to indicate request for 2.1
transcript
Returns processed transcript

Verifies the
request forms to the Records
identity of office
the applicant
Issues mini-transcript 2.4

request form to the
applicant
2.2 Processes
transcript
Submits photocopies forms from
of credentials Verifies Records
credentials office
Issues ‗Authority to
Pay‘
2.5
2.3
Submission of
photocopy of Receipt Confirmed Package the
Applicant of Confirms
the transcript request Transcript
request and
Transcript for delivery
processes the
transcript
New transcript requests Transcript

collection notice
D2 Transcript Request
Database of
Collected
Transcript collection authorization or Notice
Transcript
of transfer/delivery
Figure 7.1*: DFD for Transcript Request Process
8.2.2 Reading an Entity Relationship Diagram

The analyst can answer these questions and more by using an entity relationship diagram. We
have included a partial ERD for the transcript request scenario in Figure 7.1. First, we have
organized the data into three main categories: Transcript Applicant, Transcript Request, and
Transcript. The Transcript
165
Applicant data describe the graduates who is requesting for his academic transcript. The
Transcript Request data capture information about every transcript request event, and the
Transcript data describe the transcripts used for postgraduate admission processes by
graduates.
We can also see the specific facts that describe each of the three categories.
For example, a transcript is described by its ID number, name, description, and approval
status. We can also see what can be used to uniquely identify a transcript, a transcript request,
and a transcript applicant, by looking for the asterisks next to the data elements. A unique ID
has been created to identify every transcript applicant and every transcript. A transcript
request is uniquely identified by a combination of the transcript applicant ID, the transcript
ID, and the request date.
The lines connecting the three categories of information communicate the relationships that
the categories share. By reading the relationship lines, the analyst understands that a
transcript applicant (TA) makes transcript requests and transcript requests involve transcripts.
TRANSCRIPT APPLICANT TRANSCRIPT REQ UEST TRANSCRIPT

makes involves
*T A_ID *T A_ID *T RN_ID
T A_Name *T RN_ID T RN_Name
T A_PhoneNumber is made by *RequestDate involved in T RN_Description
T A_Address DeliveryMode T RN_ApprovalStatus
Figure 7.1: Transcript Request ERD
The ERD also communicates high-level business rules. Business rules are constraints or
guidelines that are followed during the operation of the system; they are rules such as ―A
payment can be cash, cheque, debit card, or credit card,‖ ―A sale is paid for by one or more
payments,‖ or ―A customer may place many orders.‖ Over the course of a workday, people
are constantly applying business rules to do their jobs, and they know the rules through
training or knowing where to look them up. If a situation arises where the rules are not
known, workers may have to refer to a policy guide or written procedure to determine the
proper business rules.
On a data model, business rules are communicated by the kinds of relationships that the
entities share. From the ERD, for example, we know from the ―crow‘s foot‖ placed on the
line closest to the Transcript Request that a TA may make many Transcript Requests. We can
see by the two bars placed on the line closest to the TA that a Transcript Request is made by
166
exactly one TA. Ultimately, the new system should support the business rules we just
described, and it should ensure that users don‘t violate the rules when performing the
processes of the system.
Therefore, in our example, the system should not permit a transcript request to be made that
does not involve a TA (i.e. application by proxy is not allowed). Similarly, the system should
not allow a transcript request to involve more than one TA.
Now that we‘ve seen an ERD, let‘s step back and learn the ERD basics and then describe the
syntax of the ERD, using the diagram in Figure 7.1

o Can you explain what ERD do?
 ERD communicates high-level business rules. Business rules are constraints or
guidelines that are followed during the operation of the system
8.3 Elements of an Entity Relationship Diagram

There are three basic elements in the data modelling language (entities, attributes, and
relationships), each of which is represented by a different graphic symbol.
There are many different sets of symbols that can be used on an ERD. No one set of symbols
dominates industry use, and none is necessarily better than another. Figure 7.2 summarizes
the three basic elements of ERDs and the symbols often used.
Entity: The entity is the basic building block for a data model. It is a person, place, event, or
thing about which data is collected—for example, an employee, an order, or a product. An
entity is depicted by a rectangle, and it is described by a singular noun spelt in capital letters.
All entities have a name, a short description that explains what they are, and an identifier that
is the way to locate information in the entity. In Figure 7.1, the entities are Transcript
Applicant, Transcript Request, and Transcript.
Entities represent something for which there exist multiple instances, or occurrences. For
example, in figure 7.3, Adekunle Olajide and Idowu Ige could be instances of the student
entity. We would expect the student entity to stand for all of the people whom we have
admission and have completed their registration processes, and each of them would be an
instance in the student entity. If there is just one instance, or occurrence, of a person, place,
event, or thing, then it should not be included as an entity in the data model. For example,
167
think a little more broadly about the transcript request information system. Figure 7.1 focuses
on just a small part of that information system.
We assumed that the computing centre of the institution receives more than one Transcript
Applicant, because we included a TA entity to capture specific facts about each.
Attribute: An attribute is some type of information that is captured about an entity.

For example, last name, home address, and telephone number are all attributes of a student.
It is easy to come up with hundreds of attributes for an entity (e.g., a student has a height, a
weight, a favourite food, a religious affiliation, etc), but only those that actually will be used
by the academic business process should be included in the model.
Attributes are nouns that are listed within an entity. Usually, some form of the entity name is
appended to the beginning of each attribute to make it clear as to what entity the attribute
belongs (e.g., STUD_lastName, STUD_phoneNumber). Without doing this, you can get
confused by multiple entities that have the same attributes, e.g., a student and an employee in
the institution both can have an attribute called ―lastName.‖
STUD_lastName and STUD_lastName are much clearer ways to name attributes on the data
model.
One or more attributes can serve as the identifier i.e. the attribute(s) that can uniquely identify
one instance of an entity; the attributes that serve as the identifier are noted by an asterisk
next to the attribute name. If there are no students with the same last name, then last name
can be used as the identifier of the student entity. In this case, if we need to locate Idowu Ige,
the name Ige would be sufficient to identify the one instance of the Ige last name.
Suppose that we add a student named Temitope Ige. Now we have a problem: Using the
name Ige would not uniquely lead to one instance—it would lead to two (i.e., Idowu Ige and
Temitope Ige). You have three choices at this point, and all are acceptable solutions. First,
you can use a combination of multiple fields to serve as the identifier (last name and first
name). This is called a concatenated identifier because several fields are combined, or
concatenated, to uniquely identify an instance. Second, you can find a field that is unique for
each instance, like the student telephone number. Third, you can wait to assign an identifier
(like a randomly generated number that the system will create) until the design phase of the
SDLC; this is shown in figure 7.4 Many data modellers don‘t believe that randomly
generated identifiers belong on a logical data model, because they do not logically exist in the
business process.
168
IDEF1X Chen Crow‘s Foot
An ENTITY ENTITY-NAM E ENTITY-NAM E

i. is a person, place, or thing. Attribute-name
Attribute-name Attribute-
ii. has a singular name spelt in all capital Attribute-name name Attribute-name
letters.
Attribute-name Attribute-name
iii. has an identifier.
iv. should contain more than one instance
of data.
An ATTRIBUTE ENTITY-NAM E ENTITY-NAM E
ENTITY-NAM E
i. is a property of an entity. Identifier *Identifier
ii. should be used by at least one business
process.
iii. is broken down to its most useful level
of detail.
ARELATIONSHIP
i. shows the association between two
entities.
Relationship-name Relatio Relationship-name
ii. has a parent entity and a child entity. nship-
name
iii. is described with a verb phrase.
iv. has cardinality (1:1, 1:N, or M:N).
v. has modality (null, not null).
vi. Figure 7.2:orSymbols
is dependent for
independent. Data Modelling
Relationship: Relationships are associations between entities, and they are shown by lines
that connect the entities together. Every relationship has a parent entity and a child entity, the
parent being the first entity in the relationship, and the child being the second.
Relationships should be clearly labelled with active verbs so that the connections between
entities can be understood. If one verb is given to each relationship, it is read in two
directions. For example, we could write the verb makes alongside the relationship for the TA
and Transcript Request entities, and this would be read as ―a TA makes a transcript request‖
and ―a transcript request is made by a TA.‖
In Figure 7.1, we have included words for both directions of the relationship line; the top
words are read from parent to child, and the bottom words are read from child to parent.
Notice that the TA entity is the parent entity in the TA-Transcript Request relationship. In
addition, some CASE tools require that every relationship name be unique on the ERD, so we
select unique descriptive verbs for each relationship.
169
Entity Example Instances
Adekunle Olajide
Student Idowu Ige
Chinyere Odiah
Danjuma Duru
Kelechi Samson
Figure 7.3: Entity and Instances
Concatenated Single Identifier Identifier to Be

Identifier Added Later
STUDENT STUDENT STUDENT
*STUD_lastName *STUD_phoneNumber STUD_lastName

*STUD_firstName STUD_lastName STUD_firstName
STUD_firstName
Figure 7.4: Choices for Identifiers
Cardinality: Relationships have two properties. First, a relationship has cardinality, which is
the ratio of parent instances to child instances. To determine the cardinality for a relationship,
we ask ourselves: ―How many instances of one entity are associated with an instance of the
other?‖ (Remember that an instance is one occurrence of an entity, such as TA Idowu Ige or
Transcript 001.) For example, a TA makes how many transcript requests? The cardinality for
binary relationships (i.e., relationships between two entities) is 1:1, 1:N, or M:N, and we will
discuss each in turn.
The 1:1 (read as ―one to one‖) relationship means that one instance of the parent entity is
associated with one instance of the child entity. There are no examples of 1:1 relationships in
Figure 7.1. So, imagine for a moment that, as a reward, a bank branch assigns a specific
reserved parking place to every employee who is honoured as an ―employee of the month.‖
One reserved parking place is assigned to each honoured employee, and each honoured
employee is assigned one reserved parking place. If we were to draw these two entities, we
170
would place a bar next to the Employee entity and a bar next to the Reserved Parking Place
entity. The cardinality is clearly 1:1 in this case, because each honoured employee is assigned
exactly one reserved parking place, and a reserved parking place is assigned to exactly one
employee.
More often, relationships are 1:N (read as ―one to many‖). In this kind of relationship, a
single instance of a parent entity is associated with many instances of a child entity; however,
the child entity instance is related to only one instance of the parent. For example, a TA
(parent entity) can make many Transcript Requests (child entity), but a particular Transcript
Request is made by only one TA, suggesting a 1:N relationship between TA and Transcript
Request. A character resembling a crow‘s foot is placed closest to the Transcript Request
entity to show the ―many‖ end of the relationship. The parent entity is always on the ―1‖ side
of the relationship; hence, a bar is placed next to the TA entity. Can you identify other 1:N
relationships in Figure 7.1? Identify the parent and child entities for each relationship.
A third kind of relationship is the M:N (read as ―many to many‖) relationship.

In this case, many instances of a parent entity can relate to many instances of a child entity.
There are no M:N relationships shown in figure 7.1, but take a look at figure 7.5. This figure
shows an early draft version of the Transcript Request ERD.
In this version, an M:N relationship does exist between TA and Transcript. As we can see,
one TA (parent entity) can request many Transcripts (e.g., Transcript001, Transcript002), and
a Transcript (child entity) can be requested by many TAs. M:N relationships are depicted on
an ERD by having crow‘s feet at both ends of the relationship line. As we will learn later,
there are advantages to eliminating M:N relationships from an ERD, so that is why it was
removed from figure 7.1 by creating the Transcript Request entity between TA and
Transcript. The process of ―resolving‖ an M:N relationship will be explained later.
TRANSCRIPT APPLICANT TRANSCRIPT
requests
*T A_ID *T RN_ID
T A_Name T RN_Name
T A_PhoneNumber T RN_Description
is requested by
T A_Address T RN_ApprovalStatus
Figure 7.5: M:N Relationship
171
Modality: Second, relationships have a modality of null or not null, which refers to whether
or not an instance of a child entity can exist without a related instance in the parent entity.
Basically, the modality of a relationship indicates whether the child-entity instance is
required to participate in the relationship. It forces you to ask questions such as; can you have
a Transcript Request without a Transcript? And can you have a Transcript without a
Transcript Request? Modality is depicted by placing a zero on the relationship line next to the
parent entity if nulls are allowed. A bar is placed on the relationship line next to the parent
entity if nulls are not allowed. In the two questions we just asked, the first answer is no: you
need a transcript to have a transcript request. You can, however, have a transcript without
having a transcript request for that transcript. The modality is ―not null,‖ or ―required,‖ for
the first relationship in figure7.1. Notice, however, that a zero has been placed on the
relationship line between Transcript and Transcript Request next to the Transcript Request
entity. This means that transcripts can exist in our system without requiring that a transcript
request exists. Said another way, instances of transcript requests are optional for a transcript.
The modality is ―null.‖

o ---------- is a type of information that is captured about an entity
 An attribute
8.4 The Data Dictionary and Metadata

As we described earlier, a CASE tool is used to help build entity relationship diagrams. Every
CASE tool has something called a data dictionary, which is where the analyst goes to define
or look up information about the entities, attributes, and relationships on the ERD. Visio
2010, primarily known as a drawing tool, even has some elementary data dictionary
capabilities.
The information that is captured in the data dictionary is called metadata, which simply
means data about data. Metadata is anything that describes an entity, attribute, or relationship,
such as entity names, attribute descriptions, and relationship cardinality, and it is captured to
help designers better understand the system that they are building and to help users better
understand the system that they will use.
Metadata can describe an ERD element (like entity name) and also information that is helpful
to the project team (like the user contact, the analyst contact, and special notes).
172
Metadata are stored in the data dictionary so that they can be shared and accessed by
developers and users throughout the system development life cycle. The data dictionary
allows you to record the standard pieces of information about your elements in one place, and
it makes that information accessible to many parts of a project. For example, the data
attributes in a data model also appear on the process models as elements of data stores and
data flows, and on the user interface as fields on an input screen. When you make a change in
the data dictionary, the change ripples to the relevant parts of the project that are affected.
When metadata are complete, clear, and shareable, the information can be used to integrate
the different pieces of the analysis phase and ultimately lead to a much better design. It
becomes much more detailed as the project evolves through the system development life
cycle.

o ---------- is the information that is captured in the data dictionary
 Metadata
8.5.1 Creating an Entity Relationship Diagram

Drawing an ERD is an iterative process of trial and revision. It usually takes considerable
practice. ERDs can become quite complex—in fact, there are systems that have ERDs
containing hundreds or thousands of entities.
The basic steps in building an ERD are these:

i. Identify the entities
ii. Add the appropriate attributes to each entity
iii. Draw relationships among entities to show how they are associated with one another.
First, we will describe the three steps in creating ERDs, using the data model example from
figure 7.1. We will then discuss several advanced concepts of ERD‘s.
8.5.2 Building Entity Relationship Diagrams

Step 1: Identify the Entities: As we explained, the most popular way to start an ERD is to
first identify the entities for the model, and their attributes. The entities should represent the
major categories of information that you need to store in your system. If you begin your data
model by using a use case, look at the major inputs to the use case, the major outputs, and the
information used for the use case steps.
173
If the process models (e.g., DFDs) have been prepared, the easiest way to start is with them:
The data stores on the DFDs, the external entities, and the data flows indicate the kinds of
information that are captured and flow through the system.
The Transcript Request plays a key role in our transcript request system example, and so is
included as a data entity. In addition, the Transcript themselves will need to be described with
data, and so will also be included as a data entity. Finally, we will need to capture
information about the transcript applicants (TAs), since these individuals are the key actors in
the system.
Step 2: Add Attributes and Assign Identifiers: The information that describes each entity
becomes its attributes. It is likely that you identified a few attributes if you read the transcript
request system use case (which is expected to be the starting point of the analysis) and paid
attention to the information flows on their DFDs. For example, a TA has a name, a telephone
number and a transcript has an ID and description. On a real project, there are a number of
places you can go to figure out what attributes belong in your entity. For one, you can check
in the CASE tool—often, an analyst will describe a process model data flow in detail when
he or she enters the data flow into the CASE repository. For example, an analyst may create
an entry for the transcript request information data flow which lists all the data elements that
make up the transcript request information. The elements of the data flow should be added to
the ERD as attributes in your entities.
A second approach is to check the requirements definition. Often, there is a section under
functional requirements called data requirements. This section describes the data needs for
the system that were identified while requirements were gathered. A final approach to
identifying attributes is to use requirements gathering techniques. The most effective
techniques would be interviews (e.g., asking people who create and use reports about their
data needs) or document analysis (e.g., examining existing forms, reports, or input screens).
Once the attributes are identified, one or more of them will become the entity‘s identifier.
The identifier must be an attribute(s) that is able to uniquely identify a single instance of the
entity.
Step 3: Identify Relationships: The last step in creating ERDs is to determine how the
entities are related to each other. Lines are drawn between entities that have relationships,
each relationship is labelled, and cardinality and modality is assigned. The easiest approach is
to begin with one entity and determine all the entities with which it shares relationships. In
174
our example in figure 7.1, we can see that a TA makes transcript requests, and a transcript is
included in a transcript request.
When you find a relationship to include on the model, you need to determine its cardinality
and modality. For cardinality, ask how many instances of each entity participate in the
relationship. You know that a TA can make many transcript requests, but a specific transcript
request is made by only one TA. Therefore, we place a crow‘s foot next to the transcript
request entity and a single bar closest to the TA entity. This suggests that there is a 1:N
relationship in which the TA is the parent entity (the ―1‖) and the transcript request is the
child entity (the ―many‖).
Next, we examine the relationship‘s modality. Can a TA exist without an associated

transcript request? In our example, the answer is ―yes,‖ so the modality is ―null‖ or not
required. A zero is placed next to the crow‘s foot near the chemical request. Now, can a
transcript request exist without an associated TA? This answer is ―no,‖ so the modality is
―not null‖: or required, and we place a single bar next to the TA entity
The same approach applies to determining the cardinality and modality of the relationship
between transcript and transcript request. A transcript (the parent) may be included on many
transcript requests (the child), so the relationship is 1:N.
A transcript can exist without a transcript request, so the modality is ―null‖; however, a
transcript request requires the existence of a transcript, so the modality is ―not null.‖
however, a transcript request requires the existence of a transcript, so the modality is ―not
null.‖
Remember that data modelling is an iterative process. Often, the assumptions you make and
the decisions you make change as you learn more about the business requirements and as
changes are made to the use cases and process models. But you have to start somewhere—so
do the best you can with the three steps we just described and keep iterating until you have a
model that works.
175
o List the basic steps in building an ERD
 The basic steps in building an ERD are: i. Identify the entities; ii. Add the
appropriate attributes to each entity; iii. Draw relationships among entities to
show how they are associated with one another.
The Next activity is based on what you learned in this session about data modelling.
Activity 8.1 Building Entity Relationship diagram

Take a moment to reflect on what you have read so far. Based on your learning experience
and knowing that Building Entity Relationship Diagrams requires some steps; can you note
down some of the keys steps?
Activity 8.1 Feedback: Steps in Building Entity Relationship Diagrams is summarised as

follows:
The basic steps in building an ERD are these:
iii. Draw relationships among entities to show how they are associated with one another.
Take a look at figure 7.1; it describes the ERD steps for a transcript request

*T A_ID
makes involves
*T A_ID *T RN_ID
T A_Name *T RN_ID T RN_Name
T A_PhoneNumber is made by *RequestDate involved in T RN_Description
Figure 7.1: Transcript Request ERD
176
 For us to meaningfully learn about data model--1 there is a need to understand some
fundamental steps of concepts of a model. In other words the meaning and concept of
a data modelling are explained in Box 7.1
Box 8.1: Meaning and Concepts of data model

A data model describes the data that flow through the business processes in an
organization.
Data modelling is the most important aspect of information system requirements
statement due to the following reasons:
i. The characteristics of data captured during data modelling are crucial in the design of
databases, programs, computer screens, and printed reports.
ii. Data rather than processes are the most complex aspects of many modern information
systems.
iii. The characteristics about data e.g. format and relationships with other data are rather
permanent. Unlike what we have in process modelling- who receives which data, the
format of reports, and what reports are used- all these change constantly over time.
Also note:
ERD means entity relationship diagram: ERD communicates high-level business rules,
Business rules are constraints or guidelines that are followed during the operation of the
system.
ERD has some elements which are the entities, attributes, and relationships), each of
which is represented by a different graphic symbol.
Metadata can describe an ERD element (like entity name) and also information that is
helpful to the project team (like the user contact, the analyst contact, and special notes).

1 A data model describes the data that flow through the business processes in an
organization.
2 The data model presents the logical organization of data without indicating how the
data are stored, created, or manipulated so that analysts can focus on the business
without being distracted by technical details.
3 Entity Attributes, and Relationship are elements of an ERD. Also, Cardinality and
modality are properties of relationships.
4 An entity relationship diagram (ERD) is a conceptual model which shows the
information that is created, stored, and used by a business system.
5 An attribute is some type of information that is captured about an entity.
177
6 Relationships are associations between entities, and they are shown by lines that
connect the entities together.
7 A CASE tool is used to help build entity relationship diagrams.
8 Metadata can describe an ERD element (such as entity name) as well as information
useful to the project team (like the user contact, the analyst contact, and special
notes).
9 Entities, attributes, and relationships are the ERD elements, each of which is
represented by a different graphic symbol.


Can you describe the data modelling?
Can you explain the term entity relationship diagram?
Can you list the three basic elements in the data modelling language?
Can you describe metadata?
Can you state the steps involved in building an entity relationship diagram?
SAQ 8.1: A data model is a formal way of representing the data that are used and created by
a business system; it illustrates people, places, or things about which information is
captured and how they are related to each other.
It is seen by many system developers as the most important aspect of information
system requirements statement.
SAQ 8.2: An entity relationship diagram (ERD) is a conceptual model which shows the
information that is created, stored, and used by a business system.
178
SAQ 8.3: The three basic elements in the data modelling language are: (i) entities, (ii)
attributes, and (iii) relationships.
SAQ 8.4: Metadata is anything that describes an entity, attribute, or relationship, such as
entity names, attribute descriptions, and relationship cardinality.
SAQ 8.5: The basic steps in building an ERD are:
iii Draw relationships among entities to show how they are associated with one
another.
 Relationships are defined as associations between entities, which are shown by
lines that connect the entities together.
References
Jelena M., (2004): Lecture Notes on Information Resources Part - Introduction to Data
Modeling and MSAccess. Vilnius Gediminas Technical University
Zheng J.G., (2010): CIS 3730- Designing and Managing Data. J. Mack Robinson College of
Business, Georgia State University.
179
Study Session 9: Data Modelling--II
Introduction
You learnt about the meaning and some basic concept of a model in previous session, and
you know that analysts construct process models to reflect how the business system would
operate. Simultaneously, you discovered that analysts must comprehend the information used
and generated by the business system. This session will teach you more, particularly about
data modelling. Our focus here is on creating a logical data model. You will learn more on
how to create an entity relationship diagram (ERD) and discuss some style guidelines. Then,
we will present a technique called normalization that helps analysts validate the data models
that they draw.
This session will also teach you how to organize, present the data that flows through the
processes, as well as how data models balance, or interrelate, with the process models.

9.1 Highlight three special types of entities (SAQ 9.1)
9.2 Define Normalization (SAQ 9.2.)
9.3 Describe data model guidelines (SAQ 9.3)
9.4 Describe how to validate entity relationship (SAQ 9.4)
9.5 Explain how to balancing entity relationship diagrams with data flow diagrams (SAQ 9.5)
9.1 Advanced Concepts in Data Modelling

Now that we have created a data model according to the basic syntax that was presented
earlier, we can move to several advanced concepts. We will explain three special types of
entities and show how they can be used in our Transcript Request system.
180
Independent Entity: An independent entity is an entity that can exist without the help of
another entity, such as Transcript Applicant and Transcript. These entities all have identifiers
that were created from their own attributes. Attributes from other entities were not needed to
uniquely identify instances of these entities.
Independent entities are drawn as rectangles with a single border line.
When a relationship includes an independent child entity, it is called a non-identifying
relationship. This name is derived from the fact that parent entity attributes are not needed as
part of the child entity‘s identifier.
Dependent Entity: There are situations when a child entity requires attributes from the
parent entity to uniquely identify an instance. In these cases, the child entity is called a
dependent entity, and its identifier consists of at least one attribute from the parent entity.
A good example of a dependent entity is the Transcript Request entity shown in Figure 7.1. A
Transcript Request is made by a specific TA and includes a specific transcript. We include
the TA_ID and the Transcript_ID plus the request date to fully identify each Transcript
Request, Transcript Request is considered a dependent entity and is shown as a rectangle with
a double border line.
When relationships have a dependent child entity, they are called identifying relationships.
This name is derived from the fact that parent entity attributes are needed as part of the child
entity‘s identifier.
Intersection Entity A third kind of entity is the intersection entity. It exists in order to
capture some information about the relationship between two other entities. Typically,
intersection entities are added to a data model to store information about two entities sharing
an M:N relationship. These entities are also called Associative Entities. Think back to the
M:N relationship between TA and Transcript shown in figure 7.5. In that figure, one instance
of a TA could request many Transcripts, and a Transcript can be requested by many TAs. A
difficulty arises if we want to capture the date on which a particular transcript was requested
by a specific TA. We cannot put the date in the Transcript entity, because the Transcript is
requested by many TAs. We also cannot put the date in the TA entity, because there are many
Transcripts requested by the TA. Therefore, we need another entity that enables us to
associate a specific transcript with a specific TA on a specific date.
181
TRANSCRIPT APPLICANT requests TRANSCRIPT
*T A_ID *T RN_ID
T A_Name T RN_Name
T A_PhoneNumber T RN_Description
T A_Address
is requested by
T RN_ApprovalStatus

involves
*T A_ID makes *T RN_ID *T RN_ID
T A_Name *T RN_Name T RN_Name
T A_PhoneNumber RequestDate involved in T RN_Description
is made by
Figure 7.6: Resolving an M:N Relationship
The process of adding an intersection entity is called ―resolving an M:N relationship‖

because it eliminates the M:N relationship and its associated problems from the data model.
There are three steps involved in adding an intersection entity.
Step 1: Remove the M:N relationship line and insert a new entity in between the two existing
ones.
Step 2: Add two 1:N relationships to the model. The two original entities should serve as the
parent entities for each 1:N, and the new intersection entity becomes the child entity in both
relationships.
Step 3: Name the intersection entity.
Intersection entities are often named by a concatenation of the two entities that created it
(e.g., Transcript Request), making its meaning clear. Alternatively, the entity can be given
another appropriate name. Figure 7.6 shows the M:N TA-Transcript relationship and how it
was resolved with the use of an intersection entity. Are intersection entities dependent or
independent? Actually, it depends.
Sometimes an intersection entity has a logical identifier that can uniquely identify its
instances. For example, an intersection entity between a football team and a football pitch (a
182
Football team may train on many football pitches and a football pitch is trained on by many
football teams) may be called a training session. If training sessions have unique training
session Id, then the entity would be considered independent. In contrast, the Transcript
Request intersection entity in figure 7.6 requires the identifiers from both TA and Transcript
for an instance to be uniquely identified. Thus, Transcript Request is a dependent entity.
ITQ/ITQ answer
o Can you highlight the three steps involved in adding an intersection entity?
 Step 1: Remove the M:N relationship line and insert a new entity in between the
two existing ones.
Step 2: Add two 1:N relationships to the model. The two original entities should
serve as the parent entities for each 1:N, and the new intersection entity becomes
the child entity in both relationships.
Step 3: Name the intersection entity.
9.2 Validating Entity Relationship Diagrams

As observed from the previous sessions, creating ERDs is not an easy task. It takes a lot of
experience to draw ERDs well, and there are not many black and white rules to help guide
you. Luckily, there are some general design guidelines that you can keep in mind as you build
ERDs, and once the ERDs are drawn, you can use a technique called normalization to
validate that your models are well formed.
Another technique is to check your ERD against your process models to make sure that both
models balance each other.

o The technique used in validating models is called -----------
 Normalisation
9.3 ER Diagram Design Guidelines

Design guidelines are not rules that must be followed; rather, they are ―best practices‖ that
often lead to better quality diagrams. For example, labels and naming conventions are
important for creating clear ERDs. Names should not be ambiguous (e.g., name, number);
instead, they should clearly communicate what the model component represents. These
names should be consistent across the model and reflect the terminology used by the
business.
183
There are no rules covering the layout of ERD components. They can be placed anywhere
you like on the page, although most systems analysts try to put the entities that are related to
each other together. If the model becomes too complex, the model can be broken down into
subject areas. Each subject area would contain related entities and relationships, and the
analyst can work with one group of entities at a time to make the modelling process less
confusing.
In general, data modelling can be quite tricky, mainly because the data model is heavily
based on interpretation; therefore, when business rules change, the relationships or other data
model components will have to be altered. Assumptions are an important part of data
modelling. It is important that we verify all assumptions about business rules so that our data
model is correct.
Therefore, when you carryout data modelling, don‘t become overwhelmed by details. Rather,
add components to the diagram slowly, knowing that they will be changed and rearranged
many times. Make assumptions along the way and then confirm these assumptions with the
business users. Work iteratively and constantly challenge the data model with business rules
and exceptions to see whether the diagram is communicating the business system
appropriately.
UNIVERSITY
*UNI_name hires
COUNTRY
contains LECTURER
UNI_enrollment
*COU_name *LEC_ID
UNI_ dateEstab
LEC_name
UNI_chancellor
LEC_ startdate
UNI_firstpresident
specializes
COURSE
*name
description
area
Figure 7.7: Data Modelling Guidelines Summary unit
184
The Guidelines summary for evaluating data model can be deduced from figure 7.7 as
follows:
i. Country has only one instance (i.e., Nigeria). This entity is not needed
ii. If lecturers are called ―Academic Staff,‖ then the ERD should contain an entity called
―Professor,‖ to remain consistent.
iii. Why are all these attributes being captured about the University? Will it be necessary to
store the chancellor and the first president of each university? If not, these attributes should
be removed from the ERD.
iv. The attributes in the course entity are poorly labelled; we have no way of knowing to
which entity they belong if they stand alone- it would be helpful to begin each attribute with
COURSE_. Also, what is ―area‖? A term like ―department‖ of ―field of interest‖ would be
more descriptive.
v. In entity lecturer, the name attribute should be broken down into first name and last name;
else, there would be no way to manipulate names in the system. For instance, there would no
way to sort by last name if it were combined with the first name.
vi. This model assumes that a lecturer can only work for one university- what about those
with joint appointments? An assumption should be stated on the model or in the
documentation so that this business rule can be confirmed.
ITQ/ITQ answer
o ER Design guidelines are rules that must be followed; rather, than they are for ―best
practices‖ True/False?
 False
9.4 Normalization
Once you have created your ERD, there is a technique called normalization that can help you
validate the models that you have drawn. It is a process whereby a series of rules are applied
to a logical data model or a file to determine how well formed it is. Normalization rules help
analysts identify entities that are not represented correctly in a logical data model, or entities
that can be broken out from a file. The result of the normalization process is that the data
attributes are arranged to form stable, yet flexible, relations for the data model. Three
normalization rules are used to help analysts improve the quality of data models; these are
First Normal Form, Second Normal Form and Third Normal Form. These rules are applied
regularly in practice.
185
First Normal Form: A logical data model is in first normal form (1NF) if it does not
contain attributes that have repeating values for a single instance of an entity. Often, this
problem is called repeating attributes, or repeating groups. Every attribute in an entity should
have only one value per instance for the model to ―pass‖ 1NF.
Second Normal Form: Second normal form (2NF) requires first that the data model is in
1NF and second that the data model leads to entities containing attributes that are dependent
on the whole identifier. This means that the value of all attributes that serve as identifier can
determine the value for all of the other attributes for an instance in an entity. Sometimes, non-
identifier attributes are dependent on only part of the identifier (i.e., partial dependency), and
these attributes belong in another entity.
Third Normal Form: Third normal form (3NF) occurs when a model is in both 1NF and
2NF and when, in the resulting entities, none of the attributes is dependent on a non-identifier
attribute (i.e., transitive dependency).
Third normal form also addresses issues of derived, or calculated, attributes. By definition,
derived attributes can be calculated from other attributes and do not need to be stored in the
data model. As an example, a person‘s age would not be stored as an attribute if date of birth
were stored, because, by knowing the date of birth and current date, we can always calculate
the age.

o Can you mention the three normalization rules that help analysts improve the quality
of data models?
 These rules are First Normal Form, Second Normal Form and Third Normal
Form.
9.5 Balancing Entity Relationship Diagrams with Data Flow Diagrams

All the analysis activities of the systems analyst are interrelated. For example, the
requirements analysis techniques are used to determine how to draw both the process models
and data models, and the CASE repository is used to collect information that is stored and
updated throughout the entire analysis phase. Now you will see how the process models and
data models are interrelated.
Although the process model focuses on the processes of the business system, it contains two
data components—the data flow and the data store. The purposes of these are to illustrate
186
what data are used and created by the processes and where those data are kept. These
components of the DFD need to balance with the ERD. In other words, the DFD data
components need to correspond with the ERD‘s data stores (i.e., entities) and the data
elements that comprise the data flows (i.e., attributes) depicted on the data model.
Many CASE tools offer the feature of identifying problems with balance between DFDs and
ERDs; however, it is a good idea to understand how to identify problems on your own. This
involves examining the data model you have created and comparing it with the process
models that have been created for the system.
Check your data model and see whether there are any entities you have created that do not
appear as data stores on your process models. If there are, you should add them to your
process models to reflect your decision to store information about that entity in your system.
Similarly, the bits of information that are contained in the data flows should match up to the
attributes found in entities in the data models. For example, if the customer information data
flow that goes from the customer entity to the purchase aggregate process were defined as
having customer name, e-mail address, and home address, then each of these pieces of
information should be recorded as attributes in the customer entity on the data model. We
must verify that all the data items included in the data stores and data flows in the process
model have been included somewhere as an entity attribute in the data model.
We need to ensure that the data model fully incorporates all the data identified in the process
model. If it does not, then the data model is incomplete. In addition, all the data elements in
the data model should appear as a part of a data store and data flow(s) in the process model. If
some data elements have been omitted from the process model, then we need to investigate
whether those data items are truly needed in the processing of the system. If they are needed,
they must be added to the process model data stores and data flows; otherwise, they should be
deleted from the data model as extraneous data items.
A useful tool to clearly depict the interrelationship between process and data models is the
CRUD matrix. The CRUD which means Create, Read, Update, Delete matrix is a table that
depicts how the system‘s processes use the data within the system. It is helpful to develop the
CRUD matrix on the basis of the logical process and data models and then revise it later in
the design phase. The matrix also provides important information for program specifications,
because it shows exactly how data are created and used by the major processes in the system.
187
To create a CRUD matrix, a table is drawn listing all the system processes along the top, and
all the data entities (and entity attributes) along the left-hand side of the table. Then, from the
information presented in the process model, the analyst fills in each cell with a C, R, U, D,
(or nothing) to describe the process‘s interaction with each data entity (and its attributes).
Figure 7.8 shows a portion of a data flow diagram and the CRUD matrix that can be derived
from it. As you can see, if a process reads information from a data store, but does not update
it, there should be a data flow coming out of the data store only. When a process updates a
data store in some way, there should be a data flow going from the process to the data store.
External Process A External

Entity X Entity Y
Data Store F Process B
Process C Data Store G
Process A Process B Process C

Data Entity M
Attribute M-1 CRUD R R

Attribute M-2 CRUD R

Data Entity G
Attribute G-1 C R
Attribute G-2 C
Attribute G-3 C R
Figure 7.8: Partial Process Model and CRUD Matrix
188
o The process model contains two data components, which are --------- and --------
 The data flow and the data store.
Thinking carefully about the content of the data flows in the process models, you can identify
places where attributes may have been omitted from the data stores/entities. In addition, you
can verify that every attribute is created, read, updated, and deleted somewhere in the process
model. If it is not read by some process, then the attribute is probably not needed. If it is not
created or updated, the attribute probably needs to be added to a data flow(s) in the process
model.
The Next activity is based on what you learned in this session about data modelling.
Activity 9.1 Data modelling guidelines

and knowing that data modelling requires some guidelines, can you note down some of the
keys guidelines?
Activity 9.1 Feedback: Guidelines for data modelling is summarised as follows:

ii. If lecturers are called ―Academic Staff,‖ then the ERD should contain an entity called
―Professor,‖ to remain consistent.
iii. Why are all these attributes being captured about the University? Will it be necessary to
store the chancellor and the first president of each university? If not, these attributes should
be removed from the ERD.
iv. The attributes in the course entity are poorly labelled; we have no way of knowing to
which entity they belong if they stand alone- it would be helpful to begin each attribute with
COURSE_. Also, what is ―area‖? A term like ―department‖ of ―field of interest‖ would be
more descriptive.
v. In entity lecturer, the name attribute should be broken down into first name and last name;
else, there would be no way to manipulate names in the system. For instance, there would no
way to sort by last name if it were combined with the first name.
vi. This model assumes that a lecturer can only work for one university- what about those
with joint appointments? An assumption should be stated on the model or in the
Take a look at figure 7.7; it describes the data modelling guidelines
189
UNIVERSITY
*UNI_name *LEC_ID
contains hires LECTURER
COUNTRY UNI_enrollment LEC_name
*COU_name UNI_ dateEstab LEC_ startdate
UNI_chancellor
UNI_firstpresident
specializes
COURSE
*name
description
area
unit
Figure 7.7: Data Modelling Guidelines Summary
 For us to meaningfully learn about data modelling there is a need to understand the guidelines
involved. In other words the data modelling guidelines are explained in Box 9.1
190
Box 9.1: Advanced data modelling
There are three special types of entities in modelling.
These are independent entity, dependent entity and intersection entity
 When a relationship includes an independent child entity, it is called a non-
identifying relationship.
 Intersection entity exists in order to capture some information about the
relationship between two other entities.
 When relationships have a dependent child entity, they are called identifying
relationships.
 You can use a technique called normalization to validate that your models are
well formed.
 Another option is to compare your ERD to your process models to ensure that
both models are balanced when validating ERD
 Design guidelines are not rules that must be followed; rather, they are ―best
practices‖ that often lead to better quality diagrams.
 Normalization rules help analysts identify entities that are not represented
correctly in a logical data model, or entities that can be broken out from a file
 The requirements analysis techniques are used to determine how to draw both
the process models and data models.
 The CASE repository is used to collect information that is stored and updated
throughout the entire analysis phase.

1. A CASE tool is used to assist in the creation of entity relationship diagrams.
2. Normalization techniques can be used to validate whether the models are well formed or
not.
3. To validate the ERD, the ERD can be checked against your process models to make sure
that both models balance each other.

Now that you have completed this study session, you can assess how well you have achieve d
191
Can you highlight three special types of entities?
Can you define normalization?
Can you state data model guidelines?
SAQ 9.4(tests learning outcome 9.4)
Can you describe how to validate entity relationship?
Explain how to balancing Entity Relationship Diagrams with Data Flow Diagrams
SAQ 9.1: The three special types of entities are: i) Independent Entity,(ii) Dependent Entity:
(iii) Intersection Entity
SAQ 9.2: Normalisation is a process whereby a series of rules are applied to a logical data
model or a file to determine how well formed it is.
Normalization rules help analysts identify entities that are not represented
correctly in a logical data model, or entities that can be broken out from a file.
SAQ 9.3: The Guidelines for data model are as follows:
ii. If lecturers are called ―Academic Staff,‖ then the ERD should contain an entity
called ―Professor,‖ to remain consistent.
iii. Why are all these attributes being captured about the University? Will it be
necessary to store the chancellor and the first president of each university? If not,
these attributes should be removed from the ERD.
iv. The attributes in the course entity are poorly labelled; we have no way of knowing
to which entity they belong if they stand alone- it would be helpful to begin each
attribute with COURSE_. Also, what is ―area‖? A term like ―department‖ of ―field of
interest‖ would be more descriptive.
v. In entity lecturer, the name attribute should be broken down into first name and last
name; else, there would be no way to manipulate names in the system. For instance,
there would no way to sort by last name if it were combined with the first name.
192
vi. This model assumes that a lecturer can only work for one university- what about
those with joint appointments? An assumption should be stated on the model or in the
SAQ 9.4: To validate the ERD, the ERD can be checked against your process models to
make sure that both models balance each other.
SAQ 9.5: Balancing entity relationship diagrams with data flow diagrams necessitates the use
of —the data flow and the data store. The goals of these are to show what data is
utilized and created by the processes, as well as where that data is stored. These
DFD components must be balanced with the ERD. To put it another way, the DFD
data components must correspond to the ERD's data stores (i.e., entities) and the
data pieces that form the data flows (i.e., attributes) as illustrated on the data
model.
References
Jelena M., (2004): Lecture Notes on Information Resources Part - Introduction to Data
Modeling and MSAccess. Vilnius Gediminas Technical University
Zheng J.G., (2010): CIS 3730- Designing and Managing Data. J. Mack Robinson College of
Business, Georgia State University.
193

CSC 302

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CSC 302

Uploaded by

Copyright:

Available Formats

CSC 302

University of Ibadan Distance Learning Centre

General Editor: Prof. E.B. Omobowale

University of Ibadan Distance Learning Centre

Prof. K.O. Adebowale

Professor E.B. Omobowale

Help Head Office

Information Centres 16, Ajanaku Street,

The Course Contents

also addressed. 3 Units, Required.

Expected duration: 1 week or 3 contact hours

Figure 1.1: Seven Characteristics of a System

In-text Question & Answer

1.3. Important System Concepts

In-text Question & Answer

1.4. Types of Systems

i. Physical or Abstract Systems

ii. Open or Closed Systems

Five important characteristics of open systems can be identified.

Formal Information system

Director of Director of Finance & Director of

Department Head Department Head Lines of

Figure 1.4: Organizational chart showing Formal Information System

Informal Information Systems

Components of Information Systems

Here, the computer is deployed as the source of information. Computer-based information

In-text Question & Answer

 There are four types of systems. These are

In-text Question & Answer

1.7 Information Technology and Information Systems

The demand for traditional information technology staff—such as programmers, systems

In-text Question & Answer

Activity 1.1 Patterns of communication in an organisation

Director of Director of Finance & Director of

Department Head Department Head Lines of

Figure 1.4: Organizational chart showing Formal Information System

 For us to meaningfully learn about system there is a need to understand some

Summary of Study Session 1

a. Break a system into small, manageable, and understandable subsystems

Expected duration: 1 week or 3 contact hours

In-text Question & Answer

2.2 Types of Information Systems and their roles in an Organization

2.2.1 Transaction Processing Systems

2.2.3. Decision Support Systems (DSS)

Figure 2.3: Decision Support System

2.2.3.1 Group DSS

2.3 Expert Systems

In-text Question & Answer

2.4 Scientific and Office Information Systems

In-text Question & Answer

Activity 2.1 Decision Support Systems

Figure 2.3: Decision Support System

 For us to meaningfully learn about information system there is a need to understand

Summary of Study Session 2

SAQ 2.1 (tests learning outcome 2.1)

Notes on the Self-Assessment Questions (SAQs) for Study Session 2

SAQ 2.2: Information system is classified into

Srinivas N.(n.d.) : Management information systems and business decision making:

Stephen B. H (n.d.): Management Information Systems. Department of Agricultural

Expected duration: 1 week or 3 contact hours

Learning Outcomes for Study Session 3

3.1 System development methodology

Stop Project Replace

Stop Project System Design