?

SYSTEM ANALYSIS
Subject: SYSTEM ANALYSIS Credits: 4

SYLLABUS

Introduction to analysis and design

SDLC, case tools for analyst, role of system analyst, ER data models, feasibility study-economic, technical,
operational

Design of application
DFDs, form design, screen design, report design, structure chart, data base definition, equipment specification
and selection personnel extimates, I-O design.

Implementation
Data dictionary, decision tables, decision trees, logical design to physical implementation.

Introduction to distributed data processing and real time system

Evaluating distributing system, designing distributed data base, event based real time analysis tools state
transition diagrams.

Suggested Readings:

1. James A., Analysis and Design of Information System, McGraw Hill.

2. Len, Fertuck, System Analysis and Design, McGraw Hill
3. Powers, Cray, System Analysis and Design, McGraw Hill
4. Elias, M., System Analysis and Design, Prentice Hall of India
 SYSTEMS ANALYSIS
SYSTEM ANALYSIS

COURSE OVERVIEW

The study of data structures is an essential part of virtually This subject is too big to be covered in its entirety in the time

every computer course, as data structures show how data is available, so the aim must be to provide a range of experi-

actually organized and used by the computer. This unit ences, which can be applied to problems, and the performance

provides the student with a range of experiences in using the and resource issues which ensue.

algorithms and data structures that underpin much of today’s This should allow students to develop solutions using data

computing. The various techniques presented should be seen in structures for a range of commercial needs.

the context of solving problems using computers.

i
 SYSTEMS ANALYSIS
SYSTEMS ANALYSIS

CONTENT
. Lesson No. Topic Page No.

Lesson 1 The System Definitions 1

Lesson 2 Objective of a System 6

Lesson 3 Role of System Analyst 11
Lesson 4 Elements of a System 17

Lesson 5 Characteristics of a System 21

Lesson 6 Introduction to Types of System 24
Lesson 7 Types of models 27

Lesson 8 Overview of SDLC 33

Lesson 9 Stages of SDLC 37
Lesson 10 Stages of SDLC System Approaches 41

Lesson 11 Stages of SDLC 48

Lesson 12 Definition of validation and verification 51
Lesson 13 Validation and Verification 56

Lesson 14 Validation and Verification 60

Lesson 15 Validation and Verification 64
Lesson 16 Validation and Verification 69

Lesson 17 Evaluation of models 74

Lesson 18 Object Based Methods 79
Lesson 19 Object Based Methods 87

Lesson 20 Introduction to System Investigation fact Finding Techniques 100

Lesson 21 Fact Finding Techniques 106

Lesson 22 Fact Finding Techniques 111

Lesson 23 Fact Finding Techniques 116

iii
SYSTEMS ANALYSIS

SYSTEMS ANALYSIS

CONTENT
. Lesson No. Topic Page No.
Lesson 24 Fact recording Flow diagrams 121

Lesson 25 Stanadard Documentation Techniques 126

Lesson 26 Overview of Functional and data Modelling 129

Lesson 27 Data Flow Diagram 134

Lesson 28 Data Flow Diagram and Entity Diagram 137
Lesson 29 Overview of Data Modelling 140

Lesson 30 Entity Identification 143

Lesson 31 Entity Relationships 146
Lesson 32 Context Diagrams 150

Lesson 33 System Modeling 154

Lesson 34 Normalization 160
Lesson 35 Information Analysis 164

iv
 CHAPTER-1
LESSON 01: LIFE CYCLE MODELS
SYSTEM DEFINITIONS

Topics Covered based on our own day-to-day experience, as well as the experience

SYSTEMS ANALYSIS
• Introduction to System Concept of scientists and engineers in a variety of fields.
• The System Definitions • Thus, if we understand something of general systems theory,
it can help us better understand computerized (automated)
• Objectives
information systems.
• Introduction to Computer Base Information System (CBIS)
• Today, this is more and more important, because we want to
Objectives build stable, reliable systems that will function well in our
• Upon completion of this Lesson, you should be able to: complex society, and of course, there are many examples of
non-computer systems that have survived for thousands of
• Explain the Nature and Scope of System years.
• Explain the need of system analysis. And now, we can consider a definition of the basic term “system”.
Introduction It provides several definitions:
What is a System? • A regularly interacting or interdependent group of items
Generally we come into daily contact with the transportation forming a unified whole.
system, the telephone system, the accounting system, the • An organized set of ideas, or principles, usually intended to
production system, and for over tow decades, the “computer explain the arrangements or working of a systematic whole.
system”.
• An organized or established procedure.
Introduction to System Concept • Harmonious arrangement or pattern: order.
There are many common types of systems that we come into
contact with every day. It is important to be familiar with different The System Definitions
kinds of systems for at least two reasons: Do u know from where the term system is derived?
• First, even though your work as a systems analyst (we will • The term system is derived from the Greek word systema,
discuss about system analyst in detail in the later lessons)will which means an organized relationship among functioning
probably focus on one kind of system – an automated, units or components.
computerized information system – it will generally be a part • A system exists because it is designed to achieve one or more
of a larger system. objective.
• For example, you may be working on a payroll system, which • Similarly, we talk of the business system and of the organization
is part of a larger “human resources” system, which is, in turn, as a system consisting of interrelated departments (subways
part of an overall business organization (which is itself, a terms) such as production, sales, personnel, and an information
system), which is, in turn, part of al larger economic system, system.
and so on.
• What is an Information System?
• Thus, to make your system successful, you must understand
the other systems with which it will interact. Many of the • An information system is an arrangement of people, data,
computer systems that we build are replacements, or new processes, interfaces, networks, and technology that interact for
implementations of, non-computerized systems that are the purpose of supporting and improving both day-to-day
already in existence. operations in a business (sometimes called data processing), as
well as supporting the problem solving and decision making
• Also, most computer systems interact with, or interface with, a
variety of existing systems (some of which may be needs of management (sometimes called information services).
computerized and some which may not).
What is a Computer Application System?
If our new computer system is to be successful, we must
understand, in reasonable detail, how the current system behaves.
• A computer application is computer-based solution to one or
more business problems and needs. One or more computer
• Second, even though many types of systems appear to be applications are typically contained within an information
quite different, they turn out to have many similarities. system.
• There are common principles and philosophies and theories
that apply remarkably well to virtually all kinds of systems.
• Thus, we can often apply to systems that we build in the
computer field, what we have learned about other systems,

1
 There are more than a hundred definitions of the
SYSTEMS ANALYSIS

word ‘system’ some important definitions of the

term systems are as follows:

Production
• A system is an orderly grouping of interdependent components
System linked together according to a plan to achieve a specific objective.
• A system is an organized interacting, interdependent and
integrated set of components/variables/parts. A system has
Sales Personnel objectives/goals.
System System
• Webster dictionary describes system as asset or arrangement of
things so related or connected to from a unity or organization.
Information
System • A system is a set of elements forming an activity or a processing
procedure or a scheme, seeking common goal(s) by operating
on data/energy/matter (inputs) in a time reference to yield
information on energy/output.
• None of these subsystems is of much use as a single, • McGraw-Hill dictionary of computers describes system as a
independent unit. When they are properly coordinated, combination of two or more sets generally physically separated
however, the firm can function effectively and profitably. when in operation, and such other assemblies, sub-assembles,
and pars necessary to perform an operational function(s).
The noun “system” has 9 senses such as.
• System definition is the most critical phase in any manufacturing
1. System project. The functionality and performance of a product are
A group of independent but interrelated elements comprising a defined in this stage, which becomes the basis for determining
unified whole; “a vast system of production and distribution and product specifications and capabilities.
consumption keep the country going”.
The System Concept
2. System
• Ludwig von Bertalanffy, a biologist, developed a general systems
Instrumentality that combines interrelated interacting artifacts
theory that applies to any arrangement of elements such as
designed to work as a coherent entity; “he bought a new stereo
cells, people, societies, or even planets.
system”; “the system consists of a motor and a small computer”.
• Norbert Wiener, a mathematician, observed that information
3. System, System of Rules and communications provide connection links for unifying
A complex of methods or rules governing behavior; “they have fragments or elements. His systems concept of information
to operate under a system they oppose”. theory, which shows the parallel between the functioning of
4. System human beings and electronic systems, laid the foundation for
A procedure or process for obtaining an objective. today’s computer systems.
5. System • Herbert A. Simon, a political scientist, related the systems
A group of physiologically or anatomically related organs or parts; concept to the study of organizations by viewing an ongoing
“the body has a system of organs for digestion”. system as a processor of information for making decisions.

6. System (Arrangement)
• Systems analysis and design for information systems were
founded in general systems theory, which emphasizes a close
An organized structure for arranging or classifying; “he changed
look at all parts of a systems. Too often analysts focus on only
the arrangement of the topics”; “the facts were familiar but it was
one component and overlook other equally important
in the organization of them that he was original”; “he tried to
components.
understand their system of classification”.
• General systems theory is concerned with “developing a
7. System (Physical Chemistry) systematic, theoretical framework upon which to make
A sample of matter in which substances in different phases are in decisions.” . The idea of system has become most practical
equilibrium; “in a static system oil cannot be replaced by water on and necessary in conceptualizing the interrelationships and
a surface”; “a system generating hydrogen peroxide”. integration of operations, especially when using computers.
8.System Thus, a systems is away of thinking about organizations and
The living body considered as made up of interdependent their problems. It also involves a set of techniques that helps
components forming a unified whole; “exercise helped him get in solving problems.
the alcohol out of his system”.
9. System (Organization)
An ordered manner; orderliness by virtue of being methodical
and well organized; “his compulsive organization was not an
endearing quality”; “we can’t do it unless we establish some system
around here”.

2
Introduction to Computer Base • Thus, systems analysis is one of the important techniques that

SYSTEMS ANALYSIS
Information System(CBIS) provide a systematic and broader outlook to understanding,
• Systems analysis and design provide a structural approach to examining and creating or modifying systems to meet specific
the design and development of Computer Base Information objectives. Systems analysis and design is an interactive and
System (CBIS). creative process.
• The tasks involve in the design and development of CBIS can System Analysis Definition
be broadly classified into three categories, namely, • A systematic investigation of a real or planned system to
(a) Systems Analysis. determine the functions of the system and how they relate to
(b) Logical System Design. each other and to any other system.
(c) Physical System Design. • The analysis of the requirements of a task and the expression
of those requirements in a form that permits the assembly of
• Our subject deals with only the first part System Analysis. computer hardware and software to perform the task.
• The second part logical design provides logic for obtaining the • The analysis of the role of a proposed system and the
desired outputs for available inputs.
identification of the requirements that it should meet. SAD
• The third part physical design maps the logical design onto the (System Analysis and Design) is the starting point for system
physical hardware of a computer system. design. The term is most commonly used in the context of
There are many ways of classifying commercial programming, where software developers are often
systems.Common classifications are classed as either systems analysts or programmers. The systems
analysts are responsible for identifying requirements (i.e. systems
• Natural or man-made system.
analysis) and producing a design. The programmers are then
• Closed/open system. responsible for implementing it.
• Conceptual/physical system. • A systematic investigation of a real or planned system to
Natural systems occur in nature, e.g., solar system, whereas man- determine the functions of the system and how they relate to
made systems are specially created for specific objectives, e.g., defense each other and to any other system.
system, telephone system, accounting system, production system, • The Concise Oxford Dictionary of Current English states
etc. Other types are discussed in the later chapters. that system analysis is the analysis of a complex process or
System Analysis–What and Why? operation in order to improve its efficiency.
• Systems analysis is the reduction of an entire system by
studying various operations performed and their relationship • The beginning step of systems analysis, in
within the system; an examination of a business activity with a which the end user’s requirements are defined in
view to identifying problem area and recommending alternative order to get an idea of what kind of system must be designed
solutions. to meet those needs.
• System analysis thus emerges as a means through which the Types of Information Systems
total system is conceived, designed, implemented and made Organisations and individuals use different types of systems for
operational to achieve the desired objective. different purposes. Here are some of the main types of
• Thus, systems analysis specifically information systems and their uses.
• Offers a means to greater understanding of the complex Transaction processing system (TPS)
structures. A TPS collects and stores information about transactions, and
• Is a means to trade off between functional requirement of a controls some aspects of transactions. A transaction is an event
subsystem (component) and its immediately related of interest to the organisation. e.g. a sale at a store.
subsystem? A Tps is A Basic Business System. It
• Helps in understanding and comparing functional impacts of • Serves the most elementary day-to-day activities of an
subsystems to the total systems. organisation;
• Helps in achieving inter-compatibility and unity of purpose of • Supports the operational level of the business;
subsystems. • Supplies data for higher-level management decisions.
• Helps in discovering means to design systems where subsystem • Is often critical to survival of the organisation
may have apparently conflicting objectives.
• Mostly for predefined, structured tasks
• Helps in placing each subsystem in its proper perspective and
context, so that the system as a whole may best achieve its • Can have strategic consequences (eg airline reservation system)
objective with minimum available resources. It this creates • Usually has high volumes of input and output
synchronization between system and objectives.

3
 • Provides data which is summarised into information by systems tools are often integrated (e.g. Word processor can import a graph
SYSTEMS ANALYSIS

used by higher levels of management from a spreadsheet) and designed for easy operation.
• Need to be fault-tolerant. OAS Subspecies
On-line transaction processing: A transaction processing mode in Communication systems: helps people work together by sharing
which transactions entered on-line are immediately processed by information in many different formsTeleconferencing (including
the CPU. audioconferencing, computer conferencing, videoconferencing),
Sub-species of TPS: electronic mail, voice mail, fax
Groupware system: helps teams work together by providing access
Manufacturing and production systems
to team data, structuring communication, and making it easier to
Systems that supply data to operate, monitor and control the
schedule meetings. For sharing information, controlling work
production process. e.g. purchasing, receiving, shipping, process
flows, communication/integration of work
control, robotics, inventory systems, scheduling, engineering,
operations, quality control, resource management etc. Management information system (MIS)
converts TPS data into information for monitoring performance
E.G. A system in a factory that:
and managing an organisation. Transactions recorded in a TPS are
• Gets information from measuring samples of products analyzed and reported by an MIS.
• Does statistical analysis of samples They have large quantities of input data and they produce summary
• Shows when operators should take corrective action reports as output. Used by middle managers. An example is an
Sales and Marketing systems: Systems that support the sales and annual budgeting system.
marketing function by facilitating the movement of goods and Executive information system (EIS)
services from producers to customers. Also known as an Executive Support System (ESS), it provides
Examples: executives information in a readily accessible, interactive format.
They are an MIS for executive use. An EIS/ESS usually allows
• Sales support - keep customer records, follow-up
summary over the entire organisation and also allows drilling
• Telemarketing - use phone for selling down to specific levels of detail.
• Order processing - process orders, produce invoices, supply Used by top level (strategic) management. They are designed to
data for sales analysis and inventory control the individual. They let the CEO of an organisation tie in to all
• Point-of-sale - capture sales data at cash register often by scanner levels of the organisation. They are very expensive to run and
• Customer credit authorisation - advise on credit to be allowed require extensive staff support to operate.
to customer. Decision support system (DSS)
• Example: A Store’s Sales System would: helps strategic management staff (often senior managers) make
• Automatically record and total purchase transactions and prints decisions by providing information, models, or analysis tools.
out a packing list For support of semistructured and unstructured decisions
(structured decisions can be automated). Used for analytical work,
• Improve customer service
rather than general office support.
• Maintain customer data
They are flexible, adaptable and quick. The user controls inputs
Finance & Accounting Systems: Systems that maintain records and outputs. They support the decision process and often are
concerning the flow of funds in the firm and produce financial sophisticated modelling tools so managers can make simulations
statements, such as balance sheets and income statements.e.g. for and predictions.
Budgeting; General Ledger; Billing: Cost Accounting, Accounts
Their inputs are aggregate data, and they produce projections. An
Receivable / Payable; Funds Management Systems, Payroll. They
example job for a DSS would be a 5 year operating plan.
were among the earliest systems to be computerised.
Knowledge Work Systems (Kws) are used by technical staff.
Examples of financial systems: cash management, loan
KWS use modelling functions to convert design specifications
management, check processing, securities trading, Example: Visa’s
into graphical designs. They may include computer-aided design/
Credit Card payment system.
manufacture (CAD/CAM).
Human Resources System: Systems that deal with recruitment,
placement, performance evaluation, compensation, and career Summary
development of the firm’s employees. • A system is an orderly grouping of interdependent components
Examples: personnel record keeping, applicant tracking. linked together according to a plan to achieve a specific objective.
• Example business system has subsystems production, sales,
Office automation system (OAS)
personnel, and an information system which can also be a
OAS provides individuals effective ways to process personal and
system.
organisational data, perform calculations, and create documents.
e.g. word processing, spreadsheets, file managers, personal • CBIS can be broadly classified into three categories, namely,
calendars, presentation packages For are used for increasing
personal productivity. They reduce “paper warfare”. OAS software

4
Systems Analysis. References

SYSTEMS ANALYSIS
Logical System Design. Hoffer, Jeffrey A.
Modern systems analysis and design
2nd ed. Delhi : Pearson Education Asia, 2000
Sarkar, A.K.
Systems analysis, data processing and quantitative
techniques
New Delhi : Galgotia Publications, 1997
Physical System Design.
Hawryszkiewycz, Igor
System Analysis Definition Introduction to systems analysis & design
4th ed. New Delhi : Prentice Hall of India, 2002
Awad, Elias M.
Systems analysis and design
New Delhi : Galgotia Publications, 1997
Refer to Website address
http://www.sce.carleton.ca
http://www.umsl.edu
Notes

A systematic investigation of a real or planned system to determine

the functions of the system and how they relate to each other and
to any other system.
Questions
1. What do you mean by system?
2. Give any two examples for system.
3. What do you mean by computerized system?
4. Do you know from where the term system is derived?
5. Define system.
6. Why we go for system analysis and what is system analysis.
What is a System? What is System Analysis?

5
SYSTEMS ANALYSIS

LESSON 02:
OBJECTIVE OF THE SYSTEM

Topics Covered • May have multiple objectives

• Objective of a System • Determine your client - usually person paying the bill!
• Methodology of Systems Analysis Participants to system • Establish the needs of the client - sometimes difficult to
development establish
• Role of system analyst • Identify the clients single most important objective
Objectives • Choose a measure of effectiveness.
Upon completion of this Lesson, you should be able to • Discuss the project objective with the client
• Define the Objective of a system 2.Development of a system model
• Discuss the various participants in system development • Most often this is the responsibility of the systems analyst or
engineer
Objective of a System
• Keep in mind that the model is an abstraction of the system
The study of systems concepts, has three basic implications:
• A two stage process is sometimes used:
• A system must be designed to achieve a predetermined
objective. • Model decoupling - simplifying step where system components
are modeled and analyzed as subsystems. This can be helpful
• Interrelationships and interdependence must exist among the in better understanding the system.
components or subsystem.
• Model integration - entire system is modeled (e.g., the subsystem
• The objective of the organization as a whole has a higher priority components are integrated)
than the objectives of its subsystems.
• Delicate balance exists between model detail and the ability to
• For example, computerizing personnel applications must effectively and efficiently analyze the mode. Modeling detail
conform to the organization’s policy on privacy, confidentiality, may offer better reality at increased computational expense.
and security, as well as making selected data (e.g., payroll) available Under certain circumstances, a simple model may prove more
to the accounting division on request. valuable than a more complex model. The project objectives
should dictate the level of detail required.
• Many types of models are available for use
• The type of model chosen depends on system, the objectives,
perspective (time scale) of models
• One should select the most “appropriate model” - by the end
of the semester you should have a better feel for this
3.Evaluation of alternatives
• Goal is to find an optimum solution
• Identify alternative solutions
• Gather as much information about alternative solutions as
possible - may require searching the literature, obtaining technical
and cost data on equipment, operation, maintenance, and other
pertinent information
• Perform sensitivity analysis to determine response to change in
model parameters
• Verification - computer code reproduces model chosen
Methodology of Systems Analysis • Validation - model of system faithfully reproduces the actual
system
1. Identification of objectives
• This is very important. If the correct objectives are not identified,
the correct problem will not be solved!
• Consult others .
• Use multi-disciplinary team

6
 In a large organization, the initiation of a systems development

SYSTEMS ANALYSIS
project is usually much more formalized.
Whenever possible, the systems analyst should try to establish
direct contact with the user. Even if other people are involved as
intermediaries, it is important to have regular, face-to-face meeting
with the person who will ultimately inherit the system.
If it is not possible to communicate directly with the user, then
the documentation produced by the systems analyst becomes even
more crucial.
The heterogeneity of Users
One mistake often made by computer programmers, and
sometimes by systems analysts is to assume that all users are the
same.
“User” implies that the systems analyst will only have to interact
with one person, even when it is obvious that more than one user
is involved, there is a tendency to think of them as a formless,
shapeless, homogeneous group of humans.
Participants to system development Job category,
In the role of a systems analyst, you will work on systems or level of
development projects with a variety of other people. The cast of Supervision.
characters will change from project to project, the personalities will
differ dramatically, and the number of people that you interact
Here are two ways of categorizing users:
with will range from as few as one to as many as several dozen.
Level of
However, the roles are fairly consistent, and you will see them over
experience
and over again.
withdata
In a typical systems development project, there are the following
processing
major categories of players:
• ·User
Categorizing Users by Job category
• Management
On a typical systems analysis project, we can usually count on
• Auditors, quality assurance people, and ‘standards bearers” interacting with three main job categories:
• Systems analysts
(a) Operational users:
• Systems designers are the clerical, operational, and administrative people most likely
• Programmers to have the most day-to-day contact with the new system. There
• Operations personnel are three things should be kept in mind when working with
operational-level users:
Users • Operational users are very much concerned with the functions
The user, the most important player in the systems game, is the
that the system will perform, but they are likely to be even
person (or group of people) for whom the system is being built.
more concerned with the human interface issues.
He or she is the person, whom will be interviewed, often in great
• Operational users tend to have a “local” view of the system,
detail, to learn what features the new system must have to be
they tend to be knowledgeable about the specific job that they
successful.
do and the people with whom they have immediate contact.
The user is the “owner” in the sense that he or she receives, or But they often are unfamiliar with the “big picture”, that is,
inherits-and thus owns- the system when it is finally built. And they may have trouble describing how their activity fits into the
the user is the “customer” in at least two important respects: overall organization or what the overall organization’s chart
1. As in so many other professions, “the customer is always really is.
right”, regardless of how demanding, unpleasant, or irrational • Operational users tend to think of systems in very physical
he or she may seem. terms, that is, in terms of the implementation technology
2. The customer is ultimately the person paying for the system currently used to implement the system or in terms of
and usually has the right and/or the ability to refuse to pay if technology that they imagine could be used.
he or she is unhappy with the product received.
(b) Supervisory users are employed in a supervisory
Who makes a formal request for a system? capacity:
In most cases, it is fairly easy to identify the user: the user is They usually manage a group of operational users and are
typically the person who makes a formal request for a system. responsible for their performance. The significant things to
In a small organization, this is usually a very informal process. remember about supervisory users are these

7
 • Many of them are former operational users who have been produce a variety of internal reports and short-term trend
SYSTEMS ANALYSIS

promoted to their current position. analyses.

• One reason that the supervisory user may be perceived as out • Executive development project (EDP)/MIS managers: the
of touch with the operational user is that he or she is often person in charge of the systems development project itself,
measured and motivated by performance against a budget. and the higher-level managers who are concerned with the
• It is usually the supervisory user who thinks of a new system overall management and allocation of resources of all the
as a way of reducing the number of operational users or avoiding technical staff in the systems development organization.
further increases in their numbers as the volume of work • General management: top-level managers who are not directly
increases. involved in the EDP organization or in the user organization.
• The supervisory user will often act as a middleman between This might include the president and/ or chairman of the
the systems analyst and the operational user. organization.
The primary interaction between the systems analyst and all these
• The supervisory user often thinks in the same physical terms
managers has to do with the resources that will be assigned to the
as the operational user, and this perspective is often just as local
project. It is the systems analyst’s job to identify and document
as that of the operational user.
the user’s requirements and the constraints within which the
• Finally, the supervisory user will be contacted day-to-day. He or system must be built.
she is the one who will typically define the requirements and
detailed business policy that the system must implement. He Auditors
or she may be a passive member of the team, a full-time member Depending on the size of the project and the nature of the
of the team, or even the project manager. organization you work in, you may or may not have auditors.
(c) Executive-level users
Systems analysts
Generally not directly involved in a systems development project,
The system analyst is a key member of any systems development
unless the project is so large and so important that it has a major
project. In a boarder sense, the systems analyst plays several roles:
impact on the organization.
• Archaeologist and scribe: As a systems analyst, one of the main
Categorizing Users by Level of Experience jobs is to uncover detail and to document business policy that
Different users will have different levels of experience. Today, we may exist only as “tribal folklore”, passed down from
can distinguish between rank amateurs, cocky novices, and a small generation to generation of users.
(but rapidly growing) number of true computer experts.
• Innovator: The systems analyst must separate the symptoms
• The amateur is the one who has never seen a computer and of the user’s problem from the true causes. With his or her
who exclaims loudly and frequently that he or she doesn’t knowledge of computer technology, the analyst must help the
understand all this computer stuff. The real problem with the user explore useful, new applications of computers.
amateur user is somewhat more subtle: he or she may find it
• Mediator: The systems analyst who often finds himself in the
difficult to understand the “language” that the systems analyst
middle of users, managers, programmers, auditors, and
uses to describe the features, functions and characteristics of
various other players, all of whom frequently disagree with
the system to be built, even though that language avoids
one another.
obvious computer-related terminology.
• The second type of user is the “cocky novice”, the person who
• Project leader: Because the systems analyst is usually more
experienced than the programmers on the project, and since he
has been involved in one or two systems development projects,
is assigned to the project before the programmers begin
or the user who has a personal computer and who has written
working, there is a natural tendency to assign project
one or two basic programs. This user often claims to know
management responsibilities to the analyst.
exactly what he or she wants the system to do and is prone to
point out all the mistakes that the systems analyst made on the Systems designers
last project. The systems designer is the person (or group of people) who will
• Of course, there are some users who really understand systems receive the output of the systems analysis work. His or her job is
analysis, as well as the underlying technology of computers. It to transform a technology-free statement of user requirements
is a pleasure working with these people. The only problem into a high-level architectural design that will provide the framework
may be that the user and the systems analyst derive so much within which the programmer can work. In many case, the systems
pleasure talking about the tools and techniques of systems analyst and the systems designer are the same person, or member
analysis that they forget that their true objective is to build a of the same unified group of people. It is important for the
functioning system. systems analyst and systems designer to stay in close touch
throughout the project.
Management
Management is a rather loose term. The systems analyst is likely to Programmers
come into contact with several different kinds of managers: Particularly on large systems development projects, the systems
designers are likely to be a “buffer” between the systems analysts
• User managers: managers in charge of several people in the and the programmers.
operational area where the new system will be used. These are
usually middle-level managers who want systems that will

8
The systems analysts deliver their product to the system designers, 4

SYSTEMS ANALYSIS
and the system designers deliver their product to the programmer. 5
There is another reason why the systems analyst and the Who are the systems analyst’s customers and partners in systems
programmer may have little or no contact with each other: work is development.
often performed in a strictly serial sequence in many systems 1
development projects.
2
Thus, the work of systems analysis takes place first and is
3
completely finished before the work of programming begins.
4
Operations personnel
5
The operations personnel who are responsible for the computer
What business trends are influencing the careers of systems
center, telecommunications network, security of the computer
analysts?
hardware and data, as well as the actual running of computer
programs, mounting of disk packs, and handling of output from 1
computer printers. 2
All this happens after a new system has not only been analyzed 3
and designed, but has also been programmed and tested. 4
Summary 5
Objective of a System How can you prepare yourself for a career as a systems or business
Methodology of Systems Analysis analyst?
1
1. Identification of objectives
2
2. Development of a system model
3
3. Evaluation of alternatives
4
Participants in system development project
User Management Auditors, quality assurance people, and 5
‘standards bearers” Systems analysts Systems designers What does the future hold for systems analysts?
Programmers Operations personnel 1
Questions 2
What is the systems analyst’s role and responsibilities in the 3
modern business?
4
1
5
2 List down the various participants in the system development
3 1
4 2
Why are organizations recruiting computer end-users to partner
3
with the traditional systems analyst?
4
1
5
2
On what basis you categorize the users. Give your explanation
3 below.
4 1
5 2
On what basis we choose the model for a project?
3
1
4
2
5
3
4
5
List down the career opportunities for systems analysts?
1
2
3

9
 References
SYSTEMS ANALYSIS

Heuring, Vincent P.
Computer systems design and architecture
Delhi : Pearson Education Asia, 1997
Whitten, Jeffrey L.
Systems analysis and design methods
5th ed. New Delhi : Galgotia Publications, 2001
Shelly, Gary B.
Systems analysis and design
3rd ed. New Delhi : Galgotia Publications, 1999
Awad, Elias M.
Systems analysis and design
New Delhi : Galgotia Publications, 1997
Website address
http://www.sce.carleton.ca
http://www.umsl.edu
Notes

10
 LESSON 03:

SYSTEMS ANALYSIS
ROLE OF SYSTEM ANALYST

Topics Covered and computer applications that are implemented by various

• Role of system analyst technical specialists including computer programmers.
• Modern Business trends
A formal Definition
• Tips for preparing for a career as system analyst A systems analyst facilitates the study of the problems and needs
Objectives of a business to determine how the business system and
Upon completion of this Lesson, you should be able to: information technology can best solve the problem and accomplish
• Explain the need of System analyst improvements for the business. The product of this activity may
be improved business processes, improved information systems,
• Discuss the various roles played by system analyst while
or new or improved computer applications frequently all three.
developing a project.
When information technology is used, the systems analyst is
Express the various tips for preparing as a career for system analyst
responsible for:
The Systems Analyst • The efficient capture of data from its business source
In the last lesson we had a brief introduction about system analyst.
Hope u know why we have system analyst in the system • The flow of that data to the computer
development? If not, here in this lesson we shall go through in • The processing and storage of that data by the computer
detail about the various roles played by the system analyst. • The flow of useful and timely information back to the business
• Many organizations consider information systems and and its people
computer applications as essential to their ability to compete or Information technology is a contemporary term that describes the
gain competitive advantage. combination of computer technology (hardware and software)
• Information has become a management resource equal in with telecommunications technology (data, image, and voice
importance to property, facilities, employees, and capital. networks).
• All workers need to participate in the development of these A systems analyst is a business problem solver.
systems and applications – not just the computer and A systems analyst helps the business by solving its problems
information specialists. using system concepts and information technology.
• But one specialist plays a special role in systems and applications A systems analyst sell business management and computer users
development, the systems analyst. the services of information technology.
• A systems analyst(s) facilitates the development of information A systems analyst sells change.
systems and computer applications.
The role of systems analyst is changing into two
• The systems analyst performs systems analysis and design. distinct positions or roles, business analyst and
• Systems analysis is the study of a business problem domain application analyst.
for the purpose of recommending improvements and • A business analyst is a systems analyst that specializes in
specifying the business requirements for the solution. business problem analysis and technology-independent
• Systems design is the specification or construction of a technical, requirements analysis.
computer-based solution for the business requirements • An application analyst is a systems analyst that specializes in
identified in a systems analysis. (Note: Increasingly, the design application design and technology-dependent aspects of
takes the form of a working prototype.). development. A synonym is system or application architect.
Why do businesses need Systems Analysts? What Does A System Analyst Do?
• The system analyst bridges the communications gap between
A system analyst is a system-oriented problem
those who need the computer and those who understand the
solver.
technology.
• System problem solving is the act of studying a problem
Who is a Systems Analyst? environment in order to implement corrective solutions that
• Systems analysts are people who understand both business take the form of new or improved systems.
and computing. Most systems analysts use some variation of a system problem
• Systems analysts study business problems and opportunities solving approach called a system development life cycle.
and then transform business and information requirements • A systems development life cycle (SDLC) is a systematic and
of the business into the computer-based information systems orderly approach to solving system problems.

11
 The SDLC usually incorporates the following • This center manages the data and information resource in the
SYSTEMS ANALYSIS

general-purpose problem solving steps: organization.

• Planning - identify the scope and boundary of the problem, • Data Administration usually employs several systems analyst-
and plan the development strategy and goals. like specialists called data analysts who analyze database
• Analysis - study and analyze the problems, causes, and effects. requirements and design and construct the corresponding
Then, identify and analyze the requirements that must be databases.
fulfilled by any successful solution. Telecommunications
• Design - if necessary, design the solution not all solutions • This center designs, constructs, and manages the computer
require design. networks that have become integral to most businesses.
• Implementation - implement the solution. • Network analysts perform many of the same tasks as applied
• Support - analyze the implemented solution, refine the design, to designing local and wide area networks that will ultimately
and implement improvements to the solution. Different be used by systems and applications.
support situations can thread back into the previous steps. End-User Computing
System analysts are responsible for other aspects of • This center supports the growing base of personal computers
a system including: and local area networks in end user community.
• People, including managers, users, and other developers – and • They provide installation services, training, and help desk
including the organizational behaviors and politics that occur services (call-in help for various PC related problems).
when people interact with one another.
• In mature businesses, they also provide standards and
• Data, including capture, validation, organization, storage, and consulting to end users who develop their own systems with
usage. PC power tools such as spreadsheets and PC database
• Processes, both automated and manual, that combines to management systems.
process data and produce information. In this latter role, they employ analyst-like end user computing
• Interfaces, both to other systems and applications, as well to Where Do System Analysts Work?
the actual users (e.g., reports and display screens). The Systems Analyst in the Traditional Business.
• Networks, which effectively distribute data, processes, and • Information Services is organized according to the following
information to the people. functions or centers
Systems analysts can be found in most businesses; however, the
Computer Operations
organization of information services in many businesses is in
turmoil as those businesses reorganize to improve service, quality, • This center runs all of the shared computers including
and value. mainframes, minicomputers, and non-departmental servers.

The Systems Analyst in the Traditional Business.

• This unit rarely employs systems analysts.
• Information services are centralized for the entire organization • Consultants.
or a specific line of business. Modern Information Services in a Business
• Information Services reports directly to chief executive officer, • Dramatic reorganization trend in medium-to-large information
services units that are highly decentralized with a focus on
or the chief executive for a line of business.
empowerment and dynamic teams.
Where Do System Analysts Work? • Result is a federation of information systems centers that report
The Systems Analyst in the Traditional Business. directly to their functional business units (or groups of business
Information Services is organized according to the following units).
functions or centers: • Each of these centers is empowered to set priorities and make
· Systems and Applications Development. decisions on behalf of their constituent management and users.
· Most systems analysts work here, along with most • Decentralized information services can, however, lead to
programmers. information anarchy and systems that do not interoperate to
the benefit of the business as a whole.
· The systems analysts and programmers are organized into
permanent teams that support the information systems and • There will always be systems and applications that support
applications for specific business functions. more than one business function perhaps the entire enterprise.
· The Systems and Applications Development unit may include • There still exists a need for a central Information Services unit.
a development center. • The central Information Services unit is responsible for:
· A development center establishes and enforces the methods, • Information Strategy Planning
tools, techniques, and quality of all development projects. • The information strategy planning team establishes direction
Data Administration and priorities for aligning information services for the entire
business with the corporate mission, vision, and goals.

12
• Experienced systems analysts often play key roles in • A user is a person, or group of persons, for whom the systems

SYSTEMS ANALYSIS
development. analyst builds and maintains business information systems
• Information Technology Competency Centers and computer applications. A common system is client.
• The centers provide a pool of technology specific specialists, • There are at least two specific user/customer groups: system
which are provided to both, centralized and decentralized units users and system owners.
for project work. • System users are those individuals who either have direct contact
• Each expert contributes their expertise to any project to which with an information system or application or they use
they are assigned, for both centralized and decentralized projects information generated by a system.
• Cross Functional Systems and Applications Development • System owners provide sponsorship of information systems
and computer applications. In other words, they pay to have
• This center develops and supports the shared information
the systems and applications developed and maintained.
systems and cross-functional applications for the business.
A manager can also be one of the end users of a system.
• This center employs experienced systems analysts.
• As projects are started and completed, both systems analysts Two types of system users
and technical specialists are assigned to and released from project • Information technology managers and system analysts are
teams. making a demonstrated attempt to get closer to their customers
• Departmental Computing Coordination by forming a partnership.A manager can also be one of the end
users of a system.
• This unit provides both consulting services and quality
management services to the decentralized information and • Two types of system users:
computing centers. • Traditionally, most system users were internal users, that is
• Experienced systems analysts may be employed here to help employees of the business for which a system or application is
establish standards and guidelines, and to provide training designed.
and consultation to departmental projects. • Today’s user community includes external users as businesses
seek to make their information systems and applications
Consulting
interoperate with other businesses and the consumer.
1. A variation on consulting firms is systems integration.
• Information technology managers and system analysts are
• System integration involves helping organizations integrating making a demonstrated attempt to get closer to their customers
systems and applications that don’t work together properly, or by forming a partnership.
that run on very different technical platforms from different
The Roles of Management and Users in Systems Problem Solving
computer manufacturers.
• Systems analysts that specialize in systems integration are The roles of management and users in
frequently called systems engineers or systems integrators. • Implementation
Application Software Solution Providers • Users participate in system construction and testing. They are
the recipients of training necessary to enable the full user
• Application software solution providers are in the business of
community to work with the solution.
building information systems and application software packages
for resale to other businesses. • Support
• Many businesses have a policy of not building any system they • Users and management should routinely evaluate the working
can purchase. solution and suggest improvements.
• Software packages are typically written to the greatest common Modern Business Trends and Implications for the System Analyst
denominator of their intended market – that is, they are Systems analysts must keep up with rapidly changing technologies,
designed to meet general requirements and offer limited but today’s priorities are rapidly shifting from technology-driven
customizability. solutions to business-driven solutions.
• Software and solutions vendors usually hire two types of Total Quality Management (TQM)
systems analyst. • One of the major business trends of the 1990s is Total Quality
• Software engineers, are responsible for designing (and Management.
programming) the package itself. • Total Quality Management or TQM is a comprehensive
• Sales engineers, are responsible for helping customers that approach to facilitating quality improvements and management
purchase the package to integrate it into their business within a business.
operations. • TQM commitments require every business function, including
Customers, Partners and Expectations information services, identify quality indicators, measure quality,
and make appropriate changes to improve quality.
• Customers – Users and Management
• TQM impacts systems analysts on at least two fronts.
What is a user?

13
 • First, the very nature of systems analysis encourages analysts to • Competition became global with emerging industrial nations
SYSTEMS ANALYSIS

look for business quality problems. offer lower cost or higher quality alternatives to many products.
• The two most important questions in the analyst’s repertoire • Most businesses have been forced to reorganize to compete
are ‘why’ and ‘why not.’ globally
• Second, systems analysis and design provides the specifications • Systems analysts are affected by the following:
for the #1 quality problem in modern information systems • Information systems and computer applications must be
buggy software. internationalized.
• Incomplete and inconsistent specifications from analysts are a • They must support multiple languages, currency exchange rates,
significant contributor to poor software quality. international trade regulations, accepted business practices
Business Process Redesign (BPR) (which differ in different countries), and so forth.
• Total quality management has forced many businesses to • Most information systems ultimately require information
radically rethink and redesign their fundamental business consolidation for the purpose of performance analysis and
processes. decision-making.
• Business process redesign is the study, analysis, and redesign Working Knowledge of Information
of fundamental business processes to reduce costs and Technology
improve value added to the business. • The systems analyst is an agent of change.
• A BPR project begins with identification of a value chain, a • The systems analyst is responsible for showing end-users and
combination of processes that should result in some value to management how new technologies can benefit their business
the business. and its operations.
• The business processes are documented and analyzed in • The systems analyst must be aware of both existing and
excruciating detail. emerging information technologies and techniques.
• The business processes are subsequently streamlined for Computer Programming Experience and
maximum efficiency. Expertise
• The new business processes are analyzed for opportunities for
• A systems analyst must know how to program because they
further improvement through information technology.
are the principle link between business users and computer
• Systems analysts figure prominently in BPR because: programmers.
• Systems analysts are often included in BPR projects because • It is wrong to assume that a good programmer will become a
their ‘system’ perspective is valued. good analyst or that a bad programmer could not become a
• The skill competencies for BPR and systems analysis and design good analyst.
are somewhat similar. • Most systems analysts need to be proficient in one or more
• A typical BPR project identifies several opportunities for new high-level programming languages.
and revised computer applications (which systems analysts • Historically, the language of choice has been COBOL for
facilitate). business applications, but many organizations are shifting to
Continuous Process Improvement (CPI) visual programming languages or to object-oriented
programming languages .
• Another TQM related trend is continuous process
improvement. • The reasons for the shift are as follows:
• Continuous process improvement is the continuous • The transition to graphical user interfaces.
monitoring of business processes to affect small but measurable • The desire to downsize applications from the mainframe to
improvements to cost reduction and value added. networks of PCs.
• In a sense, CPI is the opposite of BPR. • The pressures to improve productivity in applications
• BPR is intended to implement dramatic change. development through rapid, iterative prototyping and the reuse
of programming modules called objects and components.
• CPI implements a continuous series of smaller changes.
• Visual and object-oriented programming requires a completely
• Another TQM related trend is continuous process
different style of program design, construction, and testing.
improvement.
• Continuous process improvement is the continuous General Business Knowledge
monitoring of business processes to affect small but measurable • The systems analysts are expected to immerse themselves in
improvements to cost reduction and value added. the business and be able to specify and defend technical
• In a sense, CPI is the opposite of BPR. solutions that address the bottom-line value returned to the
business.
• BPR is intended to implement dramatic change.
• Systems analysts should be able to communicate with business
• CPI implements a continuous series of smaller changes. experts to gain knowledge of problems and needs.
Globalization of the Economy

14
• It is not uncommon for systems analysts to develop so much • Systems analysts must be very careful not to tell sensitive and

SYSTEMS ANALYSIS
expertise over time they move out of information systems private data and information about customers, suppliers,
and into the user community. employees with the wrong people.
Problem-Solving Skills • Systems analysts must not take (or sell) designs and programs
they developed to another company.
• The systems analyst must have the ability to take a large business
problem, break that problem down into its component parts, • Systems analysts have a moral obligation to set a good example
analyze the various aspects of the problem, and then assemble for end-users and management, especially in the area of software
an improved system to solve the problem. copyrights.
• The systems analyst must learn to analyze problems in terms Systems Analysis and Design Skills
of causes and effects rather than in terms of simple remedies. • All systems analysts need thorough and ongoing training in
• The systems analyst must be well organized. systems analysis and design.
• System analysts must be able to creatively define alternative • Systems analysis and design skills can be conveniently factored
solutions to problems and needs. into three subsets:
Preparing For a Career as a Systems • Concepts and principles
Analyst • Tools
Interpersonal Communications Skills • Techniques
• The systems analyst must be able to communicate effectively, Summary
both orally and in writing.
System Analysts
• The systems analyst should have a good command of the Systems analysts are people who understand both business and
English language. computing. Systems analysts study business problems and
• Almost without exception, communications skills, not technical opportunities and then transform business and information
skills, prove to be the single biggest factor in career success or requirements of the business into the computer-based information
failure. systems and computer applications that are implemented by
• Systems analysts work in teams composed of IS professionals, various technical specialists including computer programmers.
end-users, and management. Business needs for System Analyst
• Being able to cooperate, to comprise, and to function as part The system analyst bridges the communications gap between those
of a team, is critical for success in most projects. who need the computer and those who understand the technology.
• Because development teams include people with dramatically Tips for a career as system analyst
different levels of education and experience, group dynamics is Good Communication skills, Flexibility and adaptability, system
an important skill to develop. analysis and design skills
Flexibility and Adaptability Questions
• No two systems development projects encountered by a systems Why we need a system analyst?
analyst are identical. 1
• There is no single, magical approach or solution applicable to 2
systems development.
3
• Successful systems analysts learn to be flexible and adapt to
4
special challenges or situations presented by specific systems
development projects. 5
• The systems analyst must be able to recognize when variations What are the major roles of system analyst?
upon (or single-instance exceptions to) development standards 1
are necessary and beneficial to a particular project. 2
• The systems analyst must be aware of the implications of not 3
following the standards.
4
Character and Ethics 5
• The nature of the systems analyst’s job requires a strong character Why do business need system analyst?
and sense of ethics.
1
• Ethics is a personal character trait in which an individual(s)
understands the difference between ‘right’ and ‘wrong’ and 2
acts accordingly. 3
• Systems analysts must be very careful not to share their 4
organization’s sensitive and secret information with others, 5
either within or outside the organization.

15
 Explain about modern business trends and implications for
SYSTEMS ANALYSIS

system analyst.
1
2
3
4
5
Give some tips to become a system analyst(career).
1
2
3
4

5
What qualities you look for in a good Systems Analyst.
References
Awad, Elias M.
Systems analysis and design
New Delhi : Galgotia Publications, 1997
Hoffer, Jeffrey A.
Modern systems analysis and design
2nd ed. Delhi : Pearson Education Asia, 2000
Hawryszkiewycz, Igor
Introduction to systems analysis & design
4th ed. New Delhi : Prentice Hall of India, 2002
Refer to Website address
http://www.sce.carleton.ca
http://www.wiwd.uscourts.gov
http://www.masi.com

Notes

16
 LESSON 04:

SYSTEMS ANALYSIS
ELEMENTS OF SYSTEMS

Topics Covered • The processor is the element of a system that involves the
Elements of systems actual transformation of input into output.

Objectives • Processors may modify the input totally or partially depending

on the specifications of the output.
Upon completion of this Lesson, you should be able to:
• This means that as the output specifications change, so does
• Explain about the various elements of a system the processing.
• Discuss the attributes with the elements. Control
Elements of a system: • The control element guides the system.
Recall about the role of system analyst…..System analysts operate
in a dynamic environment where changes are a way of life. The
• Management as a decision-making body controls the inflow,
handling, and outflow of activities that affect the business.
environment may be a business firm, a business application, or a
computer system. Feedback
To reconstruct a system the following key elements must be • Control in a dynamic system is achieved by feedback.
considered: • Feedback may be positive or negative, routine or informational.
• Outputs • Positive feedback reinforces the performance of the system. It
• Inputs. is routine in nature.
• Processor(s). • Negative feedback generally provides the controller with
• Control. information for action.
• Feedback. Environment
• Environment. • The environment is the supra system within which an
• Boundaries and interface. organization operates.
• The organization environment consists of vendors,
Outputs
competitors, and others, which provides constraints and
• A major objective of a system is to produce an output influences the actual performance of the business.
• The output may be goods, services or information it should Boundaries and Interfaces
satisfy the expectations of the user.
A system should be defined by its boundaries-the limits that
• Outputs are the outcome of processing. identify its components, processes, and interrelationships when it
Inputs interfaces with another system.
• Inputs may be material, human resources, information that Elements of a System and Their
enters the system for processing. Attributes
How to Use This Checklist
• What follows is essentially a checklist of elements of systems
and the attributes that these elements may have.
• Most systems have all of the seven major elements, but not all
the attributes are necessarily relevant to every system.
• This checklist has been prepared for the use of people engaged
in the kind of careful analysis of systems, existing or planned,
that is implied by the label “systems analysis.”
• As a systems analyst works his or her way through the many
aspects of a typical system that is being studied (i.e., analyzed
and/or designed), the analyst can use the attributes in the
checklist as reminders of questions that need to be asked about
the aspects under study.
Types of Elements
• Data.
Processor (s)

17
 • Equipment. • Reliability: includes preventive maintenance, backup alternatives,
SYSTEMS ANALYSIS

• Personnel. recovery from breakdown)

• Data Vehicles. • Modifiability
Physical requirements: light, power supply, weight, size, noise, air-
• Information Stores.
conditioning (temperature and humidity) needs
• Procedures and Programming.
• Location, and provision for possible need to move equipment
• Training. in future
Data: The Ingredients Of The information Future availability of this type of equipment? of equipment
that the system uses, processes, and/or performing the same function(s)?
produces • Interface with users and/or operators
Attributes to be Considered: • Cost: lease, purchase, maintenance (including comparison of
• Unambiguous name: Does each type of data have an the costs of maintenance on purchased equipment vs. the costs
unambiguous name within the system? of leasing)
• Relevance to system tasks: To which task(s) is each type of data • Warranties and maintenance arrangements
relevant? is the type of data under consideration relevant to • Security (against accidental and/or willful damage)
only one task or to two or tasks? Data Vehicles: Databases, Files, etc.
• Source: What is the source of this type of data? what is the
Attributes to be Considered
reliability of the source? what is the authenticity of the source?
Note: Attributes in this category need to be checked against those
• Processing needed of personnel and equipment, since data vehicles share many
• Destination attributes with those categories.
• Logical relationships, if any: E.g., have both the invoice for the • Degree of aggregation: how many items are handled together?
book and the physical book arrived? • Format (for both human and machine use): machine coding;
Personnel: Users And Operators human coding (e.g., maps, charts, tables, prose)
Attributes to be considered: • Timeliness: how up-to-date must the data be? are only current
data desired? or current data plus historical data (e.g., to show
• Functions performed by humans: What functions are trends)?
performed by humans? should be performed by humans?
• Selection criteria: all data? summary data? exceptions only? how
• Human-decision points: stated vs. actual filtered?
• Nature of human decisions: Could some of the decisions be • Initiation or access: routine? when and as scheduled? as
made programmatically? Could some of the decisions be made
accumulated? on demand only? who initiates access?
by lower-level staff members?
• Transudation: mechanism(s) involved in changing the form
• Authority and information links with other personnel, both of data (microcomputer, computer printer, typewriter, terminal,
formal and informal
copier, camera, etc.)
• Extra-system responsibilities of staff members: committees • Correctness: what are the chances for error? how can errors be
assigned to? community involvement?
detected and corrected? how much error is tolerable?
• Attitudes toward system and fellow workers, especially toward
• Cost: physical costs of vehicle? costs of preparing data in
fellow workers as grouped by departments or other
vehicle?
administrative units
• Appropriateness of data vehicle to data items?
• Reliability
• Retention and security
• Turnover
• Source, handler(s), and destination
Equipment: Machinery And Other
• Relation to other data vehicles
Physical Equipment
Attributes to be Considered:
Information Stores: Disk Drives, Book
Collections, World-wide Web Sites, Tape
• Functions performed by machines: What functions are Cartridges, Etc.
performed by machines? should be performed by machines?
Attributes to be Considered
• Machine-decision points
• Size, measured in various ways
• Data-storage size
• Input and output rates desired and/or expected
• Data input and output rates
• Growth rate expected
• Format requirements
• Logical format(s) used
• Compatibility
• Physical format(s) used
• Equipment needed for storage

18
• Equipment needed for input and output Elements of a system

SYSTEMS ANALYSIS
• Location • Outputs
• Permanence: what happens if lost? Security measures? • Inputs.
• Accessibility and privacy considerations • Processor(s).
• Importance or value (cost) • Control.
• Replacement and/or backup • Feedback.
Procedures And Programming • Environment.

Attributes to be Considered • Boundaries and interface.

Interpret functions in terms of specific sequences of tasks to be Elements of a system & the attributesv
performed by • Data.
• Organizational units, existing or proposed • Equipment.
• Persons • Personnel.
• Equipment • Data Vehicles.
• Detail procedures for personnel in terms of • Information Stores.
• Steps in processing • Procedures and Programming.
• Decision points • Training.
• Organizational responsibilities
Questions
• Individual responsibilities . With the help of a system (any real example) explain the key
Detailed procedures for use of equipment (e.g., specifications for elements of that system.
computer programs) in terms of • Outputs
• Steps in processing • Inputs.
• Decision points • Processor(s).
• Organizational responsibilities • Control.
• Individual responsibilities . • Feedback.
Training: System staff and system users • Environment, Boundaries & Interfaces
Attributes to be Considered Explain about the elements of a system and the attributes of the
• Skills needed: internally acquired? Externally acquired? system with a real example.
• Knowledge needed: internally acquired? Externally acquired? 1
• Information handled in performing the task 2

• Definition of externally acquired skills and knowledge (e.g., 3

qualifications for being hired for the task) 4
• Definition of skills and knowledge to be provided though 5
internal training Can you have a viable system without feedback? Explain.
• Quantities of training needed, as an effect of turnover and of 1
system rate of change 2
• Possibilities of cross training or re-training of present skills 3
• Procedures for providing training, including staff needed and 4
equipment needed
5
• Training to be provided by manufacturers of equipment or
vendors of software systems. References:
Review Check List

19
 Heuring, Vincent P.
SYSTEMS ANALYSIS

Computer systems design and architecture

Delhi : Pearson Education Asia, 1997
Whitten, Jeffrey L.
Systems analysis and design methods
5th ed. New Delhi : Galgotia Publications, 2001
Shelly, Gary B.
Systems analysis and design
3rd ed. New Delhi : Galgotia Publications, 1999
Awad, Elias M.
Systems analysis and design
New Delhi : Galgotia Publications, 1997
Hoffer, Jeffrey A.
Modern systems analysis and design
2nd ed. Delhi : Pearson Education Asia, 2000
Sarkar, A.K.
Systems analysis, data processing and
quantitative techniques
New Delhi : Galgotia Publications, 1997
Hawryszkiewycz, Igor
Introduction to systems analysis & design
4th ed. New Delhi : Prentice Hall of India, 2002
Refer to Website address
http://www.sce.carleton.ca
http://www.wiwd.uscourts.gov
http://www.umsl.edu

Notes

20
 LESSON 05:

SYSTEMS ANALYSIS
CHARACTERISTICS OF A SYSTEM

Topics Covered What is interaction?

• ·Characteristics of a system
• Example of an organization
• Integrated information system
Objectives
Upon completion of this Lesson, you should be able to:
• Discuss with the real example about the characteristics of a
system.
• Explain about information system.
Characteristics of a system
The system definition suggests some characteristics that are present
in all systems: • Interaction refers how each component functions with other
• Organization components of the system.

• Interaction • For example in an organization purchasing must interact with

production, advertising with sales, and payroll with personnel.
• Interdependence
• In a computer system, the central processing unit (CPU) must
• Integration interact with the input device to solve a problem. The main
• Central objective memory holds programs and data that the arithmetic unit uses
Organization for computation. The interrelationship between these
components enables the computer to perform.
What is an organization?
Interdependence
• “Organizations tell about structure and order”
• Interdependence means that parts of the organization or
• Organization is the arrangement of components, which helps
computer system depend on one another .One subsystem
to achieve objectives.
depends on the input of another subsystem
• For example in the design of business system the hierarchical
• Each of the top inner circles represents major subsystems of a
relationships shown below in the figure (Organization structure
production firm.
An Example) starting with the president on top and downward
blue collar workers represents the organization structure. • The personnel subsystem consists of subsystems such as
benefits, health and safety and employment.
Organization Structure an Example
Major Subsystem of a production firm (Higher-
Level Subsystem)

President Formal
Organizational
Positions

Vice President Vice President Vice President

Sales Production Accounting

Lines of
Authority
Department Head Department Head
Assembly Painting

Workers Workers • No subsystem can function in isolation because it is dependent

on the data (inputs) it receives from other subsystem to perform
Interaction its required tasks.

21
 • Interdependence is illustrated by the activities and support of
SYSTEMS ANALYSIS

system analyst, programmers, and the operations staff in a

computer center.
• A decision to computerize an application is initiated by the
user, analyzed and designed by the analyst, programmed and
tested by the programmer, and run by the computer operator.
Task interdependence in a computer based
subsystem

User
Area System Analysis Programming Operations

Integration
Ø Integration refers to the holism of systems.
Ø Integration is concerned with how a system is tied together.
Ø It means that parts of the system work together within the
system even though each part performs a unique function.

Central objective
The last characteristics of a system are its central objective. Objective • The above figure is an integrated information system designed
may be real or stated. The stated objective may be a real objective. to serve the needs of authorized users (department heads,
Example managers, etc.) for quick access and retrieval via remote terminals.
To illustrate these system characteristics, Figure above named Major The interdependence between the personnel subsystem and
Subsystem of a production firm( Higher-Level Subsystem) the organization’s users is obvious.
• Shows three levels of subsystems. Each of the top inner circles • In summary, no subsystem can function in isolation because it
represents a major subsystem of a production firm. is dependent on the data (inputs) it receives from other
subsystems to per- form its required tasks. Interdependence is
• The personnel subsystem, in turn, may be viewed as a system further illustrated by the activities and support of systems
that consists of subsystems such as benefits, health and safety,
analysts, programmers, and the operations staff in a computer
and employment. Health and safety as a key personnel
center.
subsystem consists of lower-level elements that are considered
vital in personnel operation. • A decision to computerize an application is initiated by the
user, analyzed and designed by the analyst, programmed and
• Each element may he represented by a computer-based package tested by the programmer, and run by the computer operator.
or is part of a human resource database that provides
information on unemployment, insurance benefits, and the As shown in Figure below, none of these persons can perform
like. properly without the required input from others in the computer
center subsystem.
Integrated Information system

22
Review Questions 4. Who participate in system development? Please tell the role of

SYSTEMS ANALYSIS
1. From your understanding of this lesson, do you need a each of them.
computer to do systems analysis? Discuss. 5. What is system development life cycle? What are its
1 components? Which part in the life cycle does each of the
participating system developers handles?
2
6. From what perspectives are the system requirements viewed?
3
7. What are the purposes of system survey? Please tell several
4
popular system survey methods.
5
8. Why is survey report necessary? What is an adequate and detail
2. Take an organization with which you are familiar and examine survey report like?
the following:
References
a. Primary subsystems.
Heuring, Vincent P.
b. Characteristics.
Computer systems design and architecture
c. Elements.
Delhi : Pearson Education Asia, 1997
d. Purpose.
Whitten, Jeffrey L.
1 Systems analysis and design methods
2 5th ed. New Delhi : Galgotia Publications, 2001
3 Shelly, Gary B.
4 Systems analysis and design
5 3rd ed. New Delhi : Galgotia Publications, 1999
1. List the parts and functions of the following systems: Awad, Elias M.
a. Microcomputer. Systems analysis and design
b. Stapler. New Delhi : Galgotia Publications, 1997
c. Your business school or department. Hoffer, Jeffrey A.
Modern systems analysis and design
1
2nd ed. Delhi : Pearson Education Asia, 2000
2
Sarkar, A.K.
3
Systems analysis, data processing and
4
quantitative techniques
5
New Delhi : Galgotia Publications, 1997
4. Consider an automobile and a hospital as two systems. Identify
Hawryszkiewycz, Igor
the following as an input and/or output for each system:
Introduction to systems analysis & design
a. Batteries.
4th ed. New Delhi : Prentice Hall of India, 2002
b. Cured patients.
Refer to Website addres
c. Doctors.
http://www.sce.carleton.ca
d. Driver’s performance.
http://www.wiwd.uscourts.gov
e. Drugs.
http://www.umsl.edu
f. Gasoline.
g. Information.
h. Motion.
i. A patient who died.
j. Tires.
k. X-ray machine
Questions
1. What is system, give some definitions of system?
2. How do you distinguish natural systems and man-made
systems?
3. Please list some automated systems and the rules to build
them up.

23
 LESSON 06:
SYSTEMS ANALYSIS

INTRODUCTION TYPES OF SYSTEM

Topics Covered characteristics of familiar living systems can be used to help

• Types of System illustrate and better understand man-made systems.
• Introduction, The living systems, whether at the level of the cell, the organ,
the organism, the group, the organization, the society, or the
• Automated system
supranational system, all contain the 19 subsystems:
• General principles of a system
1. The reproducer, which is capable of giving rise to other systems
• Physical or Abstract system similar to the one, it is in.
Objectives 2. The boundary, which holds together the components that
Upon completion of this Lesson, you should be able to: make up the system, protects them from environmental
• Discuss the various types of system stresses, and excludes or permits entry to various sorts of
matter-energy and information.
• Differentiate between nature system and man made system
3. The ingestor, which brings matter-energy across the system
• Explain about automated system boundary from its environment.
• Explain about physical system and abstract system. 4. The distributor, which carries inputs from outside the system
Types of System or outputs from its subsystems around the system to each
Before reading this lesson Recollect what is a system? And who is component.
a system analyst? 5. The converter, which changes certain inputs to the system into
Now let us see about the types of system forms more useful for the special processes of that particular
• There are many different types of systems, but indeed, virtually system.
everything that we come into contact with during our day-to- 6. The producer, which forms stable associations that endure for
day life is either a system or a component of a system (both). significant periods among matter-energy inputs to the system
It is useful to organize different kinds of systems into useful or outputs from its converter, the materials synthesized being
categories. or growth, damage repair, or replacement of components of
the system, or for providing energy for moving or constituting
• Because our ultimate focus is on computer systems, we will the system’s outputs of products or information markets to
divide all systems into two categories: natural systems and
its suprasystem.
man-made systems.
7. The matter-energy storage subsystem, which retains in the
Natural systems system, for different periods of time, deposits of various sorts
• There are a lot of systems that are not made by people: they of matter-energy.
exist in nature and, by and large, serve their own purpose. 8. The extruder, which transmits matter-energy out of the system
• It is convenient to divide natural systems into two basic in the form of products or wastes.
subcategories: 9. The motor, which moves the system or parts of it in relation
• Physical systems to part or all of its environment or moves components of its
• Living systems. environment in relation to each other.

Physical systems include such diverse example as: 10. The supporter, which maintains the proper spatial relationships
among components of the systems, so that they can interact
Stellar systems: galaxies, solar systems, and so on.
without weighing each other down or crowding each other.
Geological systems: rivers, mountain ranges, and so on. 11. The input transducer, which brings markers bearing
Molecular systems: complex organizations of atoms. information into system, changing them to other matter-energy
• Physical systems are interesting to study because we sometimes forms suitable for transmission within it.
want to modify them. We also develop a variety of man-made 12. The internal transducer, which receives, from other subsystems
systems, including computer systems, which must interact or components within the system,.
harmoniously with physical systems; so it is often important 13. The channel and net, which are composed of a single route in
to be able to model those systems to ensure that we understand physical space, or multiple interconnected routes, by which
them as fully as possible. markers bearing information are transmitted to all parts of the
• Living systems encompass all of the myriad animals and plants system.
around us, as well as our own human race. The properties and

24
14. The decoder, who alters the code of information input to it We can distinguish many different kinds of automated systems,

SYSTEMS ANALYSIS
through the input transducer or internal transducer into a private but they all tend to have common components:
code that can be used internally by the system. 1. Computer hardware (CPUs, disks, terminals, and so on).
15. The associator, which carries out the first stage of the learning 2. Computer software: system programs such as operating systems,
process, forming enduring associations among items of database systems, and so on.
information in the system.
3. People: those who operate the system, those who provide its
16. The memory, which carries out the second stage of the learning inputs and consume its outputs, and those who provide
process, storing various sorts of information in the system for manual processing activities in a system.
different periods of time.
4. Data: the information that the system remembers over a period
17. The decider, which receives information inputs from all other of time.
subsystems and transmits to them information outputs that
5. Procedures: formal policies and instructions for operating the
control the entire system.
system.
18. The encoder, who alters the code of information input to it
One way of categorizing automated systems is by application.
from other information processing subsystems, from a private
code used internally by the system into a public code that can be However, this turn out not to be terribly useful, for the techniques
interpreted by other systems in its environment. that we will discuss for analyzing, modeling, designing, and
implementing automated systems are generally the same regardless
19. The output transducer, which puts out markers bearing
of the application.
information from the system, changing markers within the
system into other matter-energy forms that can be transmitted A more useful categorization of automated systems is as follows:
over channels in the system’s environment. 1. Batch system: A batch system is one which in it, the information
Keep in mind that many man-made systems (and automated is usually retrieved on a sequential basis, which means that the
systems) interact with living systems. In some cases, automated computer system read through all the records in its database,
systems are being designed to replace living systems. And in other processing and updating those records for which there is some
cases, researchers are considering living systems as components of activity.
automated systems. 2. On-line systems: An on-line system is one, which accepts
input directly from the area where it is created. It is also a
Man-made systems
system in which the outputs, or results of computation, are
Man-made systems include such things as: returned directly to where they are required.
1. Social systems: organizations of laws, doctrines, customs, and 3. Real-time systems: A real-time system may be defined as one
so on. which controls an environment by receiving data, processing
2. An organized, disciplined collection of ideas. them, and returning the results sufficiently quickly to affect the
3. Transportation systems: networks of highways, canals, airlines environment at that time.
and so on. 4. Decision-support systems: These computer systems do not
4 Communication systems: telephone, telex, and so on. make decisions on their own, but instead help managers and
5. Manufacturing systems: factories, assembly lines, and so on. other professional “knowledge workers” in an organization
make intelligent, informed decisions about various aspects of
6. Financial systems: accounting, inventory, general ledger and so the operation. Typically, the decision-support systems are
on. passive in the sense that they do not operate on a regular basis:
• Most of these systems include computers today. instead, they are used on an ad hoc basis, whenever needed.
• As a systems analyst, you will naturally assume that every system 5. Knowledge-based systems: The goal of computer scientists
that you come in contact with should be computerized. And working in the field of artificial intelligence is to produce
the customer or user, with whom you interact will generally programs that imitate human performance in a wide variety of
assume that you have such a bias. “intelligent” tasks. For some expert systems, that goal is close
• A systems analyst will analyze, or study, the system to determine to being attained. For others, although we do not yet know
its essence: and understand the system’s required behavior, how to construct programs that perform well on their own, we
independent of the technology used to implement the system. can begin to build programs that significantly assist people in
• In most case, we will be in a position to determine whether it their performance of a task.
makes sense to use a computer to carry out the functions of General systems principles
the system only after modeling its essential behavior. There are a few general principles that are of particular interest to
• Some information processing systems may not be automated people building automated information systems. They include
because of these common reasons: Cost; Convenience; Security; the following:
Maintainability; Politics. 1. The more specialized a system is, the less able it is to adapt to
Automated systems different circumstances.

Automated systems are the man-made systems that interact with 2. The more general-purpose a system is, the less optimized it is
or are controlled by one or more computers. for any particular situation. But the more the system is

25
 optimized for a particular situation, the less adaptable it will be Automated system
SYSTEMS ANALYSIS

to new circumstances. General principles of a system

3. The larger a system is, the more of its resources that must Physical system
be devoted to its everyday maintenance.
Abstract System
4. Systems are always part of larger systems, and they can
always be partitioned into smaller systems. Questions
Differentiate between the natural system and man made system.
5. Systems grow. This principle could not be true for all systems,
but many of the systems with which we are familiar do grow, 1
because we often fail to take it into account when we begin 2
developing the system. 3
Physical or Abstract system 4
Types of system 5
Discuss about the automated system. State whether it is a natural
Systems have been classified in different ways. Common
system or man made system.
classifications are
1
• Physical or Abstract System
2
• Open or closed system
3
• Man made system
4
Physical System
5
• Physical systems are tangible entities that may be static or
dynamic in operation. Give some real world examples for physical or abstract system.

• For example, the physical parts of the computer center are the 1
offices, desks, and chairs that facilitate operation of the 2
computer. 3
• They can be seen and counted; they are static. 4
• But a programmed computer is a dynamic system. 5
• Data, programs, output, and applications change as the user’s References
demands or the priority of the information requested changes.
Heuring, Vincent P.
Abstract System Computer systems design and architecture
• Abstract systems are conceptual or nonphysical entities. Delhi : Pearson Education Asia, 1997
• They may be as formulas of relationships among sets of Whitten, Jeffrey L.
variables or models. Systems analysis and design methods
• A model is a representation of a real or a planned system. 5th ed. New Delhi : Galgotia Publications, 2001
• The use of models makes it easier for the analyst to visualize Shelly, Gary B.
relationships in the system. Systems analysis and design
Review 3rd ed. New Delhi : Galgotia Publications, 1999

Various types of systems Awad, Elias M.

Systems analysis and design
Natural System
New Delhi : Galgotia Publications, 1997
§ There are a lot of systems that are not made by people: they
Hoffer, Jeffrey A.
exist in nature and, by and large, serve their own purpose.
Modern systems analysis and design
§ Physical systems
2nd ed. Delhi : Pearson Education Asia, 2000
§ Living systems.
Sarkar, A.K.
Man-made System Systems analysis, data processing and quantitative
Man-made systems include such things as: techniques New Delhi : Galgotia Publications, 1997
1. Social systems Hawryszkiewycz, Igor
2. An organized, disciplined collection of ideas. Introduction to systems analysis & design
3. Transportation systems. 4th ed. New Delhi : Prentice Hall of India, 2002
4 Communication systems Refer to Website address
5 Manufacturing systems http://www.sce.carleton.ca
http://www.wiwd.uscourts.gov
6. Financial systems
http://www.umsl.edu

26
 LESSON 07:

SYSTEMS ANALYSIS
TYPES OF MODELS

Topics Covered Reasons for Modeling

System Models • Highlight problems of interest.
• Schematic model • Economical experimentation.
• Flow system models • Precision of thought.
• Dynamic system models • Solving operational problems.
• Static system models • Impossible to analyze some systems mentally since some
systems are counterintuitive; mental models are usually inexact.
Objectives
• Quantifies relationships and identifies gaps in our knowledge
Upon completion of this Lesson, you should be able to: (can be used to guide research)
• Discuss about the Schematic model • Range of variables that can be examined in actual system is
• Discuss the various categories of System model. often quite small in time and space scale
Types of models • Dynamics of actual system may preclude data collection and
observation.
What do you mean by a model?
• Iconic - physical models that are images of the real world; Systems Models
dimensions are usually scaled up or down; for example, models • The analyst begins by creating a model of the reality (facts,
of cars might be constructed and tested in a wind tunnel relationships, procedures, etc.) with which the system is
• Analog - model that substitutes one set of properties for concerned.
another; may be iconic or mathematical; electric resistance often • Every computer system deals with the real world, a problem
used as an analog of the friction of a fluid flowing in a pipe; area, or a reality outside itself. For example, a telephone switching
this approach is not as widely used as at one time - digital system is made up of subscribers, telephone handsets, dialing,
computers have allowed the development of other modeling conference calls, and the like.
techniques that have replaced analog models • The analyst begins by modeling this reality before considering
• Stochastic - probabilistic model that uses randomness to the functions that the system is to perform.
account for immeasurable factors (e.g., weather) • Various business system models are used to show the benefits
• Deterministic - model that does not use randomness but of abstracting complex systems to model form.
uses explicit expressions for relationships that may or may not The major models discussed here are schematic, flow, static, and
involve time rates of change dynamic system models.
• Discrete - model where state variables change in steps as Schematic Models
opposed to continuously with time (e.g., number of cattle in
a barn); may be deterministic or stochastic A schematic model is a two-dimensional chart depicting system
elements and their linkages. Figure in the next page shows the
• Continuous - model whose state variables change continuously major elements of a personnel information system together
with time (e.g., biomass in a field); usually sets of differential
with material and formation flow.
equations used; initial conditions required (can be difficult to
obtain for some systems!) • One of the initial steps in a modeling exercise is to organize the
elements of the system being studied in some fashion.
• Combined - model where some state variables change
continuously and others change in steps at event times; for • Schematic models provide a means of visualizing system
example, a field of hay might be modeled using a combined structure and operation without immediately trying to
approach with the biomass modeled continuously during mathematically represent the system. Such schematic models
growth and then as a discrete event when harvested can reveal redundancies and system weaknesses that can be
corrected without extensive formal analysis.
• Mathematical - abstract model usually written in equation
form • Understanding a system well enough to construct a schematic
model of its operation may be the most important benefit of
• Object-oriented - use objects that are abstractions of real world an operations engineering study. There are many types of
objects and develop relationships and actions between objects; schematic models that might be used by operations engineer.
comes from field of artificial intelligence
• Heuristic - heuristics (rules) are used to model the system;
comes from field of artificial intelligence.

27
SYSTEMS ANALYSIS

Performance Models
A performance model describes the program’s resource usage
during computing.
• Total performance
• A function from input to measures
• Typically structured
• Contributing factors
Several kinds of performance models
• Execution structure
• Typically control flow
• Resource usage
• Typically time
Flow Graph
A simple model of performance; a timed flow graph

• The schematic models attempt to organize knowledge in a

logical fashion such that time, space and structural relationships
can be easily understood
Flow System Models.
• A flow system model shows the flow of the material, energy,
and information that hold the system together. There is an
orderly flow of logic in such models.
• A widely known example is PERT (Program Evaluation and
Review Technique). It is used to abstract a real-world system in
model form, manipulate specific values to determine the critical
path, interpret the relationships, and relay them back as a control.
The probability of completion within a time period is considered
in connection with time, resources, and performance specifications

28
Problems System state

SYSTEMS ANALYSIS
• Choices, repetitions • Jobs
• Parallelism • Queuing discipline (FCFS, LCFS-PR, RR, PS, SJF, SRT, etc.)
• Locks Usage
Petri Nets • Servers as system components
A Petri net consists of • Jobs moving from one component to another
• Nodes Example
• Places P Below a simple system:
• Transitions T • Servers with queues are system’s shared resources
• Directed edges P-T or T-P • No competition for resources in queueless servers
System state • Infinite servers, delay servers
• Depicted with tokens
• Changed by a firing event
• Triggering an event
Usage
• Describing parallelism
• Describing locking
Example
Several kinds of Petri nets
• Amount of edges
• Amount of tokens
Usage of a critical resource
Performance
• Service times
• Branching probabilities
• Static values
• Several job types
The queuing discipline is essential for solvability of the model.
Extended Queuing Networks
Several locking and competition situations can’t be described by
using an ordinary queueing network.
• Extensions neccessary
• New types of nodes
• More difficult to solve
Describing performance via Petri nets
• Timed events
• Stochastic events
• Static values
Queuing networks
Queuing networks consist of
• Nodes
• Queuing servers
• Queueless servers
• Directed graphs

29
 Above: a queued resource (REQ-REL)
SYSTEMS ANALYSIS

• Dynamic service time

• More difficult to solve
and a changing node (CHG)
• may change job type
• may change job count
Other Models
There are many methods to model performance. Their basis is
usually
• A partial order (network)
• Queuing networks
• Petri nets
• Task graphs
• State machine
• SDL (CCITT)
• State diagrams
• Flow diagrams
• Process algebra
• CCS
• CCP
• LOTOS
Network-based models are usually represented in a graphical form;
several other models have a source-code-like representation.
Software Modelling Input Models
Software complexity presents a problem Besides execution, input must be modelled
• Immense number of operations • Performance figures are always for some input
• Mostly insignificant • Execution models are often related to a certain input class
• Important operations (perhaps implicitly) Input model characteristics depend on usage
• Locking • Declarative
• Queuing • Procedural
• I/O Several inputs to execute on a model
Important locations hidden under other structure • Real
• Abstractions • Syntethic
• Modularity • Artificial
• Parallelism Often the same program has several input classes
How to reveal the significant parts and clear away the rest? • Clustering the input classes
Example Execution Networks • Classing and search algorithms
One way to deal with the problem are heterogenous and hierarchical • Minimal spanning tree
models
• AQ, ID3, CART, PAC
• Execution model (below: execution network)
• Neural nets
• System model (below: queueing network)
• Genetical algorithms
• Connection between the two (transformation analysis)
Statistical Input Models
• Analytical models
• Simulation models
Statistical models describe the input sample space
• Possible inputs
• Probability of each

30
The model may be used in several ways in a Analytical Solution

SYSTEMS ANALYSIS
simulation Analytical solution of net models is often based on statistical
• Continuous analysis.
• One-shot inputs • Static analyysi
Example G (n, p) • Model states
G(n, p) is a commonly used input model in the analysis of network • State transformations
algorithms Markov state graph
• Statistical
• Efficiently executable
• One-shot
G (n, p) chooses a single net from the set of all
graphs
• N nodes in the graph
• Probability of each edge is p
• Expected value of edges p*n^2 (directed) A probability for each state (steady-state analysis).
Properties • Solve the equations related to the state graph
• Suitable for local algorithms • Difficult to solve
• Unsuitable for structural inspection In practice more efficient methods are used
• A giant component in the graph • Also approximate methods
Model Interpretation Simulation
The measurement of performance as a function of input
In simulation, the model is executed
parameters is what should be solved from a performance model
• Performance goal • Dynamical analysis
• Differnet views on the same model • Simulation program
• Can be solved well, but requires computation
Simulation can be
• Continuous (steady-state)
• Repetition of experiments with parameter variations
Tools needed for
• Statistical processing
• Input generation
• System warm-up
Result consistent with reality?
• Verification
• Validation
Simulation Example I
Job-based simulation
A sample from a program
• Queuing network model
• Steady-state
job(char *name) {
create(name);
while (completions < warm_up + measure) {
For instance, a demand on response time may limit throughput. reserve(cpu);
hold(10.0);
release(cpu);
if (prob() < 0.5) {
reserve(disk1);
hold(20.0);

31
 release(disk1); Review
SYSTEMS ANALYSIS

} else { Reasons for modeling

reserve(disk2); Types of system model
hold(30.0);
Schematic models
release(disk2);
} Flow system model
completion_count++; Static system model
if (completions == warm_up) Dynamic system model
reset();
} Questions
if (completions == warm_up + measure) What are system models?
set(done); 1
} 2
Simulation Example II 3
Server-based 4
The above in a different form
cpu() { 5
int job; Differentiate between static and dynamic systems.
int ndisk; What are system models?
create(“CPU”); 1
while(job_count) {
job = wait_any(enter_cpu); 2
use(fcpu, 10.0); 3
set(cpu_free); 4
ndisk = prob() < 0.5 ? 0 : 1; 5
if (num_busy(fdisk[ndisk]))
queue(disk_free[ndisk]); References
if (ndisk) Heuring, Vincent P
set(enter_disk1[job]); Computer systems design and architecture
else
Delhi : Pearson Education Asia, 1997
set(enter_disk0[job]);
} Whitten, Jeffrey L.
} Systems analysis and design methods
Computation with variables 5th ed. New Delhi : Galgotia Publications, 2001
Typical variables Shelly, Gary B.
• Time T Systems analysis and design
• Throughput X 3rd ed. New Delhi : Galgotia Publications, 1999
• Completion count C Awad, Elias M.
• Service demand D Systems analysis and design
• Job time W New Delhi : Galgotia Publications, 1997
• Job count L Hoffer, Jeffrey A.
• Utilization U Modern systems analysis and design
• Rresponse time R 2nd ed. Delhi : Pearson Education Asia, 2000
• Arrival rate lambda Sarkar, A.K.
• Service rate mu Systems analysis, data processing and quantitative
techniques New Delhi : Galgotia Publications, 1997
Hawryszkiewycz, Igor
Introduction to systems analysis & design
4th ed. New Delhi : Prentice Hall of India, 2002

32
 LESSON 08:

SYSTEMS ANALYSIS
OVERVIEW OF SDLC

Topics covered System Life Cycle

• Overview of SDLC Development Process
• Feasibility study, Software development projects are often very large projects.
• Purpose of stage of the SDLC
Objectives Requirements What is the problem?
Analysis Functions to be developed
Upon completion of this Lesson, you should be able to: Possible future extensions
Amount and kind of documentation
• Explain about Feasibility study Performance characteristics for functions
Feasibility Study
• Explain the purpose of the stages of SDLC Technical
Social
Software development Lifecycle Economic
Political
Design What is the solution?
A system model, which solves the problem for the user.

Overview Implementation How is the solution constructed?

A transformation of the design into an executable form.
System development Life-cycle Testing Is the problem solved?
Determining if the solution as constructed meets the
The six phases in the system development life cycle can be identified requirements.

by different names. Also, there are no definite rules regarding Delivery Can the customer use the solution?
Maintenance Are enhancements/changes needed?
what must be included in each of the six phases. Corrective - repair errors
Adaptive - modify software to adapt to changes in environment
What is Feasibility? Perfective - providing new functionality for new requirements
Preventive - improving the system's maintainability
Feasibility Study
• This phase determines the objectives of the feasibility study
and who this task belongs to — analysts or the project team? • A number of people work on such a project for a very long
• It lists out the steps required to complete a feasibility study, time and therefore the whole process needs to be controlled:
identifies the scope of the current system, problems and progress needs to be monitored, people and resources need to
unexploited opportunities in the current system, which may be allocated at the right point in time, etc.
be either manual or automated. • To understand system development, we need to recognize that
• It then discusses the major objectives for the new system, and a candidate system has a life cycle, just like a living cycle, just like
the various methods to gather data and determine how to use a living system or a new product.
the methods. • System analysis and design are keyed to the system life cycle.
• It also helps to estimate the costs of each possible solution, The stages are shown below
and develops estimates of the benefits and shortcomings of • The analyst must progress from one stage to another
each solution. methodically, answering key questions and achieving results in
It presents users and the management views on the above issues each stage.
and their decision of whether to commit to the analysis part of • A word of caution regarding life cycle activities: we isolate and
the project. sequence these activities for learning purposes, but in real life
This phase may be included with some related sub phases: they overlap and are highly interrelated.

Current physical model: • For example, when the analyst is evaluating an existing
operation, he/she is probably thinking about an alternative
The description of the system as it is now, including the way that would improve the system or wondering whether a
mechanisms used to accomplish tasks (e.g., people, devices). given piece of hardware would be a critical cost item to consider
Current logical model: The system description in term of for a candidate system.
functions, processes, and data with the mechanisms removed. Therefore, there can easily be overlap during any phase of the cycle.
New Logical Model: The Current Logical Model with new In fact, it may act as a basis for modifying earlier steps taken. We
features added. now describe each of these steps.
New Physical Model: The Current Logical Model with the various Recognition of Need – What Is the Problem?
processes allocated to automation, manual procedures, other One must know what the problem is before it can be solved. The
mechanisms. basis for a candidate system is recognition of a need for improving
Purpose of Stages of the SDLC information system or a procedure.

33
 • It entail looking into the duplication effort, bottleneck,
SYSTEMS ANALYSIS

inefficient existing procedures, or whether parts of the existing

system would be candidates for computerization.
• If the problem is serous enough, management may want to
System Development Life Cycle have an analyst look at it. Such an assignment implies a
Stage Key Question Result commitment, especially if the analyst is hired from the outside.

Recognition of need What is the problem opportunity Statesmen of scope and

• In larger environments, where format procedures are the norm,
the analyst procedures are the norm; the analyst’s first task is to
1 Preliminary survey/initial objectives performance criteria.
initial investigation
prepare a statement specifying the scope and objective of the
2 Feasibility study What are the user’s Technical/behavioral
problem.
Evaluation of existing Demonstrable needs? Feasibility • He/she then reviews it with the user for accuracy. At this stage,
System and procedures Is the problem worth Cost/benefit analysis only a rough “ball park” estimate of the development cost of
Analysis of alternative Solving? System scope and objective the project may be reached. However, accurate costs of he next
Candidatesystems How can the problem Statement of new scope and page - the feasibility study – can be produces.
Cost estimates Be redefined? Objective.
Impetus for System Change
3 Analysis What must be done Logical model of system • The idea for change originates in the environment or from
Detailed evaluation of To solve the problem? E.g. data dictionary, data with in the firm. Environment-based idea originates form
present system What are the facts? Flow diagram customers, vendors, government sources and the like.
Data collection Pertinent data • For example, new unemployment compensation regulations
may make it necessary to change the reporting procedure, format,
4 Design In general, how must Designing of alternative and content of various reports, as well as file structures.
General design The problem be solved? solutions
• Customer complains about the delivery of orders may prompt
specifications Specifically, how must Final cost/benefit analysis
an investigation of the delivery schedule, the experience of
Detailed design The problem be solved? Hardware specification
Specification What is the system Cost estimates]
truck drivers, or the volume of orders to be delivered.
Output Processing flow? Implementation schedule • When investigated, each of this idea may lead to a problem
Input Approval of systems by use definition as a first step in that system life cycle process.
Files Programs • Ideas for change may also come from within the organization-
Procedures Does the user approve Test plans top management, the user, the analyst).
System? Security, audit, and operating
Program construction procedures
• As an organization changes its operations or faces advances in
Actual hardware use Formal
computer technology, someone within the organization may
Testing How well do individual system test
fell the need to update existing application or improve
Unit testing programs/modules test out?
procedures. Here are some examples
Combined module How ready are programs for • An organization acquires another organization.
Testing acceptance test? • A local bank branches into the suburbs.
User acceptance Testing.
• A department spends 80 percent of its budget in one month.
5 Implementation What is the actual operation? Training program
User training Are user manuals ready? User-friendly documentation • A department is doing essentially the same work, and each
File/system conversion Are there delays in leading files? department head insists the other department should be
6 Post-implementation and User requirements met user eliminated.
Maintenance standards met satisfied user • A request for a new form discloses the use of bootleg
Evaluation Is the key system running? (unauthorized) forms.
Maintenance Should the system be modified?
Serious problem in operations, a high rate of labor turnover,
Enhancements
labor intensive activities, and high reject rats of finished goods,
also prompt top management to initiate an investigation. Other
examples are:
• A report reaches a senior vice president and she suspect the
figures.
• For example, a supervisor may want to investigate the system • The company comptroller read an IRS audit report and starts
flow in purchasing, or a bank president has been getting thinking.
complaints about the ling line in the drive –in.
• An executive read about decision support systems for sales
• This need lead to a preliminary survey or an initial investigation forecasting and it gives him an idea.
to determine whether an alternative system can solve the
• Many of these ideas lead to further studies by management
problem.
request, often funneled downward and carried out by lower
management.

34
• User-originated ideas also prompt initial investigations. 1. Statement of the problem- a carefully worded statement of

SYSTEMS ANALYSIS
• For example, a bank’s need teller has been noticing long the problem that led to analysis.
customer line in the lobby. 2. Summary of finding and recommendation-a list of the major
• She wants to know whether they are due to the computer’s finding and recommendations of the study. It is ideal for the
slow responses to inquiries, the new tellers limited training, or user who requires quick access to the results of he analysis of
just a sudden increase in bank business. the system under study. Conclusions are stated, followed by a
list of the recommendations and a justification for them.
• To what extent and how quickly a user-originated idea is
converted to a feasibility study depend on several factors: 3. Details of findings- an outline of he methods and procedures
undertaken by the existing system, followed by coverage of he
• The risks and potential returns.
objective and procedures of he candidates system. Included are
• Management’s bias toward the user. also discussion of output report, file structures, and costs and
• Financial costs and the funds available for system work. benefits of the candidate system.
• Priorities of other projects in the firm. 4. Recommendations and conclusions- Specific recommendations
• The persuasive ability of the user. regarding the candidate system, including personnel
assignments, costs, project schedules, and target dates.
• All these factors are crucial for a prompt response to a user
request for change. • After management reviews the proposal, it becomes a form
agreement that paves the way for actual design and
• A system analyst is in a unique position to detect and even implementation.
recommend change.
• This is a crucial decision point in the life cycle. Many project die
• Experience and previous involvement in the user area of here, whereas the more promising ones continue through
operations make him/her a convenient resource for idea.
implementation.
• The role and status of the analyst as a professional add credibility
to the suggestions made.
• Changes in the proposal are made in writing, depending on
the complexity, size, and cost of the project. It is simply
Feasibility Study common sense to verify change before committing the project
• Depending on the results of the initial investigation, the survey to design.
is expanded to a more detailed feasibility study. Review
• A feasibility study is a test of system proposal according to it Software Development Life Cycle(SDLC)
workability, feasibility study is a test of a system proposal
Feasibility Study
according to it workability, impact on the organization, ability
to meet user needs, and effective use of resources. Sub Phases
• It focuses on three major questions: Current Physical model
1. What are the user’s demonstrable needs and how does a Current Logical model
candidate system meet them? New Physical model
2. What resources are available for give candidate system? Is the New Logical model
problem worth solving.?
3. What is the likely impact of the candidate system on the
organization?
How well done it fit within the organization’s master MIS
plane?
• Each of these questions must be answered carefully. They
revolve around investigation and evaluation of he problem
identification and description of candidates system, specification
of performance and the cost of each system, and final selection
of the best system.
• The objective of a feasibility study is not to solve the problem
but to acquire a sense of its scope. During the study the
problem definition is crystallized and aspects of the problem
to be included in he system are determined.
• Consequently, costs and benefits are estimated with grater
accuracy at this stage. The result of the feasibility study is a
formal proposal. This is implying a report-a formal document
detailing the nature and scope of the proposed solution. The
proposal summarizes what is known what is going to be done.
Ø It consists of the following:

35
 What factors guide the choice of one process model over another?
SYSTEMS ANALYSIS

1
Software Development Life Cycle(SDLC) 2
Feasibility Study
3
Sub Phases
4
Current Physical model
Current Logical model
5
New Physical model Describe the phases of System Development Life Cycle.
New Logical model What qualities you look for in a good Systems Analyst.
Purpose of SDLC Why is life cycle needed for the development of information
Requirements Analysis What is the problem? systems?
Feasibility Study
Technical
What is the difference between analysis and design? Can one begin
Social to design without analysis? Why?
Economic
Political References
Design What is the solution? Heuring, Vincent P.

Implementation How is the solution constructed?

Computer systems design and architecture
. Delhi : Pearson Education Asia, 1997
Testing Is the problem solved?
.
Whitten, Jeffrey L.
Delivery Can the customer use the solution? Systems analysis and design methods
Maintenance Are enhancements/changes needed? 5th ed. New Delhi : Galgotia Publications, 2001
Corrective
Adaptive Shelly, Gary B.
Perfective
Preventive Systems analysis and design
3rd ed. New Delhi : Galgotia Publications, 1999
Awad, Elias M.
Systems analysis and design
Questions New Delhi : Galgotia Publications, 1997
What are strategies used in industry to model the software Hoffer, Jeffrey A.
development process? Modern systems analysis and design
1 2nd ed. Delhi : Pearson Education Asia, 2000
2 Sarkar, A.K.
3 Systems analysis, data processing and
4 quantitative techniques
5 New Delhi : Galgotia Publications, 1997
What are the similarities and differences between these universal Hawryszkiewycz, Igor
models?
Introduction to systems analysis & design
1
4th ed. New Delhi : Prentice Hall of India, 2002
2
S. Pfleeger (1991) Software Engineering. New York: Macmillan.
3
Pressman (1997) Software Engineering: A Practitioners Approach.
4 New York:McGraw-Hill.
5 Van Vliet, Hans (1993) Software Engineering: Principles and
What processes or tasks span phases of the lifecycles? Practice. Chichester: John Wiley & Sons.
1
2
3
4
5

36
 LESSON 09 :

SYSTEMS ANALYSIS
STAGES OF SDLC

Topics covered Classical Waterfall

Stages of SDLC,· 1 Waterfall Model
Waterfall model·
Characteristics Waterfall model
Objectives
Upon completion of this Lesson, you should be able to:
Explain the stages of SDLCExplain the Simple,
Elaborated and Alternate Waterfall model.
Stages of the SDLC
Introduction to System Development Lifecycle
• Software development has hit something of a crisis - we fail to
deliver software that meets user expectation.
• However by employing disciplined techniques throughout the
development of software and by employing a philosophy of
co-ordination, control and management through out the
development lifecycle of a software project enhanced standards
may be achieved.
• The aim is to provide discipline to the development of software
- a structured framework against which development takes place
is advocated.
• A model of the process of systems development is used by
organizations to describe their approach to producing computer
systems.
• Traditionally this has been a staged (or phased) approach,
known as the System Life Cycle or System Development
Life Cycle (SDLC).
An example of a SDLC is given below
2 Elaborated Waterfall

STAGE TASK OUTCOMES

Problem Definition Establish what the problem is Statement of requirements

Establish scope & objectives;

Feasibility Study determine whether project is Feasibility study report
viable

Define what constitutes a solution Logical model of the

Analysis
to the problem solution

Determine ways of solving the Costing and high level

Outline Design
problem and choose one design of the system

Specify how the system will be

Detailed Design System specifications
implemented

Write the program & procedures; Working system &

Implementation
Install & test system documentation

Maintenance Provide support & enhancements Working system

Alternate Waterfall Model

37
SYSTEMS ANALYSIS

Classic System Development Lifecycle -

Version 2
Feasibility
• Is the project technically, operationally, financially and legally
feasible ?
• The feasibility study is used to determine if the project should
The lifecycle approach is derived from the waterfall model of system get the go-ahead.
development described by Royce in 1970, a simplified version of • If the project is to proceed the feasibility study will produce a
which is given below project plan and budget estimates for the future stages of
development.
Analysis
• Gather the requirements for the system.
• This stage includes a detailed study of the business needs of
the organization.
• Options for changing the business process may be considered.
Design
• This focuses on high level design (what programs are we going
to need and how are they going to interact), low level design
(how the individual programs are going to work), interface
design (what are the interfaces going to look like) and data
design (what data are we going to need).
Implementation
• The designs are translated into code.
• Computer programs may be written using a conventional
programming language to a fourth generation language (4GL)
or an application generator.
Test
• The system is tested. Normally programs are written as a series
of individual modules - these should be subject to separate
and detailed test.
• The system is then tested as a whole - the separate modules are
brought together and tested as a complete system.
Classic System Development Lifecycle -
Version 1 • The system needs to be tested to ensure that interfaces between
There are now many variations on the theme of the waterfall modules work (integration testing), the system works on the
model, an alternative is presented below: intended platform and with the expected volume of data
(volume testing) and that the system does what the user requires
(acceptance/beta testing).

38
Maintain Questions

SYSTEMS ANALYSIS
• Inevitably the system will need maintenance - hopefully we What is the system development life cycle? How does it relate to
haven’t got anything wrong but people will want extra things system analysis?
added or existing things changed over time. 1
• This paradigm is the oldest and most widely used approach to 2
system development, it was developed by Royce in 1970. 3
Waterfall Approach Characteristics 4
• Although there are many variations on the theme of the lifecycle, 5
each approach has its own characteristics: How would an analysis determine the user’s needs for a system?
• Specific activities, techniques and outcomes are associated with Explain.
each stage; 1
• Progression between stages is orderly and proceeds in a linear 2
fashion;
3
• Viewed to be a process driven by technicians;
4
• Monitoring and control takes place at the end of each stage;
5
• Involvement of end users is typically passive and principally in
Where do the ideas for a proposed system originate? To what
the analysis stage.
extend does the analyst assist in this regard?
• The lifecycle model assumes that systems will be constructed
from scratch by a team of IS professionals either in-house of 1
within a software house. 2
• Other approaches exist, namely: 3
• Those based on alternative lifecycles e.g. prototyping, 4
evolutionary development, spiral model; 5
• Those which have a different philosophical basis e.g. soft Distinguish between initial investigation and feasibility study. In
systems and sociotechnical approaches; what way are they related?
• The use of package software to address application areas; 1
• The development of applications by end users. 2
• A number of these alternative approaches will be examined 3
later in the course. However, our initial focus will be on the 4
Waterfall Model of system development.
5
Problems with the Waterfall Approach Why is a system proposal so crucial for system design? Explain.
• Real projects rarely follow the sequential process illustrated - 1
iteration through the cycles is required.
2
• It is often difficult for the customer to state all requirements
explicitly at the start of the development lifecycle. 3

With this approach, the customer must be patient - a working 4

version is not usually available until late in the development lifecycle. 5
Review List the drawbacks of the evolutionary software life cycle in terms
of small software projects.
Stages of SDLC
What is a code? List nd describe each of the common coding
Example of SDLC
schemes.
Waterfall model
Characteristics of waterfall model
Problems of waterfall model

39
 References
SYSTEMS ANALYSIS

Heuring, Vincent P.
Computer systems design and architecture
Delhi : Pearson Education Asia, 1997
Whitten, Jeffrey L.
Systems analysis and design methods
5th ed. New Delhi : Galgotia Publications, 2001
Shelly, Gary B.
Systems analysis and design
3rd ed. New Delhi : Galgotia Publications, 1999
Awad, Elias M.
Systems analysis and design
New Delhi : Galgotia Publications, 1997
Hoffer, Jeffrey A.
Modern systems analysis and design
2nd ed. Delhi : Pearson Education Asia, 2000
Sarkar, A.K.
Systems analysis, data processing and
quantitative techniques
New Delhi : Galgotia Publications, 1997
Hawryszkiewycz, Igor
Introduction to systems analysis & design
4th ed. New Delhi : Prentice Hall of India, 2002
S. Pfleeger (1991) Software Engineering. New York: Macmillan.
Pressman (1997) Software Engineering: A Practitioners Approach.
New York:McGraw-Hill.
Van Vliet, Hans (1993) Software Engineering: Principles and
Practice. Chichester: John Wiley & Sons.

Notes

40
 LESSON 10 :

SYSTEMS ANALYSIS
SYSTEM APPROACHES

Topics covered • The spiral model follows the same breakdown into stages, but
• System approaches takes an incremental approach to systems development.
• System Requirements • Typically, a system is divided into smaller sub-sets for
development and delivery.
• Cost Benefit Analysis
This provides functionality to end-users at regular intervals, rather
Objectives than at the end of a waterfall development.
Upon completion of this Lesson, you should be able to: • It is also common in iterative development for highly skilled
Explain about System approaches developers to model systems with stakeholders, the design
Explain about System Requirements and implement them, rather than assign the stages to different
Explain about Cost Benefit Analysis departments or groups.
• Effective use of the spiral approach to system development
System approach
can deliver systems quickly and ensure user involvement,
• Approaches to systems development, in professional especially when prototypes are part of the development
organizations, usually follow one of two basic models: the approach.
waterfall model or the spiral model.
System requirements
• The Waterfall model is the basis of most of the structured
development methods that came into use from the 1970s • The system is developed base on the requirements of the
onwards. It provides a framework for planning top – down system itself (to help manage an organization) and technical
systems development. requirements.

• The development flows down a number of successive stages • There are different view points of what information system
are typically: automatization is like, however, we can classify them into 3
main groups:
• Systems analysis;
• View point of the system that will be developed,
• Systems design;
• Information expert’s view point and
• Systems build and test;
• User’s one.
• Systems introduction and transition;
• These points of view often conflict with one another, at the
• Maintenance of production status systems. same time we are required to build up a successful system in
• The Spiral model of systems development proposed by Barry which the system, information experts and end users share the
Boehm, has become popular is basis for iterative systems same view point.
development. • Information system is a system that collects information,
manages them and creates information products for its users.
• The following part will discuss requirements of system,
information experts and users.
The system’s requirements
• Suitable with the general strategies: Small changes in the
organization’s development may result in bigger impacts on
the information system’s requirements. Therefore, during the
system development process, these requirements should be
regularly checked for its suitability with the general strategies.
• Supporting decision maker: Together with hands-on experience,
knowledge and anticipating ability, information system plays
an important role in supporting decision making process;
• Competition edge: The more competitive the environment,
the more demand for better systems.
• Return on Investment: A new information system needs to
show financial benefits it can bring, because decisions on
investment, development costs and operation costs are based
on financial analysis;

41
 More advanced evaluation techniques can be applied. These Besides the issues of the three viewpoint groups, we would also
SYSTEMS ANALYSIS

techniques take into consideration issues such as customer like to remind you of the following popular issues:
support, organizational effectiveness, risk, etc. • Incompatibility: Applications developed in different
• Overhead control: human resource change will influence staff environments are often incompatible. Computers of different
number, staff skills and workload. In many cases, while human kinds are difficult to be connected together, making offices
resource structure is unchanged, workload and requirement for isolated from information processing system;
staff skills are yet much higher; • Shortcomings: Lack of typical information, unfriendly interface
• Supporting operational management: This is clear in preparing with users, bad storage of information.
detail information, making reports quickly, which contribute • Low reliability: Data is conflicted, inadequate and unamendable,
to a more flexible and efficient way of management; information is not updated regularly;
• Improving information communication: Optimizing the flow • Poor resources: Inadequate ability to search for information,
of information, preparing necessary updated information and lack of exploitation tools for users, low information quality;
providing users with the information;
• Bad support: Users are not aware of what they have handy,
• Impact of information products: Information products are there are no clear development strategies, development pace is
final outcomes of the IT system. We need to pay special slow, support is inadequate, mutual understanding is low.
attention to requirements for information products so as to
• It is clear that the IT experts and the users view the system
thorough analysis. These requirements shall be frequently in
from different perspectives thus having different requirements.
comparison with general strategies while developing the system;
• Analyzer’s capability is shown in his/her ability to collect ideas
• Ability to implement more quickly and better. and evaluate them from a wider perspective, because system
Users requirements developers are only knowledgeable of their own areas.
• Users are those who use the information system to manage Analysis
their organizations rather than simply those who work with
• Analysis is a detailed study of the various operations performed
computers.
by a system and their relationship within and outside of he
• They are the ones who master the current information system system.
(from information sources, management requirements to the
• A key question is : What must be done to solve the problem?
system’s shortcomings) and are future owners of the system.
One aspect of analysis is defining the boundaries of the system
• Thus their requirements should be respected while developing and determining whether or not a candidate system should
any information system. Attention should be paid in the consider other related systems.
following issues:
• During analysis, data are collected on the available files, decision
Easy access pints, and transactions handled by the present system.
The system must be able to timely access data and manipulation • Some logical system models and tools that are used in analysis
supports. are Data flow diagrams, interviews, on-site observations, and
The system questionnaires. The interview is a commonly used tool in
The system must be solid and stable, being able to meet staff’s analysis.
requirements and provide accurate information, easy to maintain • It requires special skills and sensitivity to the subject being
and restructure, quick in identifying and correcting mistakes; interviewed. Bias in data collection and interpretation can be a
Interface problem. Training, experience, and common sense are required
Suitable with working style of users, stable, easy to control data, for collection of the information needed to do the analysis.
independent and flexible, enabling users to approach in different • Once analysis is completed, the analyst has a from understanding
ways. of what is to be done?
Technical requirements • The next step is to decide how the problem might be solved.
Technological requirements should be taken into account when • Thus, in systems design, we move from the logical to the
designing information systems. The important points are as physical aspects of the life cycle.
follows:
Analysis
• Information volume: Information technology equipment must
be suitable with the volume of information that is to be Phase
processed;
• Period: Everyday information which arises regularly is repetitive
information that requires special care;
• Accuracy: Especially high accuracy is required now and then.
Accuracy is important but difficult to meet;
• However, due to its complexity, the current system fails to
resolved the issues that need to be resolved by the new system.

42
 made. The outcome is a system proposal (also called a project

SYSTEMS ANALYSIS
proposal) that summarizes the findings of the analysis and
states the recommendations for design.
Data Analysis
• Data analysis is a prerequisite to cost/benefit analysis. System
investigation and data gathering lead to an assessment of current
findings. Our interest is in determining how efficiently certain
steps are performed, how they contribute to achieving the
intended goals, and cost of making improvements.
• The safe deposit department was authorized to double its
capacity from 4,000 to 8,000 boxes in an effort to meet increased
demand. Consequently, the number of employees changed
from three to five, with one employee assigned full-time to
billing. Analysis of the data collected made it obvious that
customer information or status of vacant boxes was a
nightmare. Customer lines were long, and service was
jeopardized.
• The representative facts for the safe deposit department are
shown in the below FIGURE Representative Facts and
Candidate System Design Objectives. The system requirements
are:
Production, Implementation, and Operation Phases 1. Better customer service.
2. Faster information retrieval
3. Quicker notice preparation.
4. Better billing accuracy.
Figure Representative Facts and Candidate System Design
Objectives

• Data gathering is only part of systems analysis, however, the

next steps are to examine the data, assess the situation, look at
the alternatives, and recommend a candidate system. The costs
and benefits of each alternative guide the selection of one
alternative over the other.
• Each approach has costs and benefits that are compared with
those of other approaches before a final recommendation is

43
 recently got married and strong resistance by the majority of
SYSTEMS ANALYSIS

Analysis Current System Facts Objectives (System Design

the staff to a computerized environment.
Requirements)
What is done? Open customer account Assign safe Better customer service Faster
• Another alternative might be simply to devise a semiautomatic
(processes) deposit box Issue key information retrieval Quicker (Ferris-wheel type) system that organizes master cards and
Receive annual rent notice preparation. customer records and improves their access. A word processing
How is it done? Some 40 boxes opened or closed daily Better billing accuracy system might be introduced to speed the preparation of billing
(processing detail) Master card file located too far from Lower processing and
notices. The edit feature of word processors speed the
customer inquiry station. operating cost Improved staff
Heaviest activity on Fridays and before efficiency
preparation of billing notices. The edit feature of word
holidays More consistent billing
processors would improve the accuracy in billing preparation.
Too many steps taken with new customers procedures to eliminate errors. If these were the only two alternatives available, which alternative
Delay in billing – all manual some 80 guides the selection process. Therefore, the analyst needs to be
renewal payment notices prepared daily familiar with the cost and benefit categories and the evaluation
Cash received given to head teller at end
methods before a final selection can be made.
of each day
Poorly designed application forms COST/BENEFIT ANALYSIS
Accounting gets daily summary
Procedure for customer access to boxes is Cost and Benefit Categories
neither documented nor consistent. • In developing cost estimates for a system, we need to consider
Who does it? One person handles billing (full-time) Better trained pers onal
several cost elements. Among them are hardware, personnel,
(personnel) One Person handles security Experience in computer use
facility, operating and supply costs.
Three persons process customers into and for other applications.
out of safe deposit area 1. Hardware costs relate to the actual purchase or lease of the
Except for two persons, rest of staff is computer and peripherals (for example, printer, disk drive,
poorly trained
tape unit). Determining the actual cost of hardware is generally
Communication among staff is adequate
more difficult when various users than for a dedicated stand-
Where is it done? Location allows privacy and security Allocate quiet space for
(Physical Billing carried out close to customer computer provide security
alone system share the system. In some cases, the best way to
location/facility) counter measure for information control for this cost is to great it as an operating cost.
access.
2. Personnel costs include EDP staff salaries and benefits (health
Assessment of Time to prepare a renewal notice is 10
insurance, vacation time, sick pay, etc.) as well as pay for those
processing minutes
Time to process a customer is 3.5 minutes
involved in developing the system. Costs incurred during the
15 percent of billing is erroneous in development of a system are one-time costs and are labeled
amount, box number, or amount of rent development costs. Once the system is installed, the costs of
28 percent of vacant boxes cannot be operating and maintaining the system become recurring costs.
located on existing books
Frequent notices regarding “ to be
3. Facility costs are expense incurred in the preparation of the
renewed” boxes cost $8,000 for mailing physical site where the application or the computer will be in
Employee payroll is as high as junior operating. This includes writing, flooring, acoustics, lighting
officers in operations area and air conditioning. These cost are treated as one-time costs
and are incorporated into the overall cost estimate of the
candidate system.
1. Lower processing and operating costs.
4. Operating costs include all costs associated with the day-to-day
2. Improved staff efficiency operation of the system; the amount depends on the number
3. Consistent billing procedure to eliminate errors. of shifts, the nature of the applications, and the caliber of the
• To achieve these design objectives, several alternatives must be operating staff. There are various ways of covering operating
evaluated; there is seldom just one alternative. The analyst then costs. One approach is to treat operating costs as overhead.
selects those that are feasible economically, technically, and Another approach is to charge each authorized user for the
operationally. The approach may emphasize the introduction amount of processing they request from the system. The
of a computerized billing system, replacement of staff, amount charged is based on computer time, staff time, and
improved billing practices, changes in operating procedures, or volume of the output produced. In any case, some accounting
a combination of several options. is necessary to determine how operating costs should be
• As you can imagine, each approach has its benefits and drawbacks. handled.
For example, one alternative is to introduce a computer-based 5. Supply costs are variable costs that increase with increased use
safe deposit tracking and billing system designed to improve of paper, ribbons, disk, and the like. They should be estimated
billing accuracy and notice preparation and lower processing and included in the overall cost of the system.
and operating costs. It would also promote staff efficiency by • A system is also expected to provide benefits. The first task is
allowing the existing staff to concentrate on customer service to identify each benefit and then assign a monetary value to it
and provide online information on box availability and the for cost/benefit analysis. Benefits may be tangible and
like. The drawback includes laying off the billing clerk who intangible, direct or indirect.

44
• The two major benefits are improving performance and software, personnel training, and employee salaries are example

SYSTEMS ANALYSIS
minimizing the cost of processing. The performance category of tangible costs. They are readily identified and measured.
emphasizes improvement in the accuracy of or access to • Cost that are known to exit but whose financial value cannot
information and easier access to the system by authorized users. be accurately measured are referred to as intangible costs.
Minimizing costs through an efficient system—error concluded
• For example, employee morale problems caused by a new
in cost/benefit analysis.
system or lowered company image is an intangible cost. In
Procedure for Cost/Benefit some cases, intangible costs may be easy to identify but difficult
Determination to measure.
• There is a difference between expenditure and investment. We • For example, the cost to the breakdown of an online system
spend to get what we need, but we invest to realize a return on during banking hours will cause the bank to lose deposits and
the investment. Building a computer-based system is an waste human resources. The problem is by how much? In
investment. Costs are incurred throughout its life cycle. Benefits other cases, intangible costs may be difficult even to identify,
are realize in the form of reduced operating costs, improved such as an improvement in customer satisfaction stemming
corporate image, staff efficiency, or revenues. To what extent from a real-time order entry system.
benefits outweigh costs is the function of cost/benefit analysis. • Benefits are also classified as tangible or intangible. Like costs,
• Cost/benefit analysis is a procedure that gives a picture of the they are often difficult to specify accurately. Tangible benefits,
various costs, benefits, and rules associated with a system. The such as completing jobs in fewer hours or producing reports
determination of costs and benefits entails the following steps: with no errors, are quantifiable. Intangible benefits, such as
1. Identify the costs and benefits pertaining to a given project. more satisfied customers or an improved corporate image, are
not easily quantified. Both tangible and intangible costs and
2. Categorize the various costs and benefits for analysis.
benefits, however, should be considered in the evaluation
3. Select a method of evaluation. process.
4. Interpret the results of the analysis.
Direct or Indirect Costs and Benefits
5. Take action.
• From a cost accounting point of view, costs are handled
Cost and Benefits Identification differently depending on whether they are direct or indirect.
• Certain costs and benefits are more easily identifiable than other. Direct costs are those with which a dollar figure can be directly
For example, direct costs, such as the price of a hard disk, are associated in a project. They are applied directly to the operation.
easily identified example, direct costs, such s the price of a hard • For example, the purchase of a box of diskettes for $35 is a
disk, are easily identified from company invoice payment or direct cost because we can associate the diskettes with the dollars
canceled checks. expended. Direct benefits also can be specifically attributable to
• Direct benefits often relate one-to-one to direct costs, especially a given project. For example, a new system that can handle 25
savings form reducing costs in the activity in question. Other percent more transactions per day is a direct benefit.
direct cost and benefits, however, may not be well defined, • Indirect costs are the result of operations that are not directly
since they represent estimated costs or benefits that have some associated with a given system or activity. They are often referred
uncertainly. An example of such costs is reserve for bad debt. to as overhead. A system that reduces overhead realizes a savings.
It is a some uncertainty. An example of such costs is reserve for If it increase overhead. It incurs an additional cost.
bad debt. It is a discerned real cost, although its exact amount • Insurance, maintenance, protection of the computer center,
is not so immediate hat light, and air controlling are all tangible to a specific activity
• A category of costs or benefits that is not easily discernible is such as a report. They are overhead an are allocated among
opportunity costs and opportunity benefits. These are the cost users according to formula..
or benefits forgone by selecting one alternative over another. • Indirect benefits are realized as a by-product of another activity
They do not saw in the organization’s accounts and therefore or system. For example, our proposed safe deposit billing
are not easy to identify. system that provides profiles showing vacant boxes by size,
Classification of Costs and Benefits location, and price, will help management decide on how much
• The next step in cost and benefit determination is to categorize advertising to do for box rental. Information about vacant
costs and benefits. They may be tangible or intangible, direct or boxes becomes an indirect benefit of the billing even thought
indirect, fixed or variable. Let us review each category. is difficult to specify its value. Direct costs and benefits are
readily identified for tangible costs and benefits, respectively.
Tangible or Intangible Costs and
Benefits. Fixed or Variable Costs and Benefits.
• Tangibility refers to the case with which costs or benefits can be • Some costs and benefits are constant, regardless of how well a
measured. An outlay of cash for a specific item or activity is system is used. Fixed costs (after the fact)are sunk costs. They
referred to as a tangible cost. They are usually shown as are constant and do not change. Once encountered, they will
disbursements on the books. The purchase of hardware or not recur.
• Examples are straight-line depreciation of hardware, exempt
employee salaries, and insurance. In contrast, variable costs are

45
 incurred on a regular (weekly, monthly) basis. They are usually
SYSTEMS ANALYSIS

Avera ge Annual Pay

proportional to work volume and continue as long as the (includes 25 percent
system is in opertion. Position N benefits) Total
Collections teller 1 $12,400 $12,400
• For example, the costs of computer forms vary in proportion
Savings teller 5 11,610 58,050
to the amount of processing or the length of the reports
Bookkeeper 3 9,940 29,820
required. Proof operator 1 10,900
• Fixed benefits are also constant and do not change. An example Subtotal 10 10,900
is a decrease in the number of personnel by 20 percent resulting $111,170

form the use of a new computer. The benefit of personnel B. Reduction in handling charges

savings may recur every month. Variable benefits, on the other

C. Reduction in proof machine rental: 6,840
hand, are realized on a regular basis,
Previous units (4 @ $4,500) $18,000
• For example, consider a safe deposit tracking system that saves Present units ( 3 @ $1,380 4,140
20 minutes preparing customer notices compared with the Net savings from rentals
manual system. The amount of time saved varies with the Total gross savings

number of notices produced. 13,860

Less processing charges:
Savings versus Cost Advantages. Online demand deposit processing $33,660 $131,870

• Savings are realized when there is some kind of cost advantage. Proof of deposit reporting 27,000

As cost advantage reduces or eliminates various cost being Online savings processing 5,100
Teller machine rental 25,230
incurred. Figure An Example of Saving That Reduce Current
Total processing charges
Costsis a summary of savings for the use of a new online teller
Net savings/year
system.
• In this installation, $131,870 was saves through a reduction in 90,990
personnel, handling charges, and proof machine rental. After $

deducting processing charges of $90,990, the net savings from 40,880

the online system was $40,880. This is a savings that provides

relief from current costs. It is realized specifically as a result of
the additional processing costs incurred in the new system.
Figure An Example of Saving That Reduce Current Costs
• There are savings, however, that do not directly reduce existing
Summary of Savings costs. To illustrate, examine the following case :
From an Online Teller system • A systems analyst designed an online teller system that requires
A. Reduction in personnel and payroll 14 new terminals. No reduction in personnel is immediately
planned. Renovation of the bank lobby and the teller cages will
be required. The primary benefits are:
1. Savings in tellers’ time to update accounts and post transactions.
2. Faster access and retrieval of customer account balances.
3. Availability of additional data for tellers when needed.
4. Reduction of transaction processing errors.
5. Higher employee morale.
6. Capability to absorb 34 percent of additional transactions.
• This is a case where no dollars can be realized as a result of the
costs incurred for the new installation. There might be potential
savings if additional transactions help another department
reduce its personnel. Similarly, management might set a value
(in terms of savings) on the improved accuracy of teller, on
quicker customer service, or on the psychological benefits from
installing an online teller system.
• Given the profit motive, savings (or benefits) would ultimately
be tied to cost reductions. Management has the final say on
how well the benefits can be cost-justified.

46
Review New York: Macmillan. Pressman (1997)

SYSTEMS ANALYSIS
System Approach Software Engineering:
A Practitioners Approach.
System Requirements
New York:McGraw-Hill. van Vliet, Hans (1993)
Detailed Analysis Phase
Software Engineering:
Questions Principles and Practice.
What are the various approaches of system development? Chichester: John Wiley & Sons.
1 Notes
2
3
4
5
Explain the various system requirements.
1
2
3
4
5
What is cost-benefit analysis ? Is it important? Why? Explain.
1
2
3
4
5
References
Heuring, Vincent P.
Computer systems design and architecture
Delhi : Pearson Education Asia, 1997
Whitten, Jeffrey L.
Systems analysis and design methods
5th ed. New Delhi : Galgotia Publications, 2001
Shelly, Gary B.
Systems analysis and design
3rd ed. New Delhi : Galgotia Publications, 1999
Awad, Elias M.
Systems analysis and design
New Delhi : Galgotia Publications, 1997
Hoffer, Jeffrey A.
Modern systems analysis and design
2nd ed. Delhi : Pearson Education Asia, 2000
Sarkar, A.K.
Systems analysis, data processing and
quantitative techniques
New Delhi : Galgotia Publications, 1997
Hawryszkiewycz, Igor
Introduction to systems analysis & design
4th ed. New Delhi : Prentice Hall of India, 2002
S. Pfleeger (1991)
Software Engineering.

47
 LESSON 11 :
SYSTEMS ANALYSIS

STAGES OF SDLC

Topics covered • At this point, projected costs must be close to actual costs of
• Stages of SDLC implementation.
• Design Phase • In some firms, separate groups of programmers do the
programming whereas other firms employ analyst-
• Implementation
programmers who do analysis and design as well as code
• Post-Implementation programs.
• Candidate system, • For this discussion, we assume that two separate persons carry
• Benefits of SDLC. out analysis and programming. There are certain function,
Objectives though, that the analyst must perform while programs are
being written.
Upon completion of this Lesson, you should be able to:
• Operating procedures and documentation must complete.
Explain the stages of SDLC. Security and auditing procedures must also be developed
Explain the Candidate system
Implementation
Express the benefits of SDLC
• The implementation phase is less creative than system design.
Do You Know which is the most creative • It is primarily concerned with user training, site preparation,
phase in SDLC? and file conversion. When the candidate system is linked to
Design terminals or remote sites.
• The most creative and challenging phase of the system life cycle • The telecommunicating network and test of the network along
is system design. with the system are also included under implementation.
• The term design describes a final system and the process by • During the final testing, user acceptance is tested, followed by
which it is developed. user training.
• It refers to the technical specification (analogous to the engineer’s • Depending on the nature of the system, extensive user training
blueprints) that will be applied in implement in the candidate may be required. Conversion usually takes place at about the
system. same time the user is being trained or later.
• It also includes the construction of programs and program • Programming is itself design work. It is therefore a mistake to
testing exclude programmers from the initial system design.
The key question here is: how should the problem be solved? • System testing checks the readiness and accuracy of the system
• The first steps is to determine how the output is to be produced to access update and retrieve data from new files.
and in what format. Samples of the output (and input) are • Once the programs become available, test data are read into the
also presented. computer and processed against the file(s) provided for testing.
• Second input data and master files (data base) have to be Post-Implementation and Maintenance
designed to meet the requirements of the proposed output. • After the installation phase is completed and the user staff is
• The operational (processing) phases are handled though adjusted to the changes created by the candidate system,
program construction and testing, including a list of the evaluation and maintenance begin.
program needed to meet the system’s objectives and complete • There is an aging process that requires period maintenance of
documentation. hardware and software.
• Finally details related to justification of the system and an • If the new information is inconsistent with the design
estimate of the impact of the candidate system on the user an specifications, then changes have to be made.
the organization are documented and evaluated by
management as a step toward implementation. • Hardware requires periodic maintenance.
• The final report prior to the implementation phase includes • The importance is to continue to bring new system to
procedural flowcharts, record layout, report layouts, and standards.
workable plan for implementing the candidate system. • Project Termination
Information on personnel, money, hardware, facilities, and their • A system project may be dropped at any time prior to
estimated cost must also be available. implementation. Generally projects are dropped if, after a review
process, it is learned that:

48
• Changing objectives or requirements of the user cannot be • The economic factor focuses on the system’s potential return

SYSTEMS ANALYSIS
met by existing design. on investment.
• Benefits realized from the candidate system do not justify • The main idea behind the system development life cycle is to
commitment to implementation. formalize a means of establishing control over a complex
• There is a sudden change in the user’s budget or an increase in process.
design costs . • Work units have to be structured at three major levels for effective
• The project greatly exceeds the time and cost schedule. control of the project.
• There are many reasons a new system does not meet user • At the lowest level, work assignments are broken down into
requirements small manageable tasks.
• User requirements were not clearly defined or understood. • A task is well-defined, structured work unit that can be carried
out by one individual.
• The user was not directly involved in the crucial phases of
system development. • The task can be easily budgeted and scheduled and its quality is
measured.
• The analyst, programmer, or both were inexperienced.
• Benefits of SDLC
• User training was poor.
• Proven framework
• Existing hardware proved deficient to handle the new
application. • Uniformity
• The new system was not user-friendly. • Uniform method
• Users changed their requirements. • Uniform operation (function)
Considerations for candidate systems • Results (deliverables)
In today business there is more demand for computer services • Facilitates information exchange
than the resources available to meet the demand. The demand • Defines and focuses roles and responsibilities
is made-up of the following: • Predefined Degree of Precision
1. Operations of existing systems. • A complete solution
2. Maintenance that focuses on patching programs often • A correct solution
represents over 50 percent of maintenance.
• A predictable solution
3. Enhancements that involve major modifications in program
• Identified milestones
structure or equipment.
• Enforced Planning and Control
4. Request for candidate system.
q Problem Definition
• All the demands require resources – human, financial and q Feasibility Study
technologies. •
• The computer department has to provide the following: •
q Evaluation
1. Computer operators to run equipment.
2. System analysts to define and design specifications.
3. Application programmers to convert system specifications to
computer programs.
4. Maintenance programmers to repair errors. q Economic Feasibility
q Organizational Feasibility
5. Supervisors project leaders, and managers to coordinate the •
jobs with the users. •
q Application Feasibility
• Thus the basic problem is to match the demands for services
with available resources.
• How much one project is favored over another depends on
technical, behavioral, and economic factors. q Interview secretaries
• The technical factor involves the system department’s ability to q Summarize findings
•
handle a project.
•
• The behavioral factor involves q Compare company’s goals to capabilities

• The user’s past experience with existing with an existing system.

• The success record of the analyst
• The influence the user can exert on upper management to
finance a candidate system.

49
 Review Explain briefly the levels of structuring work units in system
SYSTEMS ANALYSIS

Design Phase development.

Implementation Phase 1
Post-Implementation Phase
2
Project Termination
Candidate system, Benefits of SDLC 3
4
Questions
Why is a system proposal so crucial for system design? Explain. 5
1 References:
2 Heuring, Vincent P.
3 Computer systems design and architecture
4 Delhi : Pearson Education Asia, 1997
Whitten, Jeffrey L.
5 Systems analysis and design methods
What is the difference between analysis and design? Can one begin 5th ed. New Delhi : Galgotia Publications, 2001
to design without analysis? Why? Shelly, Gary B.
1 Systems analysis and design
2 3rd ed. New Delhi : Galgotia Publications, 1999
3 Awad, Elias M.
4 Systems analysis and design
5 New Delhi : Galgotia Publications, 1997
What are the activities that make up system design? How does Hoffer, Jeffrey A.
system design simplify implementations? Modern systems analysis and design
1 2nd ed. Delhi : Pearson Education Asia, 2000
2 Sarkar, A.K.
3 Systems analysis, data processing and
4 quantitative techniques
5 New Delhi : Galgotia Publications, 1997
A number of activities are carried out under implementation. Hawryszkiewycz, Igor
Elaborate. Introduction to systems analysis & design
1 4th ed. New Delhi : Prentice Hall of India, 2002
2 S. Pfleeger (1991) Software Engineering. New York: Macmillan.
3 Pressman (1997) Software Engineering: A Practitioners
4 Approach. New York:McGraw-Hill.
5 Van Vliet, Hans (1993) Software Engineering: Principles and
When does an analyst terminate a project? How does it tie in with Practice. Chichester: John Wiley & Sons.
post-implementation? Explain.
1
2
3
4

5
There are several considerations in deciding on a candidate system.
What are they? Why are they important?
1
2
3
4

50
 LESSON 12 :

SYSTEMS ANALYSIS
VERIFICATION AND VALIDATION PHASE

Topics covered • Like many other industries in the United States, the health care
• Verification and Validation Phase industry is turning to computing systems to reduce
administrative overhead, control escalating costs, and improve
• Activities of V&V accuracy of stored information.
Objectives • New technology is affecting the form and usage of patient
Upon completion of this Lesson, you should be able to: information, diagnostic tools, and the tools, which provide
Explain difference between verification and validation treatment.
Explain the activities of V&V • In particular, the application of information technology is a
V&V(Verification and Validation) promising enabler for transferring gains in medical science
research to patient benefit, for ensuring appropriate availability
• Validation - are we building the right product? of patient information, and for managing the billing processes.
• Verification - are we building the product right? • Computing systems may be employed in the health care
Verification and validation environment in efforts to increase reliability of care and reduce
Once one has a ‘working’ simulation, the next step is to check that costs.
the simulation is actually doing what one expects. • Software verification and validation (V&V) is an aid in
What is Verification? determining that the software requirements are implemented
With a complicated computer program, it is all too easy to make correctly and completely and are traceable to system
errors and find that the output is the result of a mistake, rather requirements.
than a surprising consequence of the model. The process of • (Software V&V does not verify the correctness of the system
checking that a program does what it was planned to do is known requirements, only that the software requirements can be traced
as “Verification”. to the system requirements.)
In the case of simulation, the difficulties of verification are • It helps to ensure that those system functions controlled by
compounded by the fact that many simulations include random software are secure, reliable, and maintainable.
number generators, which mean that every run is different and • It uses a structured approach to analyze and test the software.
that it is only the distribution of results, which can be anticipated It evaluates software against its requirements for quality
by the theory. It is therefore essential to ‘debug’ the simulation attributes such as performance.
carefully, preferably using a set of test cases, perhaps of extreme
situations where the outcomes are easily predictable.
• Software V&V is conducted throughout the planning,
development, and maintenance of software systems.
Abstract • The major objective of the software V&V process is to
• Computing systems may be employed in the health care determine that the software performs its intended functions
environment in efforts to increase reliability of care and reduce correctly, ensure that it performs no unintended functions, and
costs. provide information about its quality and reliability.
• Software verification and validation (V&V) is an aid in • Software V&V evaluates how well the software is meeting its
determining that the software requirements are implemented technical requirements and its safety, security and reliability
correctly and completely and are traceable to system objectives relative to the system. It also helps to ensure that
requirements. software requirements are not in conflict with any standards or
• It helps to ensure that those system functions controlled by requirements applicable to other system components.
software are secure, reliable, and maintainable. • Software V&V tasks analyze, review, demonstrate or test all
• Software V&V is conducted throughout the planning, software development outputs.
development and maintenance of software systems, including • The software V&V process is tightly integrated with the software
knowledge-based systems, and may assist in assuring development process.
appropriate reuse of software. • For each activity in software development there is a
Keywords corresponding software V&V activity to verify or validate the
• Health care; independent verification and validation; knowledge- products of those activities.
based systems; software reuse; software development; software • This report explains these relationships, the software V&V
diagnostic tools; software verification and validation. tasks supporting each activity, and the types of techniques that
may be used to accomplish specific software V&V tasks.
Executive Summary

51
 • Software V&V has long been employed on new development • In response to the increasing dependence of the health care
SYSTEMS ANALYSIS

projects. Today, more and more systems are built using industry on information technology, the Advanced Technology
commercial off-the-shelf (COTS) software products, software Program (ATP) at the National Institute of Standards and
components from sources external to the developer, and Technology (NIST) issued Solicitation 94-04, Information
software from a previous version of a similar product built by Infrastructure for Health Care.
the same organization. • The recognition by the ATP that the computer-based systems
• Some of the issues concerning software V&V for systems used in health care must be of high integrity (1) resulted in one
reusing any of these software types are addressed in this element of that solicitation being technology for verification
document. and validation (V&V).
• The health care industry has been interested in, and made use • This report is the result of an effort funded by the ATP to
of, artificial intelligence (AI) techniques by developing KBSs to produce guidance for the software V&V of computer-based
understand the complex medical and patient data used for health care systems.
diagnosis. • Software V&V helps to ensure and assess the quality of
• This interest has grown as the scale of the problem of managing software-based systems.
data and knowledge has grown in the health care industry. • Computing systems may be employed in the health care
• While there are techniques available for V&V of the KBS, which environment in efforts to increase reliability of care and reduce
employ AI techniques, the V&V and AI communities still costs.
need to do more research especially in the areas of making • To achieve these benefits, those functions controlled by software
knowledge maintenance easier and more reliable. in health care systems must be secure, reliable, and maintainable.
• These guidelines provide an overview of the issues in using Software V&V will help to provide all these assurances.
V&V and KBS techniques. • Software verification and validation (V&V) is an aid in
Acronyms determining that the software requirements are implemented
correctly and completely and are traceable to system
AI Artificial Intelligence
requirements. (Software V&V does not verify the correctness
ATP Advanced Technology Program of the system requirements, only that the software requirements
CASE Computer-Aided Software Engineering can be traced to the system requirements.)
CBR Case-Based Reasoning • It uses a structured approach to analyze and test the software.
COTS Commercial Off-The-Shelf It measures software against its requirements for quality
FSM Finite State Machines attributes such as performance, safety (2), and computer security.
Software V&V includes activities (3) to determine that the
IA Intelligent Agents software system performs its intended functions correctly, to
IV&V Independent Verification and Validation ensure that it performs no unintended functions, and to
KBS Knowledge-Based System provide information about its quality and reliability.
KADS KBS Analysis and Design Support • Software V&V has long been employed on new development
LOC Lines Of Code projects. Today, more and more systems are built using
commercial off-the-shelf (COTS) software products, software
NIST National Institute of Standards and Technology
components from sources external to the developer, and
Sfmeca Software Failure Mode, Effects, and Criticality Analysis software from a previous version of a similar product built by
SPC Statistical Process Control the same organization.
SQA Software Quality Assurance • Some of the issues concerning software V&V for systems
SVVP Software Verification and Validation Plan reusing any of these software types are addressed in this
document. This particular aspect of software V&V for reused
SVVR Software Verification and Validation Report
software requires additional research from the reuse and V&V
V&V Verification and Validation communities.
1 Introduction • The health care industry has been interested in and made use
• Like many other industries in the United States, the health care of artificial intelligence (AI) techniques by developing KBSs to
industry is turning to computing systems to control escalating understand the complex medical and patient data used for
costs and improve the quality of service. diagnosis.
• New technology is affecting the form and usage of patient • This interest has grown as the scale of the problem of managing
information, diagnostic tools, and the tools which provide data and knowledge has grown in the health care industry.
treatment. While there are techniques available for V&V of the KBS which
employ AI techniques, the V&V and AI communities still
• In particular, the application of information technology is a
need to do more research especially in the areas of making
promising enabler for transferring gains in medical science
knowledge maintenance easier and more reliable.
research to patient benefit, for ensuring appropriate availability
of patient information, and for managing the billing processes.

52
• These guidelines provide an overview of the issues in using • While different management and technical staff may be

SYSTEMS ANALYSIS
KBS techniques on systems requiring high reliability and on responsible for different types of test, staff who perform
some of the techniques for V&V of KBS especially KBS which verification of the software requirements may be staff who
employ expert systems. prepare preliminary plans for software system tests.
2 Software Verification And Validation • The development of the test plans and designs may lead to
(V&V) discovery of software requirements errors because of the
analysis needed to plan tests.
• Software verification and validation (V&V) is an aid in
determining that the software requirements are implemented • One issue that often arises in planning a project and its software
correctly and completely and are traceable to system V&V effort is how to ensure the objectivity of the staff
requirements. performing software V&V tasks.
• (Software V&V does not verify the correctness of the system • Independent V&V (IV&V) for software grew out of this
requirements, only that the software requirements can be traced concern. Software IV&V is the performance of software V&V
to the system requirements.) tasks by a team that is separate from the software development
• The major objective of the software V&V process is to group.
comprehensively analyze and test the software during • The software V&V technical activities each have several tasks.
development to determine that the software performs its Each task is accomplished by applying one or more techniques.
intended functions correctly, ensure that it performs no • A specific technique, such as control flow analysis, focuses on
unintended functions, and provide information about its finding a specific type of problem, for example, a logic error.
quality and reliability . • An aggregate of techniques is usually necessary to achieve the
• Software V&V evaluates how well the software is meeting its objectives of a task.
technical requirements and its safety, security, and reliability
objectives relative to the system.
• It also ensures that software requirements are not in conflict
with any standards or requirements applicable to other system
components. Software V&V tasks analyze, review, demonstrate
or test all software development outputs.
• Software verification examines the products of each
development activity (or increment of the activity) to determine
if the software development outputs meet the requirements
established at the beginning of the activity.
• The scope of each software development activity is defined by
software program management.
• A software design may consist of many small increments for
each iteration of the total system. Hence, V&V tasks can be
performed on small outputs.
• Validation that the software is a correct implementation of the
system requirements for which the software is responsible is
conducted concurrently with, and at the end of, all software
development activities.
• The software V&V process produces a software verification
and validation plan (SVVP), individual plans and reports for
tasks, summary reports, anomaly reports, and a final software
verification and validation report (SVVR).
• Software V&V planning is conducted against system
requirements at the highest level of planning, and then on the
software requirements, which should be traceable to the system
requirements.
• Many software V&V tasks, such as planning for software system
test, are actually performed in early development activities. The
software system test plan is developed concurrently with the
software requirements activity.
• The plan is updated with additions or changes in details as the
project progresses.

53
 • Tasks for acceptance test parallel those for software system test.
SYSTEMS ANALYSIS

Major Software V&V Activities

Differences may exist in the specific objectives, which may
TASKS influence test requirements.
ACTIVITY
Review
Software V&V Management
- Planning
Software Requirements V&V
Software V&V - Monitoring
Software Design V&V
Management - Evaluating results, impact of change
- Reporting
Code V&V
Unit Test
- Review of concept documentation (if not
performed prior to software requirements
Software Integration Test
development) Software System Test (4)
Software Requirements - Traceability analysis Software Installation Test
V&V - Software Requirements Evalutaion Software Operation and maintenance V&V
- Interface Analysis
Questions
- Initial Planning for Software System Test
Explain about Software Design V&V
- Reporting
1
- Traceability Analysis
2
- Software Design Evaluation
- Interface Analysis 3
Software Design V&V - Initial Planning for Unit Test 4
- Initial Planning for Software Integration 5
Test Differentiate between Unit and Integration testing.
- Report
1
- Traceability Analysis 2
- Code Evaluation 3
Code V&V - Interface Analysis
4
- Completion of Unit Test Preparation
- Reporting
5
Differentiate between verification and validation
- Unit Test Execution
Unit Test 1
- Reporting
2
- Completion of Software Integration Test
3
Preparation
Software Integration Test 4
- Execution of Software Integration Tests
- Reporting
5
- Completion of Software System Test
List the various types of testing.
Preparation
Software System Test (4) 1
- Execution of Software System Tests
- Reporting 2
3
- Installation Configuration Audit
Software Installation Test 4
- Reporting
5
- Impact-of-Change Analysis
Software Operation and
- Repeat Management V&V References
maintenance V&V
- Repeat Technical V&V Activities Heuring, Vincent P.
Computer systems design and architecture
•
This document treats acceptance test as a function of the acquirer Delhi : Pearson Education Asia, 1997
of the software system, while acknowledging that the acquirer Whitten, Jeffrey L.
may sometimes work with V&V staff from the software Systems analysis and design methods
requirements V&V through software installation test to develop 5th ed. New Delhi : Galgotia Publications, 2001
acceptance test.
Shelly, Gary B.
Systems analysis and design

54
 3rd ed. New Delhi : Galgotia Publications, 1999

SYSTEMS ANALYSIS
Awad, Elias M.
Systems analysis and design
New Delhi : Galgotia Publications, 1997
Hoffer, Jeffrey A.
Modern systems analysis and design
2nd ed. Delhi : Pearson Education Asia, 2000
Sarkar, A.K.
Systems analysis, data processing and
quantitative techniques
New Delhi : Galgotia Publications, 1997
Hawryszkiewycz, Igor
Introduction to systems analysis & design
4th ed. New Delhi : Prentice Hall of India, 2002
Notes

55
 LESSON 13:
SYSTEMS ANALYSIS

VERIFICATION AND VALIDATION

Topics covered management who acts upon the reported discrepancy and
• Independent Verification and Validation Phase findings.
• Software V&V Management, • Financial independence means that control of the IV&V budget
is retained in an organization outside the contractor and program
Software V&V activities.
organization that develop the software.
Objectives • This independence protects against diversion of funds or
Upon completion of this Lesson, you should be able to: adverse financial pressures or influences that may cause delay or
Explain about Independent verification and validation stopping of IV&V analysis and test tasks and timely reporting
Explain the activities of software V&V of results.
• The extent that each of these parameters is vested in the IV&V
What is meant by Independent V&V ? team’s responsibilities defines the degree of independence
• Some software V&V activities may be performed by two achieved.
different groups. The use of a different organization (other
• Based on the definitions of IV&V and how much IV&V a
than the software development group) for software V&V is
specific project requires, some software V&V activities may be
called independent verification and validation (IV&V).
conducted by both the developer and another organization.
• Technical independence requires that members of the IV&V • For example, unit test by one organization may focus on
team (organization or group) may not be personnel involved
demonstrating that specific objectives (e.g., safety objectives
in the development of the software.
relative to the system), which may differ from the objectives of
• This team must have some knowledge about the system design the developer (e.g., logic structure, test coverage),.
or have related experience and engineering background enabling
them to understand the system. Software V&V Management
• The IV&V team must not be influenced by the development • The process of software V&V needs to be managed and
team when the IV&V team is learning about the system performed comprehensively over the entire software
requirements, proposed solutions for building the system, and development process.
problems encountered. • Management tasks, spanning all of the software development
• Technical independence is crucial in the team’s ability to detect activities, are to:
the subtle software requirements, software design, and coding • Plan and maintain the software V&V process.
errors that escape detection by development testing and SQA • Coordinate and interpret performance and quality of the
reviews. software V&V effort.
• The technical IV&V team may need to share tools from the • Report discrepancies promptly to the user or development
computer support environment (e.g., compilers, assemblers, group.
utilities) but should execute qualification tests on these tools • Identify early problem trends and focus software V&V tasks
to ensure that the common tools themselves do not mask on them.
errors in the software being analyzed and tested.
• Provide a technical evaluation of the software performance and
• The IV&V team uses or develops its own set of test and quality attributes at each major software program review (so a
analysis tools separate from the developer’s tools whenever determination can be made of whether the software product
possible. has satisfied its set of software requirements well enough to
• Managerial independence means the responsibility for IV&V proceed to the next activity).
belongs to an organization outside the contractor and program • Assess the full impact of proposed software changes.
organizations that develop the software.
• An SVVP contains the information necessary to manage and
• While assurance objectives may be decided by regulations and perform software V&V. Major steps in developing an SVVP
project requirements, the IV&V team independently decides are to:
the areas of the software/system to analyze and test, techniques
to conduct the IV&V, schedule of tasks (within the framework • Define (or confirm, if already provided) the quality and
of the system schedules), and technical issues to act upon. performance objectives (e.g., verify conformance to
specifications, verify compliance with safety and computer
• The IV&V team provides its findings in a timely fashion security objectives relative to the system, assess efficiency and
simultaneously to both the development team and the systems quality of software, and assess performance across the full
operating environment).

56
• Characterize the types of problems anticipated in the system is an effective method of providing early product information

SYSTEMS ANALYSIS
and define how they would be manifested in the software. to software V&V.
• Select the software V&V analysis and testing techniques to • The early deliveries reinforce the systematic analysis and test
effectively detect the system and software problems. approach used by software V&V to examine the software in
• Select the metrics and techniques applied to V&V results to smaller pieces while progressively evaluating larger software
measure and predict the quality of the software. pieces as each new piece is integrated.
• The SVVP may include details for acquiring tools and for • High-risk software areas are easier to identify by using the
training personnel. The SVVP is revised as knowledge incremental approach because the software V&V can:
accumulates about the characteristics of the system, the software, • Provide an early lead time to evaluate each engineering solution
and the problem areas in the software and in software V&V and allow time to suggest alternative solutions which can be
activities. incorporated in subsequent incremental deliveries without
• The software V&V process could be tailored to specific adversely impacting the schedule.
applications; however, the risk of the software failing and the • Isolate each new set of requirements and evaluate their impact
subsequent consequences must be considered when selecting on the system performance.
software V&V activities. • Provide early indications of system performance so that
• One software V&V management task is to monitor the adjustments can be made to refine the desired performance.
software V&V technical progress and quality of results. • Develop trend information about software anomalies and risk
• During each software V&V activity, planned software V&V issues to allow time to adjust the development and software
tasks are reviewed and new ones are added to focus on the V&V resources and planning to accommodate evolving
critical performance/quality functions of the software and its software risk issues.
system. • In incremental development, a software build (or early product)
• The monitoring task includes formal reviews of software V&V represents a basic program skeleton including draft
discrepancy reports and technical evaluations to provide a check documentation containing portions of the full software
of their correctness and accuracy. capabilities.
• Internal monitoring of the quality and accuracy of software • Each successive build integrates additional functions into the
V&V results is essential because the development group must skeleton. Based on discrepancy or progress reports from
make the necessary software changes as indicated by the software software V&V, software program management can make the
V&V results. technical and management decisions to refocus the software
• If the software V&V results are erroneous, or of poor quality, V&V and development team onto the program’s specific
the development group wastes its time and resources in problem areas of the software.
attempting the changes, and more importantly, loses confidence • Two related analyses, criticality and hazard, can help focus the
in the effectiveness and helpfulness of the software V&V V&V effort on those parts of the program whose consequence
results. of failure are most severe. A hazard is an (unsafe) “condition
• Software V&V “focus on identifying and eliminating the specific that may lead to an unintended event that causes an undesirable
high-risk problems to be encountered by a software project.” outcome”.
This does not mean that software V&V should examine only • For example, a driver of a car ignores warning lights at a railroad
20% of the software. crossing and drives the car onto the tracks. The hazard is the
• Rather, software V&V needs to examine all the software. presence of the car and train on the track at the same time.
• This includes: identifying potential hazards or threats to the • The unintended event (mishap) is the train colliding with the
safety and security of the system, prioritizing the software car. The undesirable outcome is the probable loss of life and
functions by criticality, and allocating software V&V analysis damage to the car and train.
resources to those areas of the software which contain critical (5) • The term hazard generally is used to refer to safety problems;
functions and high-risk problems (i.e., more error-prone). the term threat generally is used to refer to security problems.
Identifying and focusing on critical and high-risk areas of the • In this lesson, the methods and issues related to hazard analysis
software can be addressed by these software V&V methods: are also applicable to security issues; the terms threat and security
• Examination of early program deliveries to software V&V staff; could be used in place of hazard and safety respectively.
• Use of software hazard (or threat) analysis; and • Criticality analysis locates and reduces high-risk problems and
• Conduct of a “criticality analysis” to identify the most critical is performed at the beginning of a project.
functions of the software. • It identifies the functions and units which are required to
• Various approaches in development can provide early product implement critical program functions or quality requirements
information to software V&V. (e.g., safety, computer security). The steps of the analysis are:
• These include: prototypes, incremental software development, • — Develop a block diagram or control-flow diagram of the
and handing over each unit or sub function following system and its software. Each block or control-flow box
development unit testing. Incremental software development represents a system or software function (unit).

57
 • — Trace each critical function or quality requirement through throughout the software development process adds
SYSTEMS ANALYSIS

the block or control flow diagram. significantly more chance for error.
• — Classify all traced software functions (units) as critical to • Software requirements V&V is intended to prevent these
either the proper execution of critical software functions or the problems from occurring.
quality requirements. • Design errors can be introduced by misrepresentation of the
• — Focus additional analysis on these traced software functions functional requirements and by implementation constraints
(units). relating to timing, data structures, memory space, and accuracy.
• — Repeat criticality analysis for each activity to observe whether • Software design V&V provides assurance that software
the implementation details shift the criticality emphasis to other requirements are not misrepresented or incompletely
or additional functions (units). implemented; that extraneous software requirements are not
• System hazard analysis is used to identify potential events and designed into the solution by oversight; that software
circumstances that might lead to problems of varying degrees requirements are not left out of the software design; and that
of severity, from critical failures resulting in loss of life or other constraints are managed correctly.
national security problems, to less serious malfunctions in the • Clerical and syntactical errors have been greatly reduced through
system. use of structured programming, reuse of code, adoption of
• Software hazard (or threat) analysis focuses on the role of programming standards and style guides, availability of more
software relative to the hazards, or threats. robust computer languages, better compiler diagnostics and
automated support, and, finally, more knowledgeable
• Specific techniques that can be used for hazard analysis are programmers.
included in section 6 with the V&V techniques; these include
event tree analysis, software fault tree analysis, • Nevertheless, problems still occur in translating design into
code and code V&V continues to be an important software
• When identification of high risk areas from early deliveries, V&V activity.
criticality analysis, and hazard (or threat) analysis are used
together, the software V&V approach can focus on the most • Test management is an important part of the software V&V
critical areas of the early software products. activity in which all testing needed for the software system is
considered and planned.
• Software V&V results, obtained early enough in the software
development process, can have significant impact on the quality • Software V&V test planning begins with software requirements
and performance of the system under development. and spans almost the full range of activities.

Software V&V Activities • Test planning tasks encompass different types of testing—
unit test, software integration test, and software system test.
• Software V&V should begin when the project begins. Usually The planning activities result in documentation for each test
the first software V&V tasks are conducted during the software type consisting of test plan, test design, test case, and test
requirements V&V activity. procedure documents.
• One V&V task is to examine the early project documentation, • Unit test verifies the design and implementation of software
often called concept documents, to verify that the system to be units. Software integration test verifies functional requirements
built is not only feasible but will use the rules, conventions, as the software units are integrated together.
algorithms, and practices appropriate to the application domain
of the system. • Special attention is focused on software, hardware, and operator
interfaces. Software system test validates the entire software
• Software requirements V&V is performed to ensure that the program against system requirements and software performance
specified software requirements are correct, complete, consistent, objectives.
accurate, readable, and testable, and will satisfy the system
requirements. • Software system tests validate that the software executes correctly
within its stated operating environment. The software’s ability
• Poorly specified software requirements (e.g., incorrect, to deal properly with anomalies and stress conditions is
incomplete, ambiguous, or not testable) contribute to software emphasized.
cost overruns and problems with reliability.
• Software V&V tests are not intended to duplicate or replace the
• Even when software fully meets its requirements upon delivery, user and development group’s test responsibilities, but instead
there may be problems in the maintenance activity because test behavior not normally checked by the user or development
general requirements (e.g., maintainability, quality, and group.
reusability) were not accounted for during the original
development.
• Software installation test validates that the software operates
correctly with the operational hardware system and with other
• Identifying software requirements is difficult because the software, as specified in the interface specifications.
complexity of the problems being solved causes uncertainty in
developing the intended system performance requirements.
• It verifies that the installation procedures are correct and
adequate, that the software is the same as the executable code
• The occurrence of changes in requirements (e.g., to incorporate delivered for installation, and that all supporting software
new technologies, new missions, new knowledge, new products are the proper versions.
interfacing systems, new people coming on the scene)

58
• Software installation test verifies that the software has been Systems analysis and design methods

SYSTEMS ANALYSIS
accurately tailored for site-dependent parameters and that the 5th ed. New Delhi : Galgotia Publications, 2001
configuration of the delivered product is correct.
Shelly, Gary B
• In software operation and maintenance V&V, when a software Systems analysis and design
change is made, all software V&V activities are considered and
3rd ed. New Delhi : Galgotia Publications, 1999
possibly repeated to ensure that nothing is overlooked.
Awad, Elias M.
• Software V&V activities include examining the impact of the Systems analysis and design
change throughout the system to understand what software
V&V activities are needed. Software V&V activities are added New Delhi : Galgotia Publications, 1997
or deleted to address the type of software change made. Hoffer, Jeffrey A.
• In many cases, an examination of the proposed software change Modern systems analysis and design
shows that software V&V needs to repeat its activities on only 2nd ed. Delhi : Pearson Education Asia, 2000
a small portion of the software. Sarkar, A.K.
• Also, some software V&V activities, such as verifying the original Systems analysis, data processing and
concepts, require little or no effort to verify a small change. quantitative techniques
• Small changes can have subtle but significant side-effects in a New Delhi : Galgotia Publications, 1997
software program; for this reason, change analysis (a software Hawryszkiewycz, Igor
operation and maintenance V&V task) is significant in Introduction to systems analysis & design
preventing unintended functions and problems from making
4th ed. New Delhi : Prentice Hall of India, 2002
their way into new versions of the system.
Notes
Review
Independent V&V
Technical independence
Managerial independence
Financial independence
Software V&V management, activities
Questions
Explain about Independent V&V
1
2
3
4
5
Differentiate between various IV&V.
1
2
3
4
5
Explain about the software V&V activities.
1
2
3
4
5
References
Heuring, Vincent P.
Computer systems design and architecture
Delhi : Pearson Education Asia, 1997
Whitten, Jeffrey L.

59
 LESSON 14 :
SYSTEMS ANALYSIS

VERIFICATION AND VALIDATION

Topics covered • By verifying that the software design meets its software
• Software Requirements V&V requirements, the software design V&V activity also supports
validation that the software design meets system requirements.
• Software Design V&V, Code Verification
• When the software system is designed, decisions may be made
• Unit
to incorporate existing software.
• Integration The tasks and techniques are the same as for the software being
• Software System Test developed, but the objectives and issues are specific for reuse.
Objectives General
Upon completion of this Lesson, you should be able to: • Conduct a software design traceability analysis - Trace software
Explain Software Requirements V&V design to software requirements, and vice versa. Check the
relationships for accuracy, completeness, consistency, and
Explain Software Design V&V
correctness.
Software Requirements V&V • Conduct a software design evaluation.
• The software requirements V&V activity checks that the • Evaluate the software design for accuracy, completeness,
allocation of system requirements to software is appropriate consistency, correctness, and testability.
and correct, and how well the software requirements have been
specified (e.g., correct, complete, nonambiguous, testable). • Evaluate software design for compliance with software design
standards; language standards if appropriate; and software
• It should be structured to ensure that the software objectives engineering practices.
have been met. Verification of the software requirements should
include an examination of documentation produced earlier in • Assess software design against assigned quality attributes.
system development (e.g., initial feasibility studies, concepts • Conduct a software design interface analysis - Evaluate software
on which the system has been designed) if this examination design for accuracy, completeness, consistency, and correctness
has not already been performed. of hardware, operator and software interface requirements.
• If the assumptions, algorithms, and physical rules imposed • Verify that the software requirements for assertions, responses
on the software requirements previously have not been verified to assertions and other required system algorithm and integrity
to be appropriate for this project, then software V&V should checks or fault tolerance protections have been designed into
perform those checks. the software. Check that the software design is complete and
• Inputs to the software requirements V&V activity may be accurate and will not adversely affect system performance.
documents written in natural or formal mathematical languages • Coordinate with software integration test planning.
and may include graphics and charts. Reuse -Specific
• When formal mathematical languages are used, other forms of • Conduct an evaluation of the original software design
representations may be provided to different users of the documentation for compliance to software design requirements
specifications. of the new system. Verify interface requirements.
• Concurrently with software requirements V&V, software system • Generate any needed software design information or justify
test planning in initiated. the use of the software without the required information. This
Software V&V examines all the proposed testing for the system determination should be based on recognized risk (safety, cost
to ensure that comprehensive testing and appropriate resources of modifications, impact of various degrees of uncertainty on
are planned. the project) and coordinated with the user.
Software Design V&V • If any modifications are needed, evaluate whether or not the
Ø The software design V&V activity occurs after the software software and documentation are adequate to support the
requirements have undergone the software V&V process and modification (e.g., for change analysis, testability). If not, the
the software design, or an increment of the software design, needed information should be obtained or developed. If this
has been completed. is not prudent, modifications should not be made when they
cannot be supported by adequate software design information.
Ø The software V&V tasks of trace ability, evaluation, and interface
analysis provide assurance that software requirements are not KBS -Specific
misrepresented, incompletely implemented, or incorrectly • — Verify that the domain model:
implemented. • - Is complete and consistent; and,
• - Represents the domain knowledge.

60
• — Verify that the domain model addresses, at the required • Evaluate draft code-related documents (e.g., user manual,

SYSTEMS ANALYSIS
level of accuracy and completeness, the range of expected commentary within the code) with source code for completeness,
problems. consistency, and correctness.
• — Verify that the domain model operates in the specified scope. • Coordinate with unit test (8).
Code Verification Reuse-Specific
• The code verification activity verifies correct implementation of • If the source code is available, compare it to known design
software design into code. specifications. Evaluate for correctness, consistency,
• Often this activity requires tedious checking of details within completeness, and accuracy. Assess the interfaces for consistency
the code; automation provides protection against human error with the system in which the reused code will be placed. Assess
in gathering the code information for analysis and also can source code quality. (This task may be needed in instances where
speed the process. the history of the code is not well-known.)
• Code verification is the last opportunity to find and remove • Evaluate source code for testability. Evaluate code-related
errors that could cause unnecessary costs and delays from documentation received from the source for suitability for any
advancing poor code into any of the test activities. future modifications.
• At this point in the software development process, the reuse KBS-Specific
issues should have been examined and the decision made to • Conduct a logical verification of the structure of the knowledge
reuse or not to reuse the software. and rules in the knowledge base for consistency, completeness,
• In the case that changes are to be made to the code, or if there etc.
is a possibility changes will be needed in a future version of the • Verify that the knowledge base implements the domain model
software system under development, some software V&V tasks accurately.
may be needed.
Unit Test
• The knowledge base should be internally consistent and reflect
the domain model. In its simplest form, maintaining
• Unit test is the test of the software elements at the lowest level
of development. Units may be aggregates of software elements.
knowledge base consistency (or integrity) means not allowing a
fact and its negation to both be part of the knowledge base. • Planning for unit test should occur concurrently with the
More extensive consistency checks can disallow rules that would, software design activity. Reused software will probably not
potentially, infer both a fact and its negation. Knowledge undergo unit test; unless changes were made to the units.
consistency is a key issue. • Then, appropriate testing is performed as in regression testing.
• A consistent domain model and a consistent representation General
of that model is critical. This is especially true for domains
• Test planning - Establish the objectives of the unit test, the
representing physical structures or controlled equipment.
strategies to be employed, the coverage requirements, reporting
• The model of the equipment and the physics controlling the and analysis, and close-out of anomalies.
behavior of the equipment must be consistent for computer
• Generate, monitor, and update the unit test plan to accomplish
controllers to function properly. In other domains, expert
objectives.
disagreement over the interpretation of a set of facts may be
normal and expected. • Trace test design, cases, procedures, and execution results to
the unit designs.
• For example, legal disputes frequently involve the interpretation
of the facts themselves. Probabilities can be one way to handle • Confirm that anomalies during test are software anomalies,
conflicting knowledge. and not problems detected for other reasons.

General • Generate test cases and procedures - Develop test cases and
procedures for unit test and continue tracing as required by
• Conduct a source code traceability analysis - Trace source code software test plans.
to software design, and vice versa. Check the relationships for
accuracy, completeness, consistency, and correctness.
• Perform unit test - Check individual software units for
typographical, syntactic, and logic errors to ensure that each
• Conduct a source code evaluation. correctly implements the software design and satisfies the
• Evaluate the source code for accuracy, completeness, consistency, software requirements; execute the test cases; analyze results to
correctness, and testability. verify anomalies; recommend changes to software design or
• Evaluate source code for compliance with code standards, code; and conduct re-testing as necessary.
language standards if appropriate, and software engineering • Document test activities and results.
practices.
Reuse-Specific
• Assess source code against assigned quality attributes. • Evaluate existing test cases and reports for suitability for
• Conduct a source code interface analysis - Evaluate the source intended use.
code for accuracy, completeness, consistency, and correctness
with respect to the hardware, operator, and software interfaces.

61
 • Prepare test cases and test procedures if any modifications are Reuse-Specific
SYSTEMS ANALYSIS

made to the reused software. • Perform software integration test in accordance with test
• Follow the criteria for unit test. procedures.
KBS-Specific • Analyze results to determine if the software implements the
• Evaluate the knowledge and rules in the knowledge base against intended use requirements and known design and that the
the domain knowledge. software units function correctly together.

• Establish objective for testing portions of domain knowledge. • Conduct interface tests of reused units with other system
components.
• Plan tests for accuracy and completeness of domain model.
• Conduct tests of reused units with other system components
• Define test procedures to test for expected performance level to validate performance requirements.
of the system.
• Evaluate existing test cases and reports for suitability for
Software Integration Test intended use.
• Software integration tests check the interaction with other • Prepare test cases and test procedures if any modifications are
software (e.g., libraries) and hardware. made to the reused software.
• The software integration test schedule depends upon the • Follow the criteria for software integration test.
development and integration schedules for software units,
hardware, and other components. KBS-Specific

• For large systems, software integration test planning may require • Evaluate knowledge base for completeness and consistency.
close coordination among all system personnel to ensure that • Verify that the knowledge base represents the full scope of the
the overall test objectives are achieved by the selected test domain model.
strategy. Software System Test
• When all system components have been integrated and have Software system test, in the context of software V&V, involves
successfully undergone software integration tests, then the the conduct of tests to execute the completely integrated system.
system moves into software system test. Software system test is the validation that the software meets its
• During software integration test, reused software units are requirements. Validation of the complete system may involve
integrated into the system. I many tests involving all system components.
• t is critical to test that the interfaces are correct, and that the The software system tests exercise those system functions that
resulting software meets operating requirements. invoke software to determine whether the software behaves as
intended relative to complete system performance.
General
• Test planning - Establish the objectives of the software These tests must be conducted in such a manner as to stress the
integration test, the strategies to be employed, the coverage system based on software responses to system inputs (e.g., from
requirements, reporting and analysis, and close-out of sensors, operators, databases).
anomalies. Ensure that interface testing of reused software to While software system tests are conducted after the system has
other system software is planned. been built, it is imperative that planning for these tests is conducted
• Generate, monitor, and update a software integration test plan concurrently with the software requirements activity because:
to accomplish identified objectives. • Analyzing the software requirements for test requirements may
• Trace test design, cases, procedures, and execution results to result in finding software requirements errors and/or discovery
software requirements. of untestable requirements.

• Generate test cases and procedures - Develop test cases and • Establishing test facilities (e.g., model of operational
procedures for unit test and continue tracing as required by environment) and Computer-Aided Software Engineering
software test plans. (CASE) tools (e.g., test case generators, test data base) may
require as much time as development of the system.
• Perform software integration test.
• For reused software, software system test is performed to assure
• Check the inter-unit communication links and test aggregate that the software is correct, consistent with prior documentation,
functions formed by groups of units. complete for use and/or modification, and accurate.
• Confirm that anomalies during test are software anomalies, • At the system level, reused software should be considered part
and not problems detected for other reasons. of the system. Tests are in accordance with test procedures.
• Ensure any changes to software requirements, software design, • Results are documented and traced as required by the software
or code are made. Conduct retesting as necessary. system test plan.
• Conduct functional, structural, performance, statistical, and
coverage testing of successfully integrated units after each
General
iteration of software integration and successful testing of
interfaces and interactions.
• Document test activities and results.

62
• Test planning - Establish the objectives of the software system Awad, Elias M.

SYSTEMS ANALYSIS
test, the strategies to be employed, the coverage requirements, Systems analysis and design
reporting and analysis, and close-out of anomalies. New Delhi : Galgotia Publications, 1997
• Generate, monitor, and update a software system test plan to Hoffer, Jeffrey A.
accomplish objectives. Modern systems analysis and design
• Trace system and software requirements to test software design, 2nd ed. Delhi : Pearson Education Asia, 2000
cases, procedures, and execution results.
Sarkar, A.K.
• Generate test cases and procedures - Develop test cases and Systems analysis, data processing and
procedures for unit test and continue tracing as required by quantitative techniques
software system test plans.
New Delhi : Galgotia Publications, 1997
• Test the operation of the software as an entity (sometimes a
Hawryszkiewycz, Igor
simulated environment may be used); confirm that anomalies
Introduction to systems analysis & design
during test are software anomalies, not problems detected for
other reasons; ensure any changes to software (software 4th ed. New Delhi : Prentice Hall of India, 2002
requirements, software design, code, or test cases) have been Notes
made; and conduct retesting as necessary.
• Document test activities and results.
Reuse-Specific
• Evaluate existing test cases and reports for suitability for
intended use.
• Prepare test cases and test procedures if any modifications have
been made to the reused software.
• Follow the criteria for software system test within the boundaries
of the known and documented software design.
KBS-Specific
• Define procedures for testing the system according to the
expected knowledge of the end user.
Questions
Explain about Software Requirements V& V
1
2
3
4
5
Explain about code verification.
1
2
3
4
5
References
Heuring, Vincent P.
Computer systems design and architecture
Delhi : Pearson Education Asia, 1997
Whitten, Jeffrey L.
Systems analysis and design methods
5th ed. New Delhi : Galgotia Publications, 2001
Shelly, Gary B.
Systems analysis and design
3rd ed. New Delhi : Galgotia Publications, 1999

63
 LESSON 15 :
SYSTEMS ANALYSIS

VERIFICATION AND VALIDATION

Topics covered documented, and operators have received training in new or

• Software Installation technique changed procedures.
• Software operation & Maintenance Verification and Validation • The software maintenance V&V activity requires planning for
Phase software V&V based on the extent of the maintenance (e.g.,
adaptive, corrective, perfective ,and hence a revisit of all the
• Strategies for checking techniques. software development activities to identify to what extent each
Objectives software V&V activity must be performed.
Upon completion of this Lesson, you should be able to: • If software V&V has not been performed during software
Explain about software installation technique development, then the V&V during software operations and
Explain the software operation & maintenance V&V maintenance must consider performing a selected set of tasks
from the software V&V activities related to earlier development
Explain about different strategies for checking techniques. activities.
Software Installation Test • Some activities may include generating software requirements
• The software installation test activity is the final step before or software design information from source code, an activity
launching full customer acceptance testing. known as reverse engineering. While costly and time
• The purpose of installation test is to demonstrate that the consuming, it is necessary when the need exists for rigorous
correct software has been delivered and that the software software V&V effort.
interfaces are correct relative to any interfaces at the installation General
site. • — Conduct an anomaly evaluation - Evaluate the severity of
• Acceptance testing, which involves the user/customer, is anomalies during software operation and their effect on the
outside the scope of this document. system.
General • — Conduct a proposed change assessment - Assess proposed
• — Conduct an installation configuration audit. changes to the software and their effect on the system to
determine software V&V activities from earlier development
• Determine that all software outputs needed to operate the to be repeated. Conduct them.
system are present.
• — Develop an SVVP.
• Check that the software installed in the system is the software
that underwent software V&V. KBS-Specific
• — Develop and execute tests that will examine and stress site- • — Plan for update of knowledge base including domain model.
unique parameters (e.g., printer interface, operating system • — Determine mechanisms used for updating knowledge base.
interface, monitor interfaces).
Software V&V Techniques
• — Generate applicable documentation.
• The conduct of software V&V tasks to fulfill the requirements
• — Generate an SVVR (or generate it at the end of the software of the V&V activities generally involves techniques selected
V&V process). from three major classes: static, dynamic, and formal analysis.
Reuse-Specific • Static analysis techniques are those which directly analyze the
• — Conduct an installation configuration audit to verify that form and structure of a product without executing the product
any reused software that has not been modified is the current • Reviews, inspections, audits and data flow analysis are examples
version. of static analysis techniques.
KBS-Specific Static Analysis Techniques
• — Ensure that data and updates to the knowledge base which • Are traditionally applied to software requirements, software
are supplied from external sources are in an acceptable form. design and source code.
Software Operation and Maintenance • They may also be applied to test documentation, especially test
V&V cases, to verify their traceability to the software requirements,
Ø The software operation V&V activity requires periodic checks their adequacy to fulfill test requirements, and their accuracy.
that the integrity of the system has been maintained, that any Dynamic analysis techniques
changes to the system which affect its operation have been

64
• Involve execution, or simulation, of a development activity • Some software V&V techniques used during code V&V tasks

SYSTEMS ANALYSIS
product to detect errors by analyzing the response of a product are control flow analysis, database analysis, regression analysis,
to sets of input data . and sizing and timing analysis.
• For these techniques, the output values, or ranges of values, • For large code developments, control flow diagrams showing
must be known. the hierarchy of main routines and their sub functions are
• Testing is the most frequent dynamic analysis technique. useful in understanding the flow of program control.
Prototyping, especially during the software requirements V&V • Database analysis is performed on programs with significant
activity, can be considered a dynamic analysis technique; in this data storage to ensure common data and variable regions are
case the exact output is not always known but enough used consistently between all call routines.
knowledge exists to determine if the system response to the • Data integrity is enforced and no data or variable can be accidentally
input stimuli meets system requirements. overwritten by overflowing data tables. Data typing and use are
• Formal analysis is the use of rigorous mathematical techniques consistent throughout all program elements.
to analyze the algorithms of a solution . • Regression analysis is used to reevaluate software requirements
• Sometimes the software requirements may be written in a and software design issues whenever any significant code change
formal specification language (e.g., VDM, Z) which can be is made.
verified using a formal analysis technique like proof-of- • This technique ensures project awareness of the original system
correctness. requirements.
• The term formal often is used to mean a formalized process, • Sizing and timing analysis is done during incremental code
that is, a process that is planned, managed, documented, and is development and compared against predicted values. Significant
repeatable. In this sense, all software V&V techniques are formal, deviations between actual and predicted values is a possible
but do not necessarily meet the definition of the mathematical indication of problems or the need for additional examination.
techniques involving special notations and languages.
• Another area of concern to software V&V is the ability of
Strategies for Choosing Techniques compilers to generate object code that is functionally equivalent
• Some software V&V techniques used during software to the source code, that is, reliance on the correctness of the
requirements V&V tasks are control flow analysis, data flow language compiler to make data dependent decisions about
analysis, algorithm analysis, and simulation. abstract programmer coded information.
• Control and data flow analysis are most applicable for real time • For critical applications, this problem is solved by validating
and data driven systems. the compiler or by validating that the object code produced by
the compiler is functionally equivalent to the source.
• These flow analyses transform logic and data requirements text
into graphic flows which are easier to analyze than the text. • Code reading is another technique that may be used for source
PERT, state transition, and transaction diagrams are examples code verification. An expert reads through another
of control flow diagrams. programmer’s code to detect errors. In an experiment conducted
• Algorithm analysis involves re-derivation of equations or at the National Aeronautics and Space Administration Goddard
evaluation of the suitability of specific numerical techniques. Space Flight Center, code reading was found to be more effective
than either functional testing or structural testing.
• Simulation is used to evaluate the interactions of large, complex
systems with many hardware, user, and other interfacing • The reason was attributed to the expertise of the readers who,
software units. as they read the code, were simulating its execution and were
able to detect many kinds of errors.
• Some software V&V techniques used during software design
V&V tasks include algorithm analysis, database analysis, sizing • Other techniques commonly used are walkthroughs,
and timing analysis, and simulation. inspections and reviews.
• These tasks occur in interactive meetings attended by a team
• Algorithm analysis examines the correctness of the equations
which usually includes at least one member from the
or numerical techniques as in the software requirements activity,
development group. Other members may belong to the
but also examines truncation and round-off effects, numerical
development group or to other groups involved in software
precision of word storage and variables (e.g., single- vs.
development.
extended-precision arithmetic), and data typing influences.
• Database analysis is particularly useful for programs that store • The duration of these meetings is usually no more than a few
hours in which code is examined on a line-by-line basis. In
program logic in data parameters.
these dynamic sessions, it may be difficult to examine the code
• A logic analysis of these data values is required to determine thoroughly for control logic, data flow, database errors, sizing,
the effect these parameters have on program control. Sizing timing and other features which may require considerable
and timing analysis is useful for real-time programs having manual or automated effort. Advance preparation for these
response time requirements and constrained memory execution activities may be necessary and includes code analysis techniques.
space requirements.
• The results of these techniques provide appropriate engineering
information for discussion at meetings where code is evaluated.

65
 • Regardless of who conducts or participates in walkthroughs • The selection of V&V techniques for use on each critical area of
SYSTEMS ANALYSIS

and inspections, software V&V analyses may be used to the program is a method of tailoring the intensity of the
support these meetings. software V&V against the type of risk present in each area of
• A comprehensive test management approach to testing the software.
recognizes the differences in strategies and in objectives for • For example, software V&V would apply algorithm analysis to
unit, software integration, and software system test. critical numerical software functions, and techniques such as
• Unit test verifies the design and implementation of software sizing and timing analysis, data and control flow analysis and
units. Software integration test verifies functional requirements interface analysis to real-time executive functions.
as the software units are integrated. Descriptions of Techniques The following are summary
• Special attention is focused on software, hardware, and operator descriptions of techniques taken from [BAHILL], [BEN],
interfaces. Software system test validates the entire software [EWICS3], [KIRANI], [NBS93], [NGUYEN], [NIST209],
program against system requirements and software performance [NIST5589], [NUREG6316], [OKEEFE], [OLEARY],
objectives. Software system tests validate that the software [TURING], [VOAS91,92,95], [WALLACE94], and [WILEY].
executes correctly within its stated operating environment. Algorithm analysis examines the logic and accuracy of the software
• The software’s ability to deal properly with anomalies and stress requirements by translating algorithms into some language or
conditions is emphasized. structured format. The analysis involves rederiving equations or
evaluating the suitability of specific numerical techniques. It checks
• These tests are not intended to duplicate or replace the user and
that algorithms are correct, appropriate, stable, and meet all accuracy,
development group’s test responsibilities, but instead
timing, and sizing requirements. Algorithm analysis examines
supplement the development testing to test behavior not
the correctness of the equations and numerical techniques,
normally tested by the user or development group.
truncation and rounding effects, numerical precision of word
• Effective testing requires a comprehensive understanding of storage and variables (single vs. extended-precision arithmetic),
the system. Such understanding develops from systematically and data typing influences. Issues: accuracy; algorithm efficiency;
analyzing the software’s concept, requirements, design, and correctness; consistency in computation; error propagation;
code. numerical roundoff; numerical stability; space utilization
• By knowing internal software details, software V&V testing is evaluation; system performance prediction; timing.
effective at probing for errors and weaknesses that reveal hidden Analytic modeling provides performance evaluation and capacity
faults. planning information on software design. It represents the
• This is considered structural, or white-box, testing. It often program logic and processing of some kind of model and analyzes
finds errors for which some functional, or black-box, test cases it for sufficiency. Issues: accuracy; algorithm efficiency; bottlenecks;
can produce the correct output despite internal errors. error propagation; feasibility; modeling; numerical roundoff;
• Functional test cases execute part or all of the system to validate numerical stability; processing efficiency; system performance
that the user requirement is satisfied; these test cases cannot prediction.
always detect internal errors that will occur under special Back-to-back testing detects test failures by comparing the output
circumstances. of two or more programs implemented to the same specification.
• Another software V&V test technique is to develop test cases The same input data is applied to two or more program versions
that violate software requirements. and their outputs are compared to detect anomalies. Any test data
selection strategy can be used for this type of testing, although
• This approach is effective at uncovering basic design assumption
random testing is well suited to this approach. Also known as
errors and unusual operational use errors.
comparison testing. Issues: anomalies or discrepancies between
• The process of planning functional test cases requires a versions.
thorough examination of the functional requirements.
Boundary value analysis detects and removes errors occurring at
• An analyst who carefully develops those test cases is likely to parameter limits or boundaries. The input domain of the program
detect errors and omissions in the software requirements. is divided into a number of input classes. The tests should cover
• In this sense test planning can be effective in detecting errors the boundaries and extremes of the classes. The tests check that
and can contribute to uncovering some errors before test the boundaries of the input domain of the specification coincide
execution. with those in the program. The value zero, whether used directly
• The planning process for testing must take into account the or indirectly, should be used with special attention (e.g., division
specific objectives of the software V&V for the software and by zero, null matrix, zero table entry). Usually, boundary values of
the impact of different test strategies in satisfying these the input produce boundary values for the output. Test cases
objectives. should also be designed to force the output to its extreme values.
• Frequently, the most effective strategy may be to combine two If possible, a test case which causes output to exceed the specification
or more strategies. boundary values should be specified. If output is a sequence of
data, special attention should be given to the first and last elements
• Criticality analysis may be used to identify software V&V and to lists containing zero, one, and two elements. Issues:
techniques to address high-risk concerns. algorithm analysis; array size; inconsistencies between limits;
specification error.

66
Code reading involves an expert reading through another Decision (truth) tables provide a clear and coherent analysis of

SYSTEMS ANALYSIS
programmer’s code to detect errors. The individual is likely to complex logical combinations and relationships. This method
perform a pseudo-execution (mentally) of the code to pick up uses two-dimensional tables to concisely describe logical
errors before compilation. Issues: correctness; misuse of variables; relationships between boolean program variables. Issues: logic
omitted functions; parameter checking; poor programming errors.
practices; redundancy. Desk checking involves the examination of the software design or
Control flow analysis transforms text describing software code by an individual, usually an expert other than the author, for
requirements into graphic flows where they can be examined for obvious errors. It can include looking over the code for obvious
correctness. It checks that the proposed control flow is free of defects, checking for correct procedure interfaces, reading the
problems (e.g., unreachable or incorrect software design). Control comments to develop a sense of what the code does and then
flow analysis is used to show the hierarchy of main routines and comparing it to its external specifications, comparing comments
their subfunctions and checks that the proposed control flow is to software design documentation, stepping through with input
free of problems (e.g., unreachable or incorrect code elements). It conditions contrived to “exercise” all paths including those not
detects poor and potentially incorrect program structures. Issues: directly related to the external specifications, and checking for
assertion testing/violations; bottlenecks; boundary test cases; compliance with programming standards and conventions. Issues:
branch and path identification; branch testing; cell structure of anachronistic data; calls to subprograms that do not exist; data
units; correctness; software design evaluation; error propagation; fields unconstrained by data boundaries; failure to implement the
expected vs. actual results; file sequence error; formal specification design; failure to save or restore registers; improper nesting of
evaluation; global information flow and consistency; hierarchical loops and branches; improper program linkages; improper
interrelationship of units; inaccessible code; software integration sequencing of processes; incomplete predicates; incorrect access of
tests; inter-unit structure; loop invariants; path testing; processing array components; inefficient data transport; infinite loops;
efficiency; retest after change; system performance prediction; test initialization faults; input-output faults; instruction modification;
case preparation; unit tests. inverted predicates; mismatched parameter lists; missing labels or
Coverage analysis measures how much of the structure of a unit code; missing validity tests; misuse of variables; prodigal
or system has been exercised by a given set of tests. System level programming; unauthorized recursion; undeclared variables;
coverage measures how many of the unit parts of the system unreachable code; unreferenced labels.
have been called by a test set. Code coverage measures the Review
percentage of statements, branches, or lines of code (LOC) exercised
Software Installation technique
by a test set. Issues: unit tests, software integration tests, software
system tests. Software operation & Maintenance Verification and

Critical timing/flow analysis checks that the process and control Validation PhaseStrategies for checking techniques.]
timing requirements are satisfied by modeling those aspects of Various Techniques
the software design. Issues: modeling; synchronization; timing. Questions
Database analysis ensures that the database structure and access Explain about Software Installation technique
methods are compatible with the logical design. It is performed
1
on programs with significant data storage to ensure that common
data and variable regions are used consistently between all calling 2
routines; that data integrity is enforced and no data or variable can 3
be accidentally overwritten by overflowing data tables; and that 4
data typing and use are consistent throughout the program. Issues:
5
access protection; data characteristics and types; software design
evaluation; file sequence error; global information flow; processing Explain about operation and maintenance V&V.
efficiency; space utilization evaluation; unit tests. 1
Data flow analysis is important for designing the high level 2
(process) architecture of applications. It can check for variables 3
that are read before they are written, written more than once
4
without being read, and written but never read. Issues: assertion
testing/violations; bottlenecks; boundary test cases; branch and 5
path identification; branch testing; cell structure of units; data Explain about software V&V techniques.
characteristics; environment interaction; error propagation; 1
evaluation of program paths; expected vs actual results; file sequence
2
error; global information flow and consistency; hierarchical
interrelationship of units; inter-unit structure; loop invariants; 3
processing efficiency; retest after changes; software design 4
evaluation; software integration tests; system performance 5
prediction; test case preparation; uninitialized variables; unused
variables; variable references.

67
 Discuss the various types of techniques used in V&V.
SYSTEMS ANALYSIS

1
2
3
4
5
References
Heuring, Vincent P.
Computer systems design and architecture
Delhi : Pearson Education Asia, 1997
Whitten, Jeffrey L.
Systems analysis and design methods
5th ed. New Delhi : Galgotia Publications, 2001
Shelly, Gary B.
Systems analysis and design
3rd ed. New Delhi : Galgotia Publications, 1999
Awad, Elias M.
Systems analysis and design
New Delhi : Galgotia Publications, 1997
Hoffer, Jeffrey A.
Modern systems analysis and design
2nd ed. Delhi : Pearson Education Asia, 2000
Sarkar, A.K.
Systems analysis, data processing and
quantitative techniques
New Delhi : Galgotia Publications, 1997
Hawryszkiewycz, Igor
Introduction to systems analysis & design
4th ed. New Delhi : Prentice Hall of India, 2002
Notes

68
 LESSON 16 :

SYSTEMS ANALYSIS
VERIFICATION AND VALIDATION

Topics covered Inspections are evaluation techniques whereby the software

Software V&V Techniques requirements, software design, or code are examined by a person
or group other than the author to detect faults, violations of
Objectives development standards, and other problems. An inspection
Upon completion of this Lesson, you should be able to: begins with the distribution of the item to be inspected (e.g., a
Explain about Various techniques used in V& V also relate with specification). Each participant is required to analyze the item on
the various phases in SDLC. his own. During the inspection, which is a monitored meeting of
Software V&V Techniques all the participants, the item is jointly analyzed to find as many
Error seeding determines whether a set of test cases is adequate errors as possible. All errors found are recorded, but no attempt is
by inserting ( seeding ) known error types into the program and made to correct the errors at that time. However, at some point in
executing it with the test cases. If only some of the seeded errors the future, it must be verified that the errors found have actually
are found, the test case set is not adequate. The ratio of found been corrected. Issues: accuracy; checklists (software requirements,
seeded errors to the total number of seeded errors is an estimation software design, code); effective forerunners to testing; formal
of the ratio of found real errors to total number of errors, or specification evaluation; go-no-go decisions; information flow
consistency; logic errors; loop invariants; manual simulation; retest
Number Seeded Errors Found Number Real Errors Found
after change; space utilization evaluation; technical reviews; status
—————————— = —————————— reviews; syntax errors; uninitialized variables; unused variables.
Total Number Seeded Errors Total Number Real Errors Interface analysis is a static analysis technique. It is used to
One can solve for the total number of real errors, since the values demonstrate that the interfaces of subprograms do not contain
of the other three are known. Then, one can estimate the number any errors that lead to failures in a particular application of the
of errors remaining by subtracting the number of real errors found software. Interface analysis is especially important if interfaces do
from the total number of real errors. The remaining test effort can not contain assertions that detect incorrect parameter values. It is
then be estimated. If all the seeded errors are found, this indicates also important after new configurations of pre-existing
that either the test case set is adequate, or that the seeded errors subprograms have been generated. The types of interfaces that are
were too easy to find. Issues: test case adequacy. analyzed include external, internal, hardware/hardware, software/
Event tree analysis uses a bottom-up approach to model the software, software/hardware, and software/database. Issues:
effects of an event that may have serious repercussions. The actual and formal parameters mismatch; inconsistencies between
initiating event is the root of the event tree. Two lines are drawn subroutine usage list and called subroutine; inconsistency of
from the root, depicting the positive and negative consequences attributes of global variables; inconsistency between COTS
of the event. This is done for each subsequent consequence until parameter usage relative to other system parameters; incorrect
all consequences are considered. Issues: hazard analysis; safety; assumptions about static and dynamic storage of values; incorrect
threat analysis; timing. functions used or incorrect subroutine called; input-output
Finite state machines (FSM) check for incomplete and description errors.
inconsistent software requirements by modeling the software in Interface testing is a dynamic analysis technique. Similar to
terms of its states, inputs and actions. For example, a system is in interface analysis, except test cases are built with data that tests all
state S1, receives an input I, then carries out action A, and moves interfaces. Interface testing may include the following: testing all
to state S2. FSMs can check that there is an action and new state for interface variables at their extreme positions; testing interface
every input in every state, and that only one state change is defined variables individually at their extreme values with other interface
for each state and input pair. Issues: incomplete software variables at normal values; testing all values of the domain of
requirements specification; inconsistent software requirements; each interface variable with other interface variables at normal values;
modeling. testing all values of all variables in combination (may be feasible
Functional testing executes part or all of the system to validate only for small interfaces). Issues: actual and formal parameters
that the user requirement is satisfied. Issues: boundary test cases; mismatch; inconsistencies between subroutine usage list and called
branch and path identification; branch testing; file sequence error; subroutine; inconsistency of attributes of global variables;
path testing; program execution characteristics; retest after change; inconsistency between COTS parameter usage relative to other
statement coverage testing; system performance prediction; system parameters; inconsistent interface parameters; incorrect
software system tests; test case preparation; test thoroughness; assumptions about static and dynamic storage of values; functions
unit test; uninitialized variables; unused variables; variable used or incorrect subroutine called; input-output description errors.
references; variable snapshots/tracing. Mutation analysis determines the thoroughness with which a
program has been tested, and in the process, detects errors. This
procedure involves producing a large set of versions or

69
 “mutations” of the original program, each derived by altering a violated. Issues: software integration tests; retest after change;
SYSTEMS ANALYSIS

single element of the program (e.g., changing an operator, variable, software system tests; unit tests.
or constant). Each mutant is then tested with a given collection of Requirements parsing involves examination to ensure that each
test data sets. Since each mutant is essentially different from the software requirement is defined unambiguously by a complete set
original, the testing should demonstrate that each is in fact of attributes (e.g., initiator of an action, source of the action, the
different. If each of the outputs produced by the mutants differ action, the object of the action, constraints). Issues: accuracy;
from the output produced by the original program and from each assertion testing/violations; checklists; completeness; consistency;
other, then the program is considered adequately tested and correct. environment interaction; feasibility; formal specification evaluation;
Issues: boundary test cases; branch and path identification; branch hierarchical interrelationship of units; information flow consistency;
testing; retest after change; test case preparation. software integration tests; inter-unit structure; path testing; proof
Performance testing measures how well the software system of correctness; software requirements evaluation; software
executes according to its required response times, CPU usage, and requirements indexing; software requirements to design correlation;
other quantified features in operation. measurements may be retest after change; standards check; statement coverage testing;
simple to make (e.g., measuring process time relative to volumes software system tests; unit tests.
of input data) or more complicated (e.g., instrumenting the code Reviews are meetings at which the software requirements, software
to measure time per function execution). Issues: memory design, code, or other products are presented to the user, sponsor,
allocation; synchronization; timing. or other interested parties for comment and approval, often as a
Petri-nets model systems to assure software design adequacy for prerequisite for concluding a given activity of the software
catastrophic-failure and other safety problems. The system development process. Reviews check the adequacy of the software
(including software systems) is modeled using conditions and requirements and software design according to a set of criteria and
events represented by state transition diagrams. Petri-nets consist procedures. Issues: effective forerunners to testing; logic errors;
of places (conditions—represented by circles), transitions syntax errors.
(events—represented by bars), inputs (pre-conditions— Sensitivity analysis is a prediction of the probability that a
represented by arrows originating from places and terminating at software testing scheme will make programmer faults observable
transitions), outputs (post-conditions—represented by arrows during testing. It allows different testing strategies to be ranked,
originating from transitions and terminating at places), and tokens compared, and evaluated. Sensitivity analysis is useful for assessing
(indication of true condition—represented by dots). Petri-nets which regions of code are most likely to be affected during software
can be “executed” to see how the software design will actually maintenance (code modifications). It can be twisted into an
work under certain conditions. Specifically, Petri-nets can be used assessment of how fault-tolerant a program is to software
to determine all the states (including hazardous states) the system programmer faults (logic errors). Issues: correctness; logic errors;
can reach, given an initial condition. Issues: hazard analysis; reliability; test case adequacy.
modeling; safety; threat analysis; timing.
Simulation is used to evaluate the interactions of large, complex
Proof of correctness (formal verification) involves the use of systems with many hardware, user, and other interfacing software
theoretical and mathematical models to prove the correctness of a units. Simulation uses an executable model to examine the behavior
program without executing it. Using this method, the program is of the software. Simulation is used to test operator procedures
represented by a theorem and is proved with first-order predicate and to isolate installation problems. Issues: assertion testing/
calculus. Issues: correctness; proof of critical sections. violations; behavior; boundary test cases; branch and path
Prototyping helps to examine the probable results of identification; branch testing; environment interaction; execution
implementing software requirements. Examination of a prototype monitoring, sampling, support; feasibility; file sequence error; inter-
may help to identify incomplete or incorrect software requirements unit structure; path testing; program execution characteristics; retest
and may also reveal if any software requirements will not result in after change; statement coverage testing; system performance
desired system behavior. It can be used as an aid in examining the prediction; software system tests; uninitialized variables; unused
software design architecture in general or a specific set of functions. variables; variable references; variable snapshot/tracing.
For large complicated systems prototyping can prevent Sizing and timing analysis is useful for determining that
inappropriate software designs from resulting in costly, wasted allocations for hardware and software are made appropriately for
implementations. Issues: behavior; omitted functions (from the software design architecture. It is performed during
software requirements); incomplete software requirements incremental code development by obtaining program sizing and
specification; user interface. execution timing values to determine if the program will satisfy
Regression analysis and testing is used to reevaluate software processor size and performance requirements allocated to the
requirements and software design issues whenever any significant software. Significant deviations between actual and predicted values
code change is made. It involves retesting to verify that the modified is a possible indication of problems or the need for additional
software still meets its specified requirements. This analysis ensures examination. Issues: algorithm efficiency; bottlenecks; boundary
awareness of the original system requirements. It is performed test cases; branch and path identification; branch testing; software
when any changes to the product are made during installation to integration tests; processing efficiency; program execution
verify that the basic software requirements and software design characteristics; retest after change; space utilization evaluation;
assumptions affecting other areas of the program have not been software system tests; timing; unit tests.

70
Slicing is a program decomposition technique used to trace an Walkthroughs are similar to reviews, but less formal and much

SYSTEMS ANALYSIS
output variable back through the code to identify all code more detailed. A walkthrough is an evaluation technique in
statements relevant to a computation in the program. This which a designer or programmer leads one or more other
technique may be useful to demonstrate functional diversity. members of the development team through a segment of
Issues: allocation of V&V resources; common code; information software design or code, while the other members ask questions
flow consistency; program decomposition; variable references. and make comments about technique, style, and identify
Software failure mode, effects and criticality analysis reveals possible errors, violations of development standards, and other
weak or missing software requirements by using inductive problems. Issues: checklists; error propagation; effective
reasoning to determine the effect on the system of a unit (includes forerunners to testing; formal specification evaluation; go-no-
software instructions) failing in a particular failure mode. A matrix go decisions; logic errors; manual simulation; parameter
is developed for each unit depicting the effect on the system of checking; retest after change; small, but difficult, or error-prone
each unit’s failure in each failure mode. Items in the matrix may sections of design or code; status reviews; syntax errors; software
include the failure mode and causes, effect on system, criticality, system tests; technical reviews.
change/action required, and prevention and control safeguards. Reuse-Specific
The criticality factor, that is, the seriousness of the effect of the Most V&V techniques are applicable to reused software. Guidance
failure, can be used in determining where to apply other analyses in section 3 provides suggestions on issues to be considered for
and testing resources. Issues: hazard analysis; safety; incomplete deciding to reuse the software; these issues may require application
software requirements specification; threat analysis. of V&V techniques. The two techniques identified in this section
Software fault tree analysis identifies and analyzes software safety are crucial.
requirements. It is used to determine possible causes of known • — Consistency analysis compares the requirements of any
hazards. Its purpose is to demonstrate that the software will not existing software with the new software requirements to ensure
cause a system to reach an unsafe state, and to discover what consistency. Issues: consistency.
environmental conditions would allow the system to reach an • — Interface analysis (see interface analysis and interface testing
unsafe state. The analyst assumes that an already identified hazard above) is especially important to exercise interfaces of reused
has occurred and then works backward to discover the possible software to other parts of the system as part of the planning
causes of the hazard. This is done by creating a fault tree, whose for the reused software, to ensure correct adaption of the reused
root is the hazard. The system fault tree is expanded until it contains code to possible differences in the software architecture,
at its lowest level basic events which cannot be further analyzed. operating environment, and application domain from its
Issues: hazard analysis; safety; threat analysis. original usage.
Stress testing tests the response of the system to extreme
conditions to identify vulnerable points within the software, and
KBS-Specific Techniques
to show that the system can withstand normal workloads. Issues: • — Alternative model compares the domain model
design errors; planning for defaults when system over-stressed. implemented in the KBS to an alternate domain model for
completeness and accuracy.
Structural testing examines the logic of the units and may be
used to support software requirements for test coverage, i.e., how • — Control groups can be used during testing to compare
much of the program has been executed. Issues: bottlenecks; performance on executing a given task with or without the
error propagation; evaluation of program paths; parameter KBS available.
checking; program execution characteristics; retest after change. • — Credibility analysis compares the results of the system to
Symbolic execution shows the agreement between the source known expert s answers and reasoning to the same cases and
code and the software requirements specification. This is an judges the credibility of the system.
evaluation technique in which program execution is simulated • — Field testing is used only for low risk applications. It places
using symbols rather than actual values for input data, and the KBS in actual use and records the results of that use.
program output is expressed as logical or mathematical expressions • — Illegal attribute testing checks rules against constraints
involving these symbols. Issues: assertion testing/violations; for illegal attribute values. This as an effective method for
program execution characteristics; proof of correctness; retest after eliminating bugs during the implementation process of KBS
change. development.
Test certification ensures that reported test results are the actual • — Logical verification is the verification of the expert s
finding of the tests. Test related tools, media, and documentation knowledge for completeness, consistency, etc., as the domain
are certified to ensure maintainability and repeatability of tests. model for the knowledge base system is being built.
This technique is also used to show that the delivered software
• — Meta models compare the knowledge and rules to domain
product is identical to the software product that was subjected to
meta models.
V&V. It is used, particularly in critical software systems, to verify
that the required tests have been executed and that the delivered • — Partition testing selects test cases using partitions of the
software product is identical to the product subjected to software input and output space as criteria and checks if the specification
V&V. Issues: incorrect product version shipped; incorrect test addresses those cases. This as an effective method for
results; reports on test cases that were omitted. eliminating bugs during the requirements, design, and
implementation processes of KBS development.

71
 Software V&V Techniques
• — Rule verification checks for completeness, subsumed/
SYSTEMS ANALYSIS

TECHNIQUE REQ DESIGN CODE UNIT INTEGR SYSTEM INSTALL OPER MAINT
redundant rules, inconsistent rules, dead end rules, circular
Algorithm
rules, unreachable conclusions, etc.
Analysis
• — Statistical validation examines how frequently a KBS uses Analytic
rules or clusters of rules int he knowledge base. If there are Modeling

expectations about the frequency of use expected for some Back-to-Back

rules then statics on rules use can be useful. Testing

Boundary Value
• — Turing tests compare performance of the system against Analysis
that of an expert in blind trials.
Code Reading
• — Weight analysis compares the statistical information Control Flow
associated with a rule to statics known about the domain. Analysis

Coverage
Analysis

Critical
Timing/Flow
Analysis

Database
Analysis

Data Flow
Analysis

Decision
(Truth) Tables

Desk Checking

Error Seeding

Event Tree
Analysis

Finite State
Machines

Functional
Testing

Inspections

Interface
Analysis

Interface
Testing

Mutation
Analysis

72
 1

SYSTEMS ANALYSIS
Table 3-1. Software V&V Techniques (continued)

TECHNI Q RE DESIG COD UNI INTEG SYSTE INSTAL OPE MAIN 2

UE Q N E T R M L R T
3
Regression
Analysis and
4
Testing 5
Requirments Relate the phases of SDLC with the techniques
Parsing
1
Reviews
2
Sensitivity
Ana lysis
3

Simulation
4
Sizing and
5
Timing References:
Analysis
Heuring, Vincent P.
slicing
Computer systems design and architecture
Software
Delhi : Pearson Education Asia, 1997
Fault Tree
Analysis Whitten, Jeffrey L.
Stress Testing
Systems analysis and design methods
Structural
5th ed. New Delhi : Galgotia Publications, 2001
Testing Shelly, Gary B.
Symbolic Systems analysis and design
Execution 3rd ed. New Delhi : Galgotia Publications, 1999
Test Awad, Elias M.
Certification
Systems analysis and design
Walkthroughs
New Delhi : Galgotia Publications, 1997
Hoffer, Jeffrey A.
Review
Modern systems analysis and design
Technique 2nd ed. Delhi : Pearson Education Asia, 2000
Algorithm Analysis
Analytic Modeling Sarkar, A.K.
Back-to-Back Testing Systems analysis, data processing and
Boundary Value Analysis quantitative techniques
Code Reading New Delhi : Galgotia Publications, 1997
Control Flow Analysis Hawryszkiewycz, Igor
Coverage Analysis Introduction to systems analysis & design
Critical Timing/Flow Analysis 4th ed. New Delhi : Prentice Hall of India, 2002
Database Analysis
Data Flow Analysis
Decision (Truth) Tables
Desk Checking
Error Seeding
Event Tree Analysis
Finite State Machines
Functional Testing
Inspections
Interface Analysis
Interface Testing
Mutation Analysis
Performance Testing
Petri-Nets
Proof of Correctness
Prototyping
Questions
Explain about various techniques used in V& V

73
 LESSON 17 :
SYSTEMS ANALYSIS

EVALUATION OF MODELS

Topics covered • Requires less technical development staff

Evaluation of models • Future upgrades provided by the vendor
Objectives • Customizing software packages
Upon completion of this Lesson, you should be • Purchase a basic package that can be customized to suit your
able to: needs
• Evaluate various alternatives when planning systems • Negotiate with software vendor to make enhancements to suit
development and acquisition your needs

• Explain the advantages and disadvantages of in-house • Purchase the package and make your own modifications
development versus purchasing a software package • Other software alternatives
• List the steps in purchasing and evaluating a software package • Outsourcing
• Explain the differences between a request for proposal (RFP) • End-user systems
and a request for quotation (RFQ) • Enterprise computing
• Describe the contents of the system requirements document • Outsourcing
and explain its purpose • Using outside companies to handle part of the workload, on
• Explain the prototyping process and describe a typical short-term or long-term basis
situation where prototyping is used • Contract personnel firms
• Describe computer-aided software engineering (CASE) tools • Systems management or facilities management firms
and explain how they are used during the systems
development life cycle • End-user systems

• Explain how systems flowcharts and state-transition diagrams • Major factor in systems planning and development
are used • Applications can be managed by end-users
Comparison of a chosen model • End-user systems
• Major factor in systems planning and development
Evaluating Software Alternatives (Checking)
• Applications can be managed by end-users
• Make or buy decision
• Software suites offer integrated applications
• In-house software
• Interactive Help features include wizards
• Developed by the company’s IS department
• Security concerns might require read-only files
• Software package
• Information centers (IC) can support end-user systems
• Purchased or leased from software publishers or vendors
• Enterprise computing
• Horizontal application
• Overall information management strategy
• Vertical application
• Key is effective integration of information resources
• Developing software in-house
• Many systems involve client/server architecture
• Reasons for in-house development
• Satisfy unique requirements Selecting a software alternative
• Minimize changes in business procedures and policies • Decision will affect remaining SDLC phases
• Meet constraints of existing systems • Systems analyst’s involvement depends on which alternative is
selected
• Meet constraints of existing technology
Five step process
• Develop internal resources and capabilities
• Buying a software package 1. Evaluate the information system requirements

• Reasons for buying a software package 2. Identify potential software vendors

• Lower costs 3. Evaluate software package alternatives

• Requires less time to implement 4. Make the purchase

• Proven reliability and performance benchmarks 5. Install the software package.

• Implemented by other companies

74
Steps in Evaluating and Purchasing • Hardware Alternatives

SYSTEMS ANALYSIS
Software Packages • Hardware decisions use the same five-step approach as software
Step 1: evaluate the information system decisions
requirements • Evaluate system requirements
• Identify the key features of the system • Identify potential hardware vendors
• Estimate volume and future growth • Evaluate hardware alternatives
• Specify any hardware constraints • Make the purchase
• Prepare a request for proposal or quotation • Install the hardware
Step 2: identify potential software vendors • Other issues to consider
• Next step is to contact potential vendors • Turnkey systems
• An RFP will help vendors to identify solutions • Site preparation
• Various sources of information on suppliers • New workstations
• Retailers • Network cabling
• Computer manufacturers • Raised floors
• Industry trade journals • Conditioned electrical lines
• Systems consultants • Fire extinguishing equipment
Step 3: evaluate software package alternatives • Uninterruptible power supplies (UPSs)
• Object is to compare software packages and select the best • How do you select the best alternative?
alternative • Most companies combine
• Obtain information from many sources • In-house developed software
• Vendor presentations and literature • Software packages
• Object is to compare software packages and select the best • Outsourcing
alternative • End-user systems
• Obtain information from many sources • Object is to develop a list of viable alternatives
• Vendor presentations and literature • All viable alternatives must be evaluated
• Product documentation • Feedback from users is essential
• Trade publications • How do you select the best alternative?
• Companies that perform software testing/evaluation Prototyping
• Object is to compare software packages and select the best
Prototyping Model
alternative
• Obtain information from many sources
• Vendor presentations and literature
• Product documentation
• Trade publications
• Companies that perform software testing/evaluation
• Contact users of the package
• Benchmark test
Step 4: make the purchase
• Software licenses
• Lease agreements
• Maintenance agreements
Step 5: install the software package
• Installation time depends on size and complexity • Rapid prototyping assumes that ‘real’ requirements exist and
by iterating through the tasks they can be determined.
• Before using the package, complete all implementation steps
• Evolutionary prototyping assumes that the project
• Loading, configuring, and testing the software
requirements will be subject to continuous change.
• Training users
• Converting data files to new format

75
 • Evolutionary prototyping a series of fully functioning complete SpiralModel
SYSTEMS ANALYSIS

systems with each successive system the new requirements are

incorporated.
Findings on Prototyping
Prototyping seems appropriate for
1. Data-oriented applications
2. Applications with emphasis on the user interface
3. Applications which are highly interactive
• Boehm (1984), as reported in Vliet (p. 37), had seven groups
develop a system.
• Three groups took the traditional approach (waterfall) in which
the requirements were written prior to subsequent activity.
• Four groups used an evolutionary prototyping strategy. The
findings were:
1 Prototyping took 40% less time and resulted in 45% less code
2 The traditional approach resulted in a more robust product
which was expected to be easier to maintain.
• Alavi (1984), as reported in Vliet (p. 38), reports that users were
more positive about the systems developed using the
prototyping approach. The positive attitude concerns both the
process and the product.
• Users felt more involved and had fewer conflicts with the
designers. Designers had some difficulty with changing
requirements and controlling the development process.
Rad Model
• The RAD (Rapid Application Development) model is a high
speed version of the waterfall model.
• The emphasis is on short development cycle. Short
development cycle is achieved by using component-based
construction.
• Typical use for RAD development is for information systems.
• Business Modeling
• Data Modeling
• Process Modeling
• Application Generation
• Testing and Turnover
Evolutionary Models
Incremental Model

The spiral model attempts to encompass the best features of

both the prototyping and phased lifecycle models. The spiral model
adds a new element, risk analysis.
1. Planning - determination of objectives, alternatives, and
constraints.
2. Risk Analysis - analysis of alternatives and identification/
resolution of risks

76
3. Engineering - Development of the “next-level” product 1. Identify the user’s information and operating requirements.

SYSTEMS ANALYSIS
4. Customer Evaluation - assessment of the results of engineering
Analyze Implement Final
5. Risk Identification Identify user prototype prototype conversion
requirements Input, processing
Project Risks output
difficulties associated with budget, schedule, personnel (staffing Review through Post -
and organization), resources, customer Iterative process
implementation

Technical Risks
These are those problems that arise because the problem is harder Maintenance
than we thought.
Technical uncertainty, technical obsolescence 1. Develop a working prototype that focuses on only the most
Difficulties in interfacing, maintenance, design and implementation important functions, using a basic database.
Business Risks 2. Allow the user to use the prototype, discuss requested changes,
and implement the most important changes.
1. Market risk (the product no one wants)
2. Product line skew (product does not match product line) 3. Repeat the next version of the prototype with further changes
incorporated until the system fully meets user requirements.
3. Can’t sell it because sales doesn’t understand it
• Prototyping and advanced system development techniques have
4. Management risk (change in physical management or focus) been successful in a wide variety of applications.
5. Budget risk (resource commitment) • The benefits include shorter development time, more accurate
Prototyping user requirements, and greater user participation and support.
• Prototyping is an engineering technique used to develop partial, Review
but functional versions of a system or applications. When Evaluating the alternative &Strategies
extended to system design and construction, a prototype can Selecting a software alternative
evolve into the final, implemented system.
Prototyping
• Two ‘flavors’ of prototyping are applicable to systems analysis:
RAD
• Feasibility prototyping is used to test the feasibility of a specific
technology that might be applied to the business problem. Evolutionary model, spiral model, Risk analysis

• Discovery prototyping (sometimes called requirements Questions

prototyping) is used to ‘discover’ the users’ business Explain about prototyping.
requirements by having them react to a ‘quick-and-dirty’ 1
implementation of those requirements.
2
As can be deducted from the discussion on system development,
3
there are two major problems with building information systems:
4
(1)The system development life cycle takes too long and
5
(2)The right system is rarely developed the first time.
Discuss the RAD model.
• Lengthy development frustrates the user. Analysts seem to get
bogged down with tedious methodologies for development 1
systems. T 2
• The reason they often come up with the wrong system is that 3
they expect users to define their information requirements. 4
• It usually turns out that what users ask for is not what they 5
want, and what they want is not what they need.
Differentiate between various models
• An alternative to this “paralysis by analysis” is an advanced
1
technique called prototyping.
2
• Prototyping recognizes problems of cognitive style and uses
advanced computer technology . It advocates building a simple 3
system though trial and error and refining it through and 4
iterative process. 5
• Neumann and Jenkins have conducted the most extensive Explain about risk management
research on prototyping.
1
2
The basic steps are 3

77
 4
SYSTEMS ANALYSIS

5
Tangible Investments Corporation needs a new customer billing
system. As project leader, you decided to create a prototype that
users can evaluate before the final design is implemented. You
plan to use a traditional structured analysis methodology. To
prepare for your meeting with top management tomorrow you
need to review the following topics:
(i) Explain the main purpose of prototyping
(ii) Explain why prototypes might or might not evolve into the
final version of the system.
(iii) list at least three advantages and disadvantages of prototyping.
State the difference between System design and Detailed design.
References:
Heuring, Vincent P.
Computer systems design and architecture
Delhi : Pearson Education Asia, 1997
Whitten, Jeffrey L.
Systems analysis and design methods
5th ed. New Delhi : Galgotia Publications, 2001
Shelly, Gary B.
Systems analysis and design
3rd ed. New Delhi : Galgotia Publications, 1999
Awad, Elias M.
Systems analysis and design
New Delhi : Galgotia Publications, 1997
Hoffer, Jeffrey A.
Modern systems analysis and design
2nd ed. Delhi : Pearson Education Asia, 2000
Sarkar, A.K.
Systems analysis, data processing and
quantitative techniques
New Delhi : Galgotia Publications, 1997
Hawryszkiewycz, Igor
Introduction to systems analysis & design
4th ed. New Delhi : Prentice Hall of India, 2002
Notes

78
 LESSON 18 :

SYSTEMS ANALYSIS
OBJECT BASED METHODS

Topics covered • I assume that the American Bank (AB) has partly decentralized
account management. Every branch office has equipment to
Object oriented system Development
maintain the accounts of its clients. All equipment is networked
• Scope together.
• Objects • Each ATM is associated and connected with the equipment of
• Development Paradigms a particular branch office. Clients can have checking, savings and
• Development Phases line of credit accounts, all conveniently interconnected.
• Purpose • Clients can obtain cash out of any of their accounts. A client
• Models with a personal identification number (PIN) can use an ATM
to transfer funds among attached accounts. I will expand on
• Object in analysis these requirements as necessary. For presentation reasons, I
• Classes often revise descriptions from chapter to chapter. Our examples
• Attributes represent only small fragments of any actual system.
• Summary Objects
Objectives • Ø A frame represents a concept in multiple ways. There is a
Upon completion of this Lesson, you should be able to: descriptive as Ill as a behavioral component. A frame of a
restaurant would have as a descriptive component its
Explain about object. prototypical features — being a business, having a location,
Explain about the development phase with object based methods. employing waiters, and maintaining seating arrangements.
Explain the purpose of object oriented system development • Ø The behavioral component would have scripts. For
Explain about classes and attributes example, a customer script outlines stereotypical events that
involve visiting a restaurant.
Scope
• Ø Objects and frames share the property that they bring
• The development of a software system is usually just a part of descriptive and behavioral features closely together. This shared
finding a solution to a larger problem.
feature, phrased from the programming angle, means that the
• The larger problem may entail the development of an overall storage structures and the procedural components that operate
system involving software, hardware, procedures, and on them are tightly coupled. The responsibilities of frames go
organizations. beyond those of objects. Frames are supposed to support
• I do not address associated issues such as constructing the complex cognitive operations including reasoning, planning,
proper hardware platform and reorganizing institutional natural language understanding and generation. In contrast,
procedures that use the software to improve overall operations. objects for software development are most often used for
• I further limit us to the “middle” phases of OO system realizing better understood operations.
development. I discuss the initial collection of system • On the programming side, the Simula programming language
requirements and scheduling of efforts only to the extent to is another, even older, historical root of objects. Unsurprisingly,
which they impact analysis. Similarly, I discuss situation- Simula was aimed at supporting simulation activities.
dependent implementation matters such as programming in Procedures could be attached to a type (a class in Simula’s
particular languages, porting to different systems, and terminology) to represent the behavior of an instance. Simula
performing release management only with respect to general supported parallelism , in the approximation of coroutines ,
design issues. Also, while I devote considerable attention to allowing for many interacting entities in a simulation.
the process of OO development, I do not often address the • Simula objects share the close coupling of data and procedures.
management of this or any software development process.
• The concurrency in Simula was lost in Smalltalk , Eiffel ,
• The context of any system is simply that part of the “world” Objective-C , C++ , and other popular OO programming
with which it directly interacts. In order to describe the behavior languages. HoIver, parallelism has reentered the OO paradigm
of a target system, I have to describe relevant parts of the via OO analysis methods and distributed designs. Modeling
immediate context forming the boundary of the system. reality with “active” objects requires giving them a large degree
Running Example of autonomy.
• Ø Many examples in this course pack describe parts of the • The notion of whether objects have a parallel connotation or
following system of automated teller machines (ATMs): not is currently a major difference betIen OO analysis and OO
programming. Since I expect OO programming languages to

79
 evolve to support the implementation of distributed, parallel procedural languages. In addition, inheritance provides for an
SYSTEMS ANALYSIS

systems, I expect this difference to decrease. abstraction mechanism that permits factoring out redundancies.
Definitions Applicability
Like “system”, “software”, “analysis”, and “design”, the term • Are the applicability ranges of the object-oriented paradigm
“object” evades simplistic definition. A typical dictionary definition and the structured paradigm different?
reads:
• If so, how are they related?
• Object: a visible or tangible thing of relative stable form; a thing • Is one contained in the other?
that may be apprehended intellectually; a thing to which thought
or action is directed ]. • Can I describe their ranges?
Samplings from the OO literature include:
• As yet there is not enough evidence to claim that the applicability
ranges are different, although OO may have an edge for
• An object has identity, state and behavior (Booch]). distributed systems. Structured analysis thrives on process
• An object is a unit of structural and behavioral modularity that decomposition and data flows.
has properties (Buhr ) • Can I identify a task domain where process decomposition is
Our own working definition will be refined throughout not the right thing to do, but where objects can be easily
this Lesson. I define an object as a conceptual entity recognized? Conversely, can I identify a task where I do not
that: recognize objects, but where process decomposition is natural?
• Is identifiable; Both cases seem unlikely.
• Has features that span a local state space; • Processes and objects go hand in hand when I see them as
emphasizing the dynamic versus the static view of an underlying
• Has operations that can change the status of the system locally, “behaving” substratum.
while also inducing operations in peer objects.
• The two paradigms differ in the sequence in which attention is
Development Paradigms given to the dynamic and static dimensions.
• The structured analysis (SA) paradigm is rooted in third • Dynamics are emphasized in the structured paradigm and statics
generation programming languages including Algol , Fortran , are emphasized in the OO paradigm. As a corollary, top-down
and COBOL . decomposition is a strength for the SA approach, while the
• The procedure and function constructs in these languages grouping of declarative commonalities via inheritance is a
provide for a poIrful abstraction mechanism. Complex behavior strength for the OO approach.
can be composed out of or decomposed into simpler units. Mixing Paradigms
• The block structure of Algol-like languages provides syntactic The software development community has a large investment in
support for arbitrary many layers. Applied to the development structured analysis and structured design (SD).
of systems, this abstraction mechanism gives prominence to
The question has been raised repeatedly whether one can mix and
behavioral characterization. Behavior is repeatedly decomposed
match components from the structured development process with
into subcomponents until plausibly implementable behavioral
components of the OO development process.
units are obtained.
For instance, whether the combination of SA + SD + OOP or SA
• The starting point for process modeling resides in the required + OOD + OOP is a viable route.
behavior of the desired system.
• This makes SA a predominantly top-down method. High Development Methods
level process descriptions are consequently target system specific, Within a given paradigm, one may follow a particular method. A
and thus unlikely to be reusable for even similar systems. method consists of:

• As a result, a description (and a subsequent design and 1. A notation with associated semantics.
implementation) is obtained that is by and large custom fit for 2. A procedure/pseudo-algorithm/recipe for applying the
the task at hand. notation.
• OO software development addresses the disadvantage of 3. A criterion for measuring progress and deciding to terminate.
custom fitting a solution to a problem. Footnote :
• At all levels of the development process, solution components I use the word method, not methodology. The primary meaning of
can be formulated that generalize beyond the local needs and as methodology is “the study of methods” which is the business of
such become candidates for reuse (provided I are able to manage philosophers. The secondary meaning of methodology is method.
these components). Since that is a shorter word I refrain from joining the methodology
• Other aspects of OO development are available to control the crowd. (Similarly, I prefer using technique over technology.)
complexity of a large system. • This Lesson does not introduce yet another new method for
• An object maintains its own state. A history-dependent OO development.
function or procedure can be realized much more cleanly and • I instead attempt to integrate methods representative of the
more independently of its run-time environment than in OO paradigm. Our OO analysis notation is just borroId from

80
 multiple sources. Still I have given it a name, OAN (Our analysis realm differ significantly from objects in the

SYSTEMS ANALYSIS
Analysis Notation), for easy referencing. implementation phase.
• When necessary to distinguish our views from those of others, • An analysis object is independent and autonomous.
I will refer to these simply as “our method” ( OM). • HoIver, an object in an OO programming language usually
Development Phases shares a single thread of control with many or all other objects.
• No author in the area of software development has resisted • Hence, the design phase plays a crucial role in bridging these
denouncing the waterfall model . Everyone agrees that insights different computational object models.
obtained downstream may change decisions made upstream Prototyping
and thus violate a simple sequential development algorithm.
• Prototyping and exploratory programming are common parts
• The notion of a development process in which one can backtrack of OO analysis, design and implementation activities.
at each point to any previous point has led to the fountain
• Prototyping can play a role when aspects of a target system
metaphor (with, I assume, the requirements at the bottom
cannot be described due to lack of insight. Often enough,
and the target system at the top).
people can easily decide what they do not want, but they cannot
• Whether the development process has few feedback loops (the describe beyond some vague indications what is to be produced.
waterfall model) or many (the fountain model) depends on
several factors. Footnote
I avoid the trendy phrase rapid prototyping since no one has yet
• The clarity of the initial requirements is an obvious factor. The advocated slow prototyping.
less I know initially about the desired target system, the more
I have to learn along the way and the more I will change our • Graphical user interfaces are an example. What makes a particular
minds, leading to backtracking. layout on a screen acceptable?
• Another factor might be the integration level of tools that • Must a system keep control during human interaction by
support the development process. offering menu choices or should control be relinquished so
that a user can provide unstructured input?
• A highly integrated development environment encourages
“wild” explorations, leading to more backtracking. On the other • These kinds of question are sometimes hard or impossible to
hand without tool support, I may be forced to think more answer. Prototyping experimental layouts can help. The situation
deeply at each stage before moving on because backtracking resembles that of an architect making a few sketches so that a
may become too costly. customer can formulate preferences.

• It has been said that the object-oriented paradigm is changing • As long as the unknown part of the requirements is only a
the classic distinctions betIen analysis, design and fragment of a system, OO analysis cooperates with prototyping.
implementation. In particular, it is suggested that the differences Exploratory programming is called for when most of the
betIen these phases is decreasing, that the phases blur into each requirements are not Ill understood. Research projects fall into
other. this category. Programming in artificial intelligence is an example.
• People claim that the OO paradigm turns every programmer • Problem solving by analogy is particularly murky behavior.
into a designer, and every designer into an analyst. I are willing Exploratory programming can be a vehicle for validating theories
to go only part way with this view. and/or for obtaining better conjectures.
• There is empirical evidence from projects in which objects • I feel that purely exploratory programming applies to an
identified in the requirements phase carried all the way through essentially different set of tasks than the more tractable
into the implementation . On the other hand, intrinsic (although possibly very large) tasks to which the methods
differences among phases cannot be forgotten. described in this Lesson apply. Formulated negatively, the
methods in this Lesson may not apply when the development
• Analysis aims at clarifying what the task is all about and does task is too simple or when the task is too hard.
not go into any problem solving activity. In contrast, design
and implementation take the task specification as a given and • Elucidating functionality is just one of the motivations for
then work out the details of the solution. prototyping. I have so far used “prototyping” primarily in the
sense of “throwaway prototyping” — aimed at gathering
• The analyst talks to the customer and subsequently (modulo insights — in contrast to “evolutionary prototyping” — aimed
fountain iterations) delivers the result to the designer.
at implementing a system in stages. A prototyping activity may
• The designer “talks”, via the implementor, with hardware that have both aims but they need not coincide ., I shall describe a
will ultimately execute the design. In a similar vein I do not framework for design prototyping that is explicitly evolutionary
want to blur the difference betIen design and implementation. in nature. Similarly, performance constraints may require
• Contemporary OO programming languages have limitations empirical evaluation via implementation-level prototyping.
and idiosyncrasies that do not make them optimal thinking Development Tools
media for many design tasks.
• It is, in our opinion, misleading to suggest that phase
differences disappear in the OO paradigm. Objects in the

81
 • Acceptance of the fountain metaphor as the process model for 3.“On the other hand, I can define the set of all systems that
SYSTEMS ANALYSIS

software development has profound ramifications. Beyond could possibly satisfy user needs as a statement of what I want
toy tasks, tool support and integration of different tools is our system to do without describing how the particular system
essential in enabling backtracking. Of course these tools also ... will behave.”
need to support versioning, allow for traceability , and cater to The suggestion to construct this set of all systems (and apply
team development. These are quite stringent requirements, behavior abstraction?) strikes us as artificial for the present
which are currently not yet satisfied. Various groups are working discussion, although an enumeration of techniques may be
on the standards to achieve tool control and data integration important to facilitate a physical design decision.
.Manipulating objects in all phases of the development process
4. “The next step might be to define the exact behavior of the
should make it easier to construct an integrated development
actual software system to be built ... This step ... defines how the
environment
system behaves ...”
Purpose of object oriented system development This is debatable and depends on the intended meaning of “exact
The analysis phase of object-oriented software development is behavior”. If this refers to the mechanism of the intended system
an activity aimed at clarifying the requirements of an intended then I subscribe to the quotation. HoIver, it could also encompass
software system, with: the removal of ambiguity by elaborating on the description of
Input the customer-ATM interaction. If so, I still reside in what country.
A fuzzy, minimal, possibly inconsistent target specification, user For example, I may want to exemplify that customer authentication
policy and project charter. precedes all transactions, that account selection is to be done for
those customers who own multiple accounts, etc.
Output
Understanding, a complete, consistent description of essential 5. “On the other hand, I can define the external behavior of the
characteristics and behavior. actual product ... as a statement of what the system will do
without defining how it works internally.”
Techniques
I may indeed be more specific by elaborating an interaction sequence
Study, brainstorming, interviewing, documenting.
with: “A client can obtain cash from an ATM by doing the
Models following things: Obtaining proper access to the ATM, selecting
Most attention in the analysis phase is given to an elaboration of one of his or her accounts when more than one owned, selecting
functional requirements. This is performed via the construction the cash dispense option, indicating the desired amount, and
of models describing objects, classes, relations, interactions, etc. obtaining the delivered cash.” I can go further in our example by
Declarative Modeling detailing what it means to obtain proper access to an ATM, by
I quote from Alan Davis stipulating that a bank card has to be inserted, and that a PIN has
to be entered after the system has asked for it.
A Software Requirements Specification is a document containing
a complete description of what the software will do without 6. “The next step might be to define the constituent architectural
describing how it will do it. components of the software system. This step ... defines how
the system works internally ...”
• Subsequently, he argues that this what/how distinction is less
obvious than it seems. Davis continues by arguing that one can define what these
components do without describing how they work internally.
• He suggests that in analogy to the saying “One person’s floor
is another person’s ceiling” I have “One person’s how is another • In spite of such attempts to blur how versus what, I feel that
person’s what”. He gives examples of multiple what/how these labels still provide a good initial demarcation of the
layers that connect all the way from user needs to the code. analysis versus the design phase.
• I will follow a few steps of his reasoning using the single • On the other hand, analysis methods (and not only OO analysis
requirement from our ATM example that clients can obtain methods) do have a how flavor. This is a general consequence of
cash from any of their accounts. any modeling technique. Making a model of an intended system
is a constructive affair.
1. Investigating the desired functionality from the user’s perspective
may be seen as a definition of what the system will do. • A model of the dynamic dimension of the intended system
describes how that system behaves..
The ability of clients to obtain cash is an example of functionality
specified by the user. • The object-oriented paradigm puts another twist on this
discussion. OO analysis models are grounded in object models
2. “The next step might be to define all possible systems ... that
that often retain their general form from analysis (via design)
could satisfy these needs. This step clearly defines how these
into an implementation. As a result, there is an illusion that
needs might be satisfied. ...”
what and how get blurred (or even should be blurred). I disagree
The requirements already exclude a human intermediary. Thus, I with this fuzzification.
can consider different techniques for human-machine interaction,
Ø I should also note that the use of models of any form is
for example screen and keyboard interaction, touch screen
debatable. A model often contains spurious elements that are
interaction, audio and voice recognition. I can also consider different
not strictly demanded to represent the requirements.
authentication techniques such as PIN, iris analysis, handline
analysis. These considerations address the how dimension. Objects in Analysis

82
OO analysis models center on objects. The definition of objects

SYSTEMS ANALYSIS
given in. The bird’s eye view definition is that an object is a
inside object betIen objects
conceptual entity that:
• Is identifiable; attribute relationship
static
• Has features that span a local state space; constraint acquaintanceship
• Has operations that can change the status of the system locally,
while also inducing operations in peer objects. state net and/or interaction and/or
dynamic
Since I are staying away from solution construction in the analysis interface causal connection
phase, the objects alloId in this stage are constrained. The output
of the analysis should make sense to the customer of the system
development activity. Thus I should insist that the objects • The static row includes a disguised version of entity-
correspond with customers’ notions, and add: relationship (ER) modeling . ER modeling was initially
• an object refers to a thing which is identifiable by the users of developed for database design. Entities correspond to objects,
the target system — either a tangible thing or a mental construct. and relations occur betIen objects.1 Entities are described using
Another ramification of avoiding solution construction pertains attributes . Constraints capture limitations among attribute
to the object’s operator descriptions. I will stay away from procedural value combinations.
characterizations in favor of declarative ones. • Acquaintanceships represent the static connections among
Active Objects interacting objects.
• Some OO analysis methods have made the distinction betIen 1Footnote:
active and passive objects. For instance Colbert defines an object The terms “relation” and “relationship” are generally
as active if it “displays independent motive poIr”, while a passive interchangeable. “Relationship” emphasizes the notion as a noun
object “acts only under the motivation of an active object”. phrase.
• I do not ascribe to these distinctions, at least at the analysis • The dynamic row indicates that some form of state machinery
level. Our definition of objects makes them all active, as far as is employed to describe the behavior of a prototypical element
I can tell. This active versus passive distinction seems to be of a class . Multiple versions of causal connections capture the
more relevant for the design phase “social” behavior of objects.
• This notion of objects being active is motivated by the need to • Inheritance impacts all four cells by specifying relationships
faithfully represent the autonomy of the entities in the “world”, among classes. Inheritance allows the construction of compact
the domain of interest. descriptions by factoring out commonalities.
• For example, people, cars, accounts, banks, transactions, etc., Other Model Components
are all behaving in a parallel, semi-independent fashion. By The four models form a core. Additional models are commonly
providing OO analysts with objects that have at least one thread added to give summary views and/or to highlight a particular
of control, they have the means to stay close to a natural perspective. The core models are usually represented in graphic
representation of the world. This should facilitate explanations notations
of the analysis output to a customer. HoIver, a price must be • For instance, a summary model in the static realm may remove
paid for this. all attributes and relationship interconnections in a class graph
• Objects in the programming realm deviate from this to highlight inheritance structures. Alternatively, I may want to
computational model. They may share a single thread of control show everything associated with a certain class C, for example,
in a module. Consequently, bridging this gap is a major its attributes, relationships in which C plays a role, and
responsibility of the design phase. inheritance links in which C plays a role.
Four-Component View Process
• A representation of a system is based on a core vocabulary. The • Several factors prevent analysis from being performed according
foundation of this vocabulary includes both static and dynamic to a fixed regime. The input to the analysis phase varies not
dimensions. only in completeness but also in precision.
• Each of these dimensions complements the other. Something • After factoring out these sources of variation, I may still wonder
becomes significant as a result of how it behaves in interaction whether there is an underlying “algorithm” for the analysis
with other things, while it is distinguished from those other process. Investigation of current OO analysis methods reveals
things by more or less static features. that:
• This distinction between static and dynamic dimensions is one • The creators of a method usually express only a Iak preferences
of the axes that I use to distinguish the models used in analysis. for the sequence in which models are developed.
Our other main distinction refers to whether a model concentrates • There is as yet no consensus about the process.
on a single object or whether interobject connections are addressed. • There appear to be two clusters of approaches: (1) Early
The composition of these two axes give us the following matrix: characterization of the static dimension by developing a

83
 vocabulary in terms of classes, relations, etc. (2) Early • Real-life entities are often described with words that indicate
SYSTEMS ANALYSIS

characterization of the behavioral dimension, the system- stable features. Most physical objects have features such as shape,
context interactions. Light, color, and type of material. People have features including
date of birth, parents, name, and eye color. A feature may be
Classes
seen as a binary relation between a class and a certain domain.
• Sometimes I need to talk about a particular instance in our Eye color for example, may be seen as a binary relation between
system model. For example, a bank may maintain some key the class of Eyes and an enumerated domain {brown, blue,
“system” accounts. I may want to describe a few special yellow, green, red}. A domain can be a class as Ill, for example,
employees, e.g., the executive officers. Usually, hoIver, collections in the case of the features parents, spouse, accountOwnedBy,
of objects, so-called classes 1 are described. etc.
Footnote 1: • The applicability of certain features (i.e., the features themselves,
The notions of “type” and “class” are sometimes distinguished not just their values) may change over time. For example, frogs
in the implementation realm. A type is the abstract characterization and butterflies go through some drastic changes in their lifetime.
of a particular “family” of objects, while a class is then the actual I avoid this kind of flexibility. Thus, a class is characterized by
realization in a particular programming language of that type. I its set of defining features, or attributes. This collection of
will uniformly use the term “class”.. features does not change. (I later present tricks for getting around
• A class stands for a family of objects that have something in this limitation.)
common. A class is not to be equated with a set of objects, • The notion of a (binary) relation crept into the previous
although at any moment I can consider the set of instances discussion. The reader may wonder how I can discuss them
that belong to the class. A class may be seen as what all these here since I have relegated them to another model in our four-
sets have in common. In technical terminology, a class stands component view. I make a distinction between attribute (binary)
for the intension of a particular characterization of entities, relationships that represent intrinsic, definitional properties of
while the set of objects that conform to such a characterization an object versus relationships that describe contingent,
in a certain period is known as the extension incidental connections between objects. Because I, as analysts,
• Notationally, a rectangle surrounds the name of a class. For are in control, I can prescribe for an object what is definitional
example, the class Account is depicted as: and what is incidental. For example, in a particular system I
may agree that for the class Person a social-security-number is a
defining attribute while a parent feature is seen as an incidental
relationship. In another system, the reverse choices could be
made.
• An object is an instance of at least one and at most one class. I illustrate the notation for attributes with a class Account that has:
Certain methods allow an object to change, during its lifetime, • Attribute accountNumber of value domain AccountNumber
the class of which it is an instance. This freedom increases the and
expressive poIr of the analysis method. But since most OO
• Attribute currency of value domain Currency.
software development methods and languages do not support
this feature, and since the effects of change may be described by A graphical notation for these attribute names and attribute values
other means, I refrain from this practice. is:
• Individual objects are primarily characterized by an indication
of which class they belong. For example:

• The arrow between the instance and its class is called the ISA
relationship. This instance characterization is insufficient. At
this stage, I do not have available the means, beyond naming,
to distinguish multiple instances of the class Account. This representation indicates that AccountNumber is a “data value”
• In general, I avoid using names to describe individual objects, domain and that Currency is a class. It is debatable whether I
because usually objects do not have natural names. Just consider should make such a distinction betIen values and objects. For
the examples given earlier — a bank transaction, a newspaper instance, one can take the stance that integers, strings, and 32-bit
story, a phone call, a rental car contract, a utility bill, and an reals are all objects as Ill.. I use the convention that unboxed value
airline reservation. Instead, descriptions are used that somehow domains do not represent classes. Consequently, if I change our
denote unique entities. Attributes of objects will do the mind and represent the currency attribute as a data value, I would
descriptive job. unbox it.
Attributes Attributes of Instances

84
• Attributes can be employed to describe an instance of a class

SYSTEMS ANALYSIS
Development]. OO texts that cover the full life cycle include
by indicating how it “scores” with respect to the attributes. In Booch’s Object Oriented Design with Applications and
the following example, I depict a particular instance of the Rumbaugh et al’s Object Oriented Modeling and Design .
class Account:
• Yearly proceedings are available from the principal OO
conferences, OOPSLA (held in the Istern hemisphere) and
ECOOP (Europe). Both originally focused on programming
and programming languages but have more recently broadened
their attention to the full life cycle.
Questions
Analysis aims at giving an unambiguous description of what a
target system is supposed to do. Enumerate the differences, if
any, of an analysis method for characterizing software systems
versus an analysis method for characterizing hospital systems, or
any other nonsoftware system with which you are familiar.
1
Note that attribute names have been repeated in the instance. An 2
alternative approach would use graphic notation to link up the 3
attributes of the instance with the attributes in the class, as in: 4
5
In general, prototyping may be seen as “disciplined” hacking that
explores a narrow Ill defined problem. Would the throwaway
connotation of a produced artifact in this characterization change
as the result of an overall OO approach?
1
2
3
4

Discuss whether analysis, should be performed for the following

Summary tasks:
• Software systems are often components of general systems. 1. The planning for your next vacation.
This Lesson discusses only object-oriented approaches to
developing software systems. The roots of the OO paradigm 2. The repair of faulty software.
include AI frames and programming languages including 3. The acquisition of your next car.
Simula. 4. The remodeling of your kitchen.
• The structured paradigm focuses on decomposing behaviors. 5. The decision to get married.
The OO paradigm focuses on objects, classes, and inheritance. 6. The reimplementation of an airline reservation system
The two paradigms do not mix Ill. While the OO paradigm to exploit five supercomputers.
tightly integrates the development phases of analysis, design
and implementation, intrinsic differences betIen these phases 7. A comparative study of OO analysis methods.
should not be blurred. OO methods are compatible with
prototyping efforts, especially those constructed in order to 1
elucidate otherwise unknown requirement fragments. 2
• Purpose of object oriented system development 3
• Models 4
• Object in analysis 5
• Classes Analysis is a popular notion. Mathematics, philosophy, psychiatry,
• Attributes and chemistry all have a claim on this concept. Is there any
Further Reading
• Standard non-OO texts include Ward and Mellor’s Structured
Development for Real-Time Systems and Jackson’s Systems

85
 commonality between these notions and the notion of analysis 11 NIST. Reference Model for Frameworks of Software
SYSTEMS ANALYSIS

developed in this lesson? Engineering Environments. National Institute of Standards

1 and Technology, December 1991.
2 12 J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W.
Lorensen. Object-Oriented Modeling and Design. Prentice Hall,
3
1991.
4
13 P.T. Ward. How to integrate object orientation with structured
5 analysis and design. IEEE Software, March 1989.
Do you expect the following items to be addressed during OO 14 P.T. Ward and S. Mellor. Structured Development for Real-
analysis? Time Systems. Prentice Hall, 1985.
8. Maintainability. 15 E. Yourdon. Modern Structured Analysis. Yourdon Press,
9. Quality. 1989.
10. The development costs of the target system. Notes
11. The execution costs of the target system.
12. The programming language(s) to be used.
13. The reusability of existing system components.
14. The architecture of the implementation.
15. The relevance of existing frameworks.
1
2
3
4
5
6

References
1 G. Booch. Object Oriented Design with Applications.
Benjamin/Cummings, 1990.
2 R. Buhr. Machine charts for visual prototyping in system
design. Technical Report 88-2, Carlton University, August 1988.
3 O. Dahl and K. Nygaard. Simula: An algol-based simulation
language. Communications of the ACM, 9, 1966.
4 A.M. Davis. Software Requirements, Analysis and Specification.
Prentice-Hall, 1990.
5 D. de Champeaux, A. Anderson, M. Dalla Gasperina, E.
Feldhousen, F. Fulton, M. Glei, C. Groh, D. Houston, D.
Lerman, C. Monroe, R. Raj, and D. Shultheis. Case study of
object-oriented software development. In OOPSLA ‘92. ACM,
1992.
6 D. de Champeaux and P. Faure. A comparative study of object-
oriented analysis methods. Journal of Object-Oriented
Programming, March/April 1992.
7 Random House. The Random House College Dictionary.
Random House, 1975.
8 W.S. Humphrey. Managing the Software Process. Addison-
Isley, 1990.
9 M. Jackson. Systems Development. Prentice Hall, 1982.
10 M. Minsky. A framework for representing knowledge. In P.
Winston, editor, The Psychology of Computer Vision.
McGraw-Hill, 1975.

86
 LESSON 19 :

SYSTEMS ANALYSIS
OBJECT BASED METHODS

Topics covered
Object oriented system Development
• Attribute features
• Optional attributes
• Static and Dynamic
Object Relationships
• Relationships
• Collections
• Identifying Relationships Probability
Class Relationships We may want to associate with an attribute our knowledge about
the distribution of the values in the value domain. (A default
• Property Inheritance
value need not correspond with the value that has the highest
• Subclasses probability.) As an example, consider the class Human with the
• Multiple Inheritance attribute age. The probability distribution corresponds here with a
• Inheritance of Relations demographic profile. A designer may want to exploit this
information.
Objectives
We avoid introducing special notation. One option is to list (value,
Upon completion of this Lesson, you should be able to: probability) pairs. For numerical domains, a probability
Explain about the attributes. distribution function may be specified. Any other mathematical
With a live example about various attribute features notation may be invoked as needed.
Explain the various notation used for identifying object Multiplicity
relationships A multiplicity feature associates more than one value to an attribute.
Explain the various notation used for identifying class We use the notation [N:M], where 0 <= N <= M. N indicates the
relationships minimum number of values and M indicates the maximum
number. A few conventions simplify the notation:
Attribute Features
• We usually abbreviate [N:N] as [N] to represent a multiplicity
We have attached attributes to objects. The next step is to give, in
of exactly N.
a sense, attributes to attributes. We will call them features to avoid
too much confusion. • We usually omit a multiplicity indicator when the multiplicity
is [1].
Two features of attributes have been encountered already, the
attribute’s relation name, which is sometimes called the role name, For example, the class Hand might contain the attribute finger with
and the value domain . Here we expand the features that can be a value domain of class Finger and a multiplicity constraint of
associated with an attribute. We should stress that using these [0:6]. This requires an explanation indeed. A hand remains a hand
features is optional and can be ignored in first rounds or even all even when all the fingers have been amputated. That explains the
together. minimum 0. The 6 has been chosen because Anne Boleyn had a
hand with six fingers.
Defaults
This multiplicity notation is sometimes not expressive enough.
Sometimes it is useful to indicate a default initial value for an
Consider a family of vehicles where the number of wheels per
attribute. A generous bank may, for example, give a surprised
vehicle is 3, 4, 6 or 10. In general, a multiplicity indicator can be any
new customer an account with an initial balance of $10. Since
arbitrarily complex description of a set of natural numbers. Given
sheep are usually white, their color attribute can be given this
this state of affairs, we omit additional notation beyond observing
default value.
that predicate calculus provides formal precision and unbounded
A revised Account class includes a notation for indicating a default expressiveness.
value of an attribute:
Optional Attributes
Using a zero lower bound in the multiplicity feature of an attribute
indicates that possession of the attribute is “optional”. This allows
instances that effectively do not have that attribute. This is a way

87
 around the limitation of freezing a collection of attributes for a
SYSTEMS ANALYSIS
Several other senses of restriction are common enough to group
class. under broad categories, allowing simpler qualification:
For example, a bank has branches, each having departments. We • We may require that an attribute value for each instance of the
assume that departments consist of a department head and class to be fix• ed (immutable) when the object is created and
subdepartments. This creates a recursive structure that bottoms initialized. This value may differ across different instances, but
out by making subdepartments optional. Thus, a nonmanagerial it may not vary across time for any instance. Fixed attributes
employee is a department head that does not supervise differentiate instances from peer objects that are members of
subdepartments. For illustration, we restrict the branching ratio the same class.
of departments to six: • We may require that the value of an attribute be common to all
instances of a class, even without knowing what that value
should be. The common value may also change across time.
For example, all instances of class Account might need to record
transactions using a common LogFile. The exact file may change
over time.
• The category of unique attributes is the extreme opposite of
common. A unique attribute is one whose value differs for
each instance of a class. For example, the value of attribute
accntId should be unique to each instance of class Account.
Qualifiers including fixed, common, and unique may be annotated
in any convenient fashion. For example, the following class Client
has a social security number attribute that is both unique for each
instance and remains fixed over its lifetime:
Statics and Dynamics
• Static considerations may be insufficient to differentiate classes.
We can still have variations based on behavioral differences.
• For example, one kind of calculator may support only addition
and subtraction, while another one with the same attribute
structure (at an appropriate abstraction level) also supports
multiplication and division. However, we are emphasizing for
now class identification, and especially characterization, via the
static features of the objects that constitute a class.
• This may sound counterintuitive. Some entities are easier to
describe via their dynamic (potential) dimension. For instance,
a pilot is a person that can fly a plane. Even so, remember that
the static and dynamic dimensions of an entity are
complementary notions that can add and build onto the other.
Change is perceived against a background of constancy.
• Dually, constancy is merely the inability to perceive a slow rate
of change. In addition, our treatment of the static dimension
Multiplicity default and probability. of objects before addressing the dynamic dimension should
Multiplicity indications may be dressed up with more knowledge not be seen as an imperative for the OO analysis process.
if this information is beneficial for a design and/or
For example, an automated teller machine can be understood as a
implementation. For example, a reasonable default multiplicity
device that can support a range of financial transactions. (The
for the number of wheels of a car is four. A probability distribution
term machine in its name already emphasizes the dynamic aspect.)
for the multiplicity feature denoting the number of children per
However, it may still be described in terms of its static features.
parent might be obtained through an empirical sampling.
The following first impression for class ATM (to be revised
Qualifiers extensively in coming chapters) lists attributes indicating functional
The range of an attribute value can be restricted in any of several components of an ATM machine:
senses. We always fix an attribute to a particular domain. The
values of an attribute of an object must remain within the indicated
domain throughout the lifetime of the object. The domain for an
attribute listed in a class may be narrowed down to only one
possible value. For example, the class Albino has for its color
attribute the value white.

88
 TimeInterval

SYSTEMS ANALYSIS
describes how often a transfer will be attempted. Possible values
can range from minutes (or perhaps even shorter) to months (or
even longer).
AmountExpression
Is any expression describing the amount to be transferred. This
might just be a fixed sum. Alternatively, we can envision that the
AB bank allows for amounts that are functions of certain
parameters. For example, to maintain a certain balance in the from
account, it might take the form:
(the balance of the from account) — (a fixed sum).
TransferBoolean
Describes a truth-valued function to be used to block the transfer
when certain conditions are not met. For example, a value calculated
by the function outlined in the previous attribute should not be
too small, or one may want to constrain the maximum amount
on the target account.
Relationships
A relationship may be seen as a named family of typed tuples.
They are typed in the sense that the nth element in a tuple is an
instance from a specific domain or class.
The signature of a relationship is just a listing of these types. For
example, the signature of the Ownership relationship is ( Client,
Account) since it has a family of 2-tuples where the first domain is
• For a different kind of example, the following TransferDaemon the class of Clients and the second domain is the class of Accounts.
class represents the static dimension of procedures that are run
Following the tradition of the data modeling community and
periodically to transfer an amount provided a condition is met.
other OOA methods, a diamond is used to depict a relationship
For instance, such a procedure may automatically transfer money
in our graphical notation. A diamond is connected via edges to
to a savings account when a checking account has too much
the domains of the tuple elements. Obviously, we will always
money.
have at least two edges.
For example, to indicate that class Client and class Account are
connected by the relationship Own:

In the same way that we may want to refer to particular instances

of classes in a particular target system, we may want to express
that certain instances actually belong to a relationship.
For example, we may want to express that a particular client owns
a particular account. An instance of a relation is represented with a
diamond containing a filled circle:

For now, we sketch out characterizations of the attributes that

help to control dynamics:

89
 Transitive
SYSTEMS ANALYSIS
Graphical notation can sometimes cause an ambiguity when a
relationship connects identical domains. For example, the Supervise For all x, y, z, if R(x, y) and R(y, z) hold, then R(x, z) holds. For
relationship between two Persons is described in textual example, the relationship AncestorOf .
representations by ordering the arguments, as in: Constraints
Supervise(Person, Person).
We can agree that the first argument represents the supervisor and In the same way that constraints provide supplementary
the second argument the “supervisee” (person that is being information about simple attributes, additional constraints may
supervised). To avoid ambiguity in diagrams we can add role express restrictions on the allowed instances of a relation.
names, as in (letting Spv stand for Supervise): For example, we can rephrase the fact that instances of class Person
have the attribute spouse as a binary relationship Spouse between
Cardinality
Person and Person (assuming the spouse attribute has been eliminated
Consider a domain in which an account cannot have more than
from class Person):
one owner. This means that a particular instance of Account can
occur not more than once in an Own tuple.
Cardinalities (the relational versions of multiplicities) may be used
to indicate such properties. Here, we can add the cardinality notation
[0:1] to the diagram: The [0:1] cardinality captures a monogamy restriction.

Alternatively, we could express that each client can own one to

multiple accounts and each account can have one to multiple The arity, or number of elements in the signature is another way
owners: of classifying relationships. Binary relations (such as Own and
Supervise) have tuples of length two. Ternary relations have tuples
of length three. Examples include:
InBetween,
a relationship among three Locations. For example, Chicago is in
between San Francisco and New York.
As another example, we may want to express that a peculiar group
TravelTimeBetween,
of *Client*s have at least three but at most five accounts with:
a relationship among two Locations and a TimeInterval. For example,
the travel time between New York and San Francisco is six hours.
ParentsOf,
a relationship among three Persons. For example, John and Mary
are the parents of Susanna.
The date that a client becomes a customer may be described as a ResideInSince,
relationship. Each client must have exactly one start date. A client a relationship among a Person, a Location, and a Date. For example,
may have started on the same date as another client. John resides in Stockholm since December.
Letting CsSn stand for CustomerSince(Client, Date):
BorrowedFrom,
a relationship among two Persons and a Thing. For example, John
borrowed a lawn mower from Mary. (“ Thing” here is perhaps too
broad. Can someone borrow the Sun?)
We can have relations with tuple lengths larger than three as well.
Qualifiers Graphically, more than two edges are obviously required for
Relationships may be classified according to their technical relationships with arity greater than two. For example, we may
properties. construe Transfer as a relation among a pair of accounts, an
amount, and a date (letting Trans stand for Transfer(fromAccount,
Reflexive toAccount, amount, date)):
For all x, R(x, x) holds; i.e., every element is necessarily related to
itself. For example, the relationship SameAgeAs.
Symmetric
For all x and y, R(x, y) implies R(y, x); i.e., the relationship is
“bidirectional”. For example, the relationship SiblingOf .

90
 When a multivalued attribute would have more specific multiplicity

SYSTEMS ANALYSIS
bounds, as in [3:7], the corresponding set notation may be
annotated accordingly in any agreed on manner.
Other Collections
If necessary, the analyst is invited to employ other collection
notations and the usual operations associated with them:
Sequences.
For example, the class String may be described as SEQ(Char).
Other examples include the ATM attribute logOfSessions, which
has as value domain SEQ(Session).
Arrays.
Sets
For example, the class 2D-4-5-grid may be described as
Sets are the most well-known and useful kinds of collections
ARRAY[3:4](Point). The days of a year can be represented as an
Once we have sets, we can open the floodgates and adjoin to our
array, for instance, to record a savings account interest rate for that
representational apparatus the notations that are available in set
time period: ARRAY[365](Day).
theory. These include:
for intersection, Bags.
for summation, For example, the collection of accounts involved in receiving funds
for subtraction, in a certain time period may be described as a BAG(Account). Since
for the subset relationship, an account may receive funds more than once we can have
for the superset relationship. repetitions.
We denote sets by expressing their domains as “arguments”. For Generic Classes
example, a set of branches is denoted as SET(Branch). Observe Additional collections and related constructs may be defined as
that we now have two ways to describe multivalued attributes; generic classes. These classes capture the commonalities of a broad
sets and multiplicity features. The following two depictions may range of other classes. Inheritance is an excellent mechanism to
be treated as equivalent: exploit abstract classes and create more specific versions. Generic
classes instead use the style of procedure or function variables to
express genericity.
Our notations for sets and other collections are special cases of
that for generic classes. By convention we use upper case names
for generic classes. For example, the following generic classQUEUE
has instances with elements of type X.

Multiplicity and set notations may be combined, for example,

when we introduce multivalued attributes where each individual
value is a set. In the following example the class School treats its
faculty as an undifferentiated set of employees and treats the student When the class Job happens to be around, we can introduce the
body as a family of sets of students: class QUEUE(Job).
Identifying Relationships
Relationships versus Classes
Analysts often have some freedom in whether to use classes versus
relationships to represent static features of a domain. The notion
of Transfer is an example.
The main consideration is that classes and relationships describe
different kinds of instances.. Instances of relationships do not
necessarily share these properties. A relation instance need not be
ascribed an independent identity. It may be fully characterized
merely by listing the elements of the tuple. Relation instances
need not have any intrinsic properties outside of those of the

91
 tuple. And they cannot change state or communicate with other dependency. The cardinality [0:1] reflects a partial function that
SYSTEMS ANALYSIS

objects at all. need not “hit” every element in the domain.

Analysts may choose the approach that appears most appropriate For example, the following diagram indicates that every person
to the task at hand. When aspects of a purported relation appear has precisely one mother, and every mother has at least one child.
class-like, or vice-versa, descriptions may change accordingly. Letting Mo stand for the MotherOf relation:
Intensional Versus Extensional Definition
The ways in which classes and relationships are defined also differ.
Classes list the central defining characteristics of identifiable objects
in a domain..
Like sets, relationships are normally described in a partially extensional Functions are among the most common kinds of relationships.
fashion. Most relationships describe tuples corresponding to the In functional relationships, at least one direction of the relation
state of affairs in the “world” and are determined by circumstances. associates a single element of one domain to those in the other. It
Thus, they have been obtained by some form of observation. is convenient and often reasonable to treat them as attributes in
The Ownership relation is an example. In this case, the family of functional direction if this appears central to the definition of the
tuples is simply a set, and in practice is a “small” finite set. For all class. In this sense (as exploited in design — see Chapter 16) all
practical purposes, relational modeling deals only with extensionally attributes are functions. For example, to indicate that each person
defined relations in which the family of tuples is small and can must have a mother:
conceivably be handled by storage media that will satisfy resource
requirements constraints.
While a useful guide, this distinction does not intrinsically separate
classes from relationships. Intensionally defined relationships may
provide a definition (e.g., a predicate) that characterizes which tuples
belong to the relation and which do not. Grandparenthood
defined as being the parent of a parent is an example. Another
example from the realm of math is the successor relationship
relating every natural number N with its successor N+1. Here, the
family of tuples is still a set, although not small and in fact of
infinite size. Relationships where the family of tuples is not a set
any longer are possible as well. Similarly, consider the MaintainedBy(Account, Branch) relation saying
Relationships versus Attributes that an account must be maintained by one branch, and a branch
As a result of the similarity between attributes and binary maintains at least one, possibly more accounts. This could be
relationships, an analyst must take care not to prematurely absorb described as a functional relationship (letting MnBy stand for
binary relationships into a class definition. MaintainedBy):
The main conceptual issue is whether a feature is definitionally
intrinsic to an object. One question to ask is whether every instance
of a class is necessarily related to a member of the other
domain. In this case it is normally a genuine attribute; in other
cases it is better represented as a relationship. On the other hand, Alternatively, the Account class could have an attribute maintainer
one should be pragmatic as well. For example, in spite of the with domain Branch. The “other” direction in a functional
existence of Gliders, it makes sense to see Engine as a [0:M] relationship may also be described as an attribute when this
(multivalued) attribute of Airplane. Consequently, Gliders may be contributes to the definitional characterization of a class. However,
described as effectively lacking the attribute Engine by giving them in this case, the attribute normally has a SET domain. For example,
the multiplicity feature [0]. each Branch could have an attribute maintainedAccts with domain
SET(Account).
A related question is whether one object is conceptually “in
control” of the values assumed in the other domain. More generally, any binary relationship may be described with a
pair of possibly set-valued functional attributes (one per domain)
Binary acquaintance relations serve this need. However, when one when it is meaningful to do so. However, the “equal partnership”
object must be able to determine its partner(s), this information implicit in the idea of describing pairs of functional attributes is
may be listed in attribute form. better captured as a relationship proper.
Functions The extreme case of a functional relationship is a one-to-one function,
Functional relationships (or just “functions”) represent the meeting where the cardinalities of both domains are [1:1]. In this case, each
point of these considerations. A tuple component of a relation element of one domain is “matched’ with a unique element of
depends functionally on the other components if its value is the other. (If one of the domains has cardinality [0:1], this instead
uniquely determined by the other components. The cardinalities represents a partial one-to-one function). For example, the
[0:1] and [1:1] for any of the domains indicate a functional “relationship” between an Account and its accountNumber is one-
to-one, as would be a relationship between Departments and

92
Managers saying that each department has a unique manager and OO programming, property inheritance. Properties consist of

SYSTEMS ANALYSIS
each manager manages a single department. These relationships declarative class features and associated constraints. (We consider
are most naturally captured as attributes. When doing so, attribute only explicit features and constraints ruling out features, values,
multiplicity notation may be extended as [1:1]-[1:1], or abbreviated etc.)
as unique to indicate this property. Property inheritance is a relation between a subclass and a
We summarize these classifications by showing how some Superclass. Class Q is a subclass of superclass P when every attribute,
standard function categories are described as attributes: constraint, and transition network of P is also an attribute,
One-to-One constraint and transition network of Q and wherever P participates
A function is one-to-one if each distinct argument maps to a in a relationship Q does as well. Additionally, the subclass Q is
distinct result. This corresponds to unique. “stronger” than P. Instances ofQ have all the definitional properties
defined in class P, but are also constrained by at least one additional
Pure
definitional feature. Thus, the family of instances of Q i s a
A function is pure if multiple applications with the same argument
subfamily of the instances of P. In more detail:
always give the same result. This corresponds to per-object fixed.
Attributes
Singular
If all instances of P possess attribute a, then so do all instances of Q. All
A function is singular (or fully many-to-one) if it always gives the
features and constraints applying to a in P also apply to a in Q.
same answer, regardless of argument. This corresponds to per-
class common (i.e., constraining all instances to possess the same Relationships
value). If there is a relationship between P and a class R, then there is a
relationship between Q and R as well. If this relationship is
Partial
functional and all of P is in the domain of the relationship, then
A function is total if it is defined for each possible argument.
for every instance q in Q there is an associated instance r in R.
Otherwise it is partial. Partial functions are denoted with [0:1]
multiplicities. Transitions
If the behavior of P is described by a transition network with
Multivalued
state S and transition T, then Q has state S and transition T as
A multivalued (or one-to-many) function corresponds to either
well.
[1:N] multiplicities or SET or other collection domains.
Inheritance is a core concept of the object-oriented paradigm, Interactions:
emerging in two basic contexts, abstraction and reuse. If instances of P may interact with, accept event input data
describing, and/or generate output event data describing instances
Abstraction of a class R, then so may instances of Q.
First, one may recognize that two constructs A and B have
All classes may be considered to be subclasses of a common base.
something in common. To avoid having to deal twice with this
We consider class Any to describe any object. It thus serves as the
shared aspect, one may create a construct C that captures the
root of any inheritance hierarchy. The class defines no attributes or
commonality, remove this commonality from A and B and restore
transitions. Any is an example of a class that is not directly
it in A and B by letting them inherit from C. Consider Apples,
(deterministically) instantiable. No object is a member only of
Pears, and Oranges. It may pay off to introduce the notion ofFruit
class Any, but instead of one of its subclasses (or their subclasses,
and factor out in Fruit the commonalities of apples, pears, and
or ...). Non-instantiable classes are common results of superclass
oranges. Similarly, it may pay off to introduce the class Account to
abstraction.
capture the commonalities in CheckingAccount, SavingsAccount,
BusinessAccount, etc. Hierarchical abstraction of common features Subclasses
contributes to the overall human understanding of the objects One can simply declare that a class is a subclass of another, for
and classes comprising a system. example that class CheckingAccount is a subclass of the class Account.
It is, of course, much more defensible to provide a reasoned
Reuse and Specialization
justification of why the class is a subclass of the other. In general,
A second reason for using inheritance can arise during model
inheritance is justifiable when the subclass description imposes
construction. During the construction of, say, class D, one may
additional features and/or constraints without invalidating any
recognize that a desired feature of D has been developed already
properties described in the superclass.
and is available in, say, class E. Instead of reconstructing this
feature, one establishes a directed inheritance link between D and We will give a set of more precise justifications, along with
E. The more specialized class D reuses all features of E. In the examples. In this section we focus on the definition of a subclass
programming realm, this is sometimes known as “programming Q with a single superclass P. We will later broaden this to include
by differences”. multiple inheritance

Property Inheritance Additional Attribute

The notions subject to inheritance in an analysis, a design, and an Q adds an attribute to those that it has obtained from P. As an
implementation are respectively properties, computation, and example, a Room has the subclass Bathroom with the attribute bath
code. Since classes are not described through code in the analysis of domain Bathtub:
phase, we have a more abstract notion of inheritance than seen in

93
SYSTEMS ANALYSIS
· Let P be a particular kind of car. Q has exactly the same features,
however it has the additional behavior that it can be operated
in four-wheel drive.
Additional Constraint
Subclass Q may differ from P because Q carries an additional
constraint on the attributes ofP. For example, let P be the class of
Customers, and Q the class of GoldenCustomers ( GC) with the
feature that they have been customers for at least ten years.

As illustrated here, our graphical notation of the superclass-subclass

inheritance relation is an arc directed to the superclass.
For another example, consider a bank to be a family of branches Narrowed Multiplicity
where the headquarters is considered to be a special branch. This A special case of additional constraint is a narrowed multiplicity
suggests defining the class Headquarters as a subclass ofBranch. We feature. For example, let P be the class of Airplanes with the
can distinguish these two classes by giving Headquarters an multivalued attribute engine having multiplicity feature [0:M] stating
additional attribute president with domain Employee: that a plane has zero or more engines. Now let Q be the class of
gliders where we narrow down the multiplicity feature of engine to
[0]:

As another example, consider the class of bikes that can have as

instances unicycles, bicycles, and tricycles
A variation on this justification is for Q to require that additional
elements be contained in a SET or other collection attribute defined
for P, assuming that P does not possess any constraints (e.g.,
collection size bounds) that preclude this.
Additional Transition
A subclass Q inherits everything in parent class P, including its
transition network. In the simplest case, the transition network
for Q is the same as the transition network for P. This provides
transitions “for free” in the subclass. However, it is possible that
the transition network of Q contains additions to P’s transition
network.
Narrowed Domain
A subclass may contain additional attributes that in turn generate Assume that P has an attribute with the class PR as a value domain.
new states and transitions. For example, a savings account may Subclass Q differs from P because it has for this attribute the value
have an attribute that describes the interest rate. As a result, the domain QR instead of the value domain PR, where QR is a
behavioral description may have an additional transition that subclass of PR. Thus, we see that the subclass notion has a recursive
accounts for interest debits. Other examples include: component.
· Let P be a particular kind of editor. Q does the same and As an example, let P be the class Person having the attribute
supports in addition an undo operation. countryOfBirth where the value domain PR is equal to Country. Let
Q be the class European. We choose EuropeanCountry as the
corresponding value domain QR. Indeed, with this choice QR is a
subclass of PR and thus Q is a subclass of P:

94
 avoided by demanding that every defined class be illustrated with

SYSTEMS ANALYSIS
at least one prototypical instance.
Attribute Ambiguity
In multiple inheritance, equal attributes from multiple sources are
projected into a single occurrence. This is one reason that different
concepts and roles should not be associated with the same name
in OO models. For example, consider the class of employees who
are also clients:

Fixed Domain
Subclass attributes may be narrowed down to fixed values. To
extend the previous case, instead of being restricted to a subclass
of PR, Q’s attribute may be fixed to a certain value of PR, say, qr.
Elaborating the previous example, Canadian becomes a subclass
of Person by fixing the value domain of countryOfBirth to the
instance Canada of the class Country.

Multiple inheritance may lead to ambiguity when a subclass inherits

a feature that has two or more different interpretations in the
Similarly, we can obtain the subclass Albino out of Mammal by
different superclasses. For example, suppose that both the class
fixing a color attribute in Mammal to white:
Employee and the class Client introduce an attribute address. Assume
that the value domain for address in Employee is, say, LongAddress
(supporting an extended zip code), while the value domain for
address in Client is ShortAddress. What is the domain for address in
EmployeeClient?
It is the responsibility of the analyst (and/or a support tool) to
avoid or repair these ambiguities. Here, one solution is to redefine
the class Client by making it a subclass of the class ClientNA,
which is like the original Client class but does not have the address
attribute. The ShortAddress attribute may then be added to Client.
Class EmployeeClient avoids the address ambiguity by inheriting
from both Employee and ClientNA . Letting LA stand for
Multiple Inheritance LongAddress and SA for ShortAddress, we obtain:
A subclass may have two or more superclasses, inheriting all
properties and constraints from each. For example, we may
introduce an account that combines the features of a checking
account and a savings account, a so-called BahamaAccount:

Alternatively, the ancestor class Person could be subdivided in an

Careless use of multiple inheritance can result in the introduction analogous fashion. For example, subclass PersonWithLongAddress
of frivolous subclasses that do not describe any possible instance. could be made the common superclass of EmployeeLA and
For example, one may define a meaningless subclass that inherits ClientLA. Pushing the distinction up one level has the advantage
from, say, both Account and Mammal. Such constructions may be of addressing similar ambiguities that may arise in any additional

95
 Person subclasses that are introduced. An even better strategy is to Nationality = American + NonAmerican
SYSTEMS ANALYSIS

use only one form of Address, if this is possible. Gender = Female + Male
Height = Short (< 1.6m) + Medium + Tall (> 1.8m).
Sibling Relationships
All crossings are permitted. For example, the intersection of
The relationship among the n sibling subclasses Q1, Q2, ... Qn of
Americans, females, and people of height less than 1.6m leads to
superclass P may be stronger than indicated by the mere fact that
a meaningful class.
they are all subclasses of the same superclass. We discuss three
special cases, exclusion, covering, and partitioning. Assuming that each of these have been described as subclass
structures, there are two variant techniques for using them to
Exclusion
derive new subclasses, attribute narrowing and mixin1 inheritance.
We may know that sibling subclasses are definitionally disjoint,
In the first, properties are listed as attributes of a base class, and
thus exclude each other. Among other constraints, this implies
narrowed in subclasses. The superclass may list unconstrained
that if we have an instance of Q1 then we know that this instance
domains, and the subclass constrained ones:
does not satisfy the definitional characteristics of Q2, ... Qn.
For example, clients may be divided into two definitionally exclusive 1Footnote
categories: The term “mixin” has grown to be used so commonly in a
P = the class of clients particular technical sense to have lost its hyphen. This also true of
Q1 = those clients that are also employees a few other terms, including “callback”
Q2 = those clients that are not employees. Using mixin inheritance, classes representing completely
For another example, assume that different account subclasses independent properties are “mixed together” via multiple
have been characterized in terms of attributes and/or constraints inheritance in the target class. The superclasses used in mixin
such that they are, in principle, mutually exclusive: inheritance are often totally useless, and even unnatural by
Account = BankAccount + ClientAccount themselves, but readily combine with others to form meaningful
ClientAccount = Personal + Joint + Business classes. For example:

A “+” is conventionally used in textual listings of disjoint classes.

We also denote this graphically as follows:

Independence
The previous example illustrated two different strategies for relating
partitioned attribute structures through inheritance. While similar,
these are not always equivalent in effect. For example, consider a
MailingLabel class with a set of attributes containing no explicit
codependency constraints:

The subclasses in a family of subclasses Q1, Q2, ..., Qn of P

bearing an exclusion property are connected in an indirect way to
the superclass P. Their family membership is expressed by
connecting them first to an intermediate box which is in turn is
attached to the superclass. This notation is also used for covering
and partitioning. To discriminate among them, we put an E, C, or
P in the little intermediate box.
Multiple Relationships
A class may bear more than one family of exclusions, coverings While unstated, there are some implicit constraints among the
and/or partitionings. These sets are independent (or orthogonal) when attributes, especially the fact that together they describe an actual
the intersection of any tuple of subclasses taken from the different postal address. However, these constraints are not even specifiable
characterizations is nonempty. As an example, consider the without recourse to a model of the entire postal system, and
following sets of properties describing Human s: thus, probably, of the entire planet.

96
There are many ways in which these properties could have been their importance in a given model or hierarchy. Leaving them

SYSTEMS ANALYSIS
factored into classes. One extreme is to create a class for each attribute implicit can be a source of error. Of course, the best solution is to
and then to use multiple inheritance to bind them together: add appropriate attributes. For example:

This class structure suggests that the different aspects of a

MailingLabel may be viewed “in isolation”. But this is not necessarily
true, especially if each of the mixed-in classes contains a transition
that changes the value of the single attribute it maintains.
Changing, say, the city surely requires changes in the zipcode. When
properties are truly orthogonal, multiple inheritance is a good way
of describing property combinations. But the implicit constraints
that the parts together form a legal address indicate otherwise here
(and in nearly all similar situations). Most often, interdependencies
are much more explicit than in this example, thus arguing
immediately against multiple inheritance. Review
Here, an intermediate factoring is more attractive. By isolating the Attibute Features
address properties in an Address class, we can still structurally reflect Optional Features
the cohesion of the address attributes. The MailingLabel class then
connects the address to a name. By doing this, we will have created Static and Dynamic properties
an Address class that seems generally useful beyond what is needed Class Relationships
for mailing label purposes. • Property Inheritance
Construction of an Address class is, of course, a pretty obvious • Subclasses
maneuver. But once we have broken out Address, we can think
• Multiple Inheritance
about extending and refactoring this new class. For example, it
seems like a bad idea to use a zip code attribute, since this only • Inheritance of Relations
applies to addresses in the United States. It seems safe to say that Questions
all addresses, world wide, need street and city properties (or
1. Identify objects, introduce their classes, give attributes, their
surrogates such as post office boxes, which are OK since these are
features and constraints as suggested by the following text:
just uninterpreted string attributes). But different countries have
different postal codes and/or other information required on Mr. White is married. He teaches OO Software Engineering classes
mailing labels. This could be captured through standard on Fridays. He is a part-time member of the faculty at the CS
subclassing mechanics. Department of the All-Smart Institute. His 23-year-old son John
was enrolled in the OOA class that Mr. White taught in the
Adding Attributes previous semester. John does not like broccoli. Mrs. White uses a
As illustrated in the previous example, inheritance may be used to ten-speed for transportation to and from the campus (she teaches
help elicit and flesh out tacit dependencies among attributes. Philosophy at the same institute). Class size is limited at the
Attempts to factor classes into hierarchies may also reveal attributes institute to 14 students. The faculty at the institute, when seen as
that were not originally listed in classes, but only implicitly parents, have at most two children. The sister of John has a
assumed. boyfriend that is two years younger than she is and plays two
For example, an Employee class might be defined as a subclass of different instruments.
Person, with additional attributes such as salary. But there may be 1
other properties that distinguish employees from people in general
2
that nobody bothered to list. Assuming that this class is used in
our banking application, an obvious one is the predicate 3
worksForAB, which is true for employees but not others, and 4
similarly for isEmployed, mayParkInEmployeeLot, and perhaps many 5
others.
It is sometimes difficult to avoid implicit distinctions during initial
class definition. There may be innumerable ways in which objects
of conceptually defined subclasses differ from those of their
superclasses. These are only made explicit when analysts notice

97
 2. A “meta” constraint on a class may express how many instances 9
SYSTEMS ANALYSIS

it can have in a particular target system. As a special case, a 10

constraint may express for a class that it has only one instance.
11
Would such a construct obviate the notion of an instance?
Consider the notions of the president of a company, New 12
Year, the first day of the year, Washington, the capital of the 2. Give examples of generic classes having one, two, ... arguments.
United States, and the headquarters of a bank. 1
1 2
2 3
3 4
4 5
5 2. Discuss whether the following families of objects can be
1. Describe a set of classes that represent entities in your kitchen. represented as a set and/or as a class.
1 1. The states of the US.
2 2. The members of your family.
3 3. The atoms in the universe.
4 4. The inhabitants of Berlin.
5 5. The colors of the rainbow.
Formulate a relation that has tuples of length four, five, ... Try to 6. The natural numbers.
avoid relations that are constructed by adjoining time and/or 7. The days of the week.
space qualifiers as in: John travels from A to B on Sunday .
1
1
2
2
3
3
4
4
5
5
1. We have advocated introducing subclasses through the
Can the following information be represented as relationships? mechanism of applying only one of the subclassing
1. The balance of an account ten days ago. mechanisms at a time. Multiple inheritance will in general deviate
2. Accounts associated with the zip code(s) of their owners. from this advice. Is the advice wrong? Should multiple
inheritance be avoided?
3. Employees located in Toronto.
1
4. The grandparents of the children living in Springfield.
2
5. The weather report of 2001 January 1.
3
6. The molecular structure of H2O.
4
7. The contents of a library.
5
8. The public transportation schedule in LA (assuming they have
one). 1. To obtain justification for relationship inheritance, we looked
into the justification of class inheritance. Check the list of class
9. The recipes in a cookbook.
justifiers and try to construct additional justifiers for relationship
10. The patterns of traffic lights at an intersection. inheritance. Consider, for example, multiple inheritance for
11. The contents of an encyclopedia. relations.
12. The grammar of FORTRAN. 1
1 2
2 3
3 4
4 5
5 2. Consider a domain with which you are familiar, for example, a
6 university environment, a kitchen, a hardware store, etc. Describe
fragments of such a domain exploiting (multiple) inheritance.
7
8

98
1

SYSTEMS ANALYSIS
2
3
4
5
3. Does it make sense to make Human a subclass of Mammal and
Male and Female subclasses of Human? If not, what would be
an alternative?
1
2
3
4
5
4. Give an example of classes related by inheritance, possibly
involving multiple inheritance, where there are at least four
levels of parent — child classes.
1
2
3
4
5
Compare Waterfall and Iterative Enhancement model.
References
• G. Booch. Object Oriented Design with Applications. Benjamin/
Cummings, 1990.
• R.J. et al Brachman. Living with classic: When and how to use
a kl-one-like language. In John F. Sowa, editor, Principles of
Semantic Networks. Morgan Kaufmann, 1991.
• R. Carnap. Meaning and Necessity. The University of Chicago
Press, 1947.
• D.W. Embley, B. Kurtz, and S.N. Woodfield. Object-Oriented
Systems Analysis. Yourdon Press/Prentice Hall, 1992.
• R.J. Brachman. A structural paradigm for representing
knowledge. Technical Report 3605, BBN, May 1978.
• D.W. Embley, B. Kurtz, and S.N. Woodfield. Object-Oriented
Systems Analysis. Yourdon Press/Prentice Hall, 1992.
• D. Maier. The Theory of Relational Databases. Computer Science
Press, 1983.
• Z. Manna and R. Waldinger. The Logical Basis for Computer
Programming. Addison-Wesley, 1985.
• J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W.
Lorensen. Object-Oriented Modeling and Design. Prentice Hall, 1991.
• J.D. Ullman. Principles of Database Systems. Computer Science
Press, 1982.

99
 CHAPTER II
LESSON 20 : SYSTEM INVESTIGATION
INTRODUCTION TO FACT
FINDING TECHNIQUES
SYSTEMS ANALYSIS

Topics Covered Overall Strategy for Fact Finding

• Introduction to system Investigation 1. Learn all you can from existing documents
• Fact Finding Techniques 2. If appropriate, observe the system in action
• Observation 3. Conduct interviews
• Interview 4. Use questionnaires to clear up things you don’t fully understand
• Investigation
5. Follow-up
• Questionnaire
Study & Analyze Current System
Objectives
— Activities —
Upon completion of this Lesson, you should be able
to: 1. Learn about current system (gather facts)
• Explain the Nature of System Investigation 2. Model current system
• Explain the various fact finding techniques 3. Analyze problems/opportunities (study facts)
• Know about Fact analysis 4. Establish new system objectives
Output —
Introduction System Investigation
1. Complete statement of user environment
Requirements Analysis Goals
2. Models of current system
• Fully describe the current system
3. List of major problems/causes/effects
• Study and analyze the current system (gather and study facts)
4. System objectives
• Determine the ideal information system
Some Questions That Must be Answered
• Identify resource constraints
• What are the inputs to this system?
• Define and prioritize requirements
• What are the outputs of this system?
• Inspire user confidence/ownership
• What is the business process (i.e., how is data processed)?
Study & Analyze Current System
• Who are the direct end-users?
• Gather information on what the system should do from as
many sources as possible • How will the users feel about this system?
• Concentrate on WHAT is needed, not HOW to do it • Who developed the existing system?

• “Don’t try to fix it unless you understand it” Learn About Current System (gather facts)
• Major problem: analyst not understanding user needs Gather information from:
Initial investigation –Current information system:
Ø This phase introduces the objectives of the initial investigation, –External sources
the steps required to initiate an investigation; the tasks involved • Reviewing other IS outside the organization can reveal practical
in the initial investigation, and the data gathering and ideas and techniques
interviewing techniques.
–Internal sources
Ø It also includes information and exhibits that should be in the
• Single most important source of facts is the user
initial investigation report, with regard to “How the standards
manual might be used?” and “why to do this after reading this • Existing paper work or documents is also a good source
section.” Analyze Problems / Opportunities(study facts)
• Study and analyze the “current” system
• Problem analysis is difficult.
–We often try to solve problems without analyzing them.
–We try to state the problem in terms of a solution.

100
 • Review of written documents,

SYSTEMS ANALYSIS
• Use the PIECES framework to frame your investigation of
the problems, opportunities, and requirements • On-site observations,
– Performance analysis • Interviews, and
– Information and data analysis • Questionnaires.
– Economic analysis • Brainstroming
– Control and security analysis • Delphi Method
– Efficiency analysis,Service analysis Review of Written Documents
Requirements Analysis Document • When available, all documentation on data carriers (forms,
• Parts records, reports, manuals, etc.) is organized and evaluated.

How analysis was conducted • Included in procedures manuals are the requirements of the
system, which helps in determining to what extent they are
• Credibility met by the present system.
• Restarts • Unfortunately, most manuals are not up to date or may no be
User requirements readable. Day-to-day problems may have forced changes that
are not reflected in the manual.
System constraints
• Furthermore, people have a tendency to ignore procedures and
Realistic System Objectives find shortcuts as long as the outcome is satisfactory.
User Requirements • Regarding existing forms, the analyst needs to find out how
• User system objectives (unedited) they are filled out, how useful they are to the user (in our
• Reports (type/frequency) scenario, the customer.) what changes need to be made, and
how easy they are to read.
• User training needs
• Effect of system on various users On-Site Observation
• Another fact-finding method used by the system analyst is on-
Organization Chart
site or direct observation. The analyst’s role is that of an
Tactics information seeker.
• Listen - don’t lecture • One purpose of on-site observation is to get as close as possible
• Don’t pre-solve problem to the “real” systems being studied.
• Compare stories • As an observer, the analyst follows a set of rules. While making
observations, he/she is more likely to listen than talk, and to
• Look for reluctant responses
listen with interest when information is passed on. He/she
• Observe your effects on system avoids giving advice, does not pass moral judgment on what is
• Avoid politics (head nodding) observed, does not argue with the user staff, and does not
• Expect hard, boring work show undue friendliness toward one but not others.
• Fact-finding Methods • On-site observation is the most difficult fact-finding technique.
It requires intrusion into the user’s area and can cause adverse
• Research and site visits
reacting by the user’s staff I not handled properly.
• Existing documentation
• The analyst observes the physical layout of the current system,
• Observation the location and movement of people, and the workflow. He/
• Questionnaires she is alert to the behavior of the user staff and of the people
• Interviews with whom they come into contact.
Observation • A change in behavior observed in perspective.
• Not for long periods of time The following questions should precede a decision to use on
sit observation.
Will change what your measuring
1. What behavior can be observed that cannot be described in
• Vary observation periods other ways?
• Take only minimal, preplanned notes 2. What data can be obtained more easily or more reliably by
• Coordinate visit beforehand and Beware of Selective observation than by other means?
Perception!!!
3. What assurances can be given that the observation process is
Fact-Finding not seriously affecting the system or the behavior being
After obtaining this background knowledge, the analyst begins to observed?
collect data on the existing system’s outputs inputs, and costs. 4. What interpretation needs to be made on observational data
They are to avoid being misled by the obvious?

101
 • If one-site observation is to be done properly in a complex the renewal cycle, preparing the bill, processing the payment,
SYSTEMS ANALYSIS

situation, it can be time-consuming. Proper sampling and accounting for cash receipts.
procedures must be use to ascertain the stability of the behavior • Decision tables describe the data flow within a system. They are
being observed. Without knowledge of stability, inferences generally used as a supplement when complex decision logic
drawn from small samples of behavior (small time slices) can cannot be represented clearly in flowchart.
prove inaccurate and, therefore, unreliable.
• As a documenting tool, they provide a simpler from of data
Interviews and Questionnaires analysis than the flowchart. When completed, they are an easy-
• On-site observation is directed toward describing and to-flow communication device between technical and non
understanding event and behavior as they occur. This method, technical personnel. They are verbally oriented to managers,
however, is less effective for learning about people’s perceptions, easy to learn and update,
feelings, and motivations. Input/output Analysis Sheet
• The alternative is the personal interview and the questionnaire.
In either method, heavy reliance is placed on the interviewee’s
report for information about the job, the present system, or Dept: Safe Deposit System: Billing Date: ------
experience. The quality of the response is judged in terms of
its reliability and validity. Input Processing/Files Output
• Reliability means that the information gathered is dependable
Customer file record Customer record pulled out to determine expiration date Customer
enough to be used for making decisions about the system and renewal rate. file record
being studied.
If expiration date is less than 30 days, a billing
• Validity means that the questions asked are so worded as to statement is prepared.

elicit the intended information.

Customer Payment Payments are sent to the accounting department.
• So, the reliability and validity of the data gathered depend on Payment /credit memo is sent to data processing for
the design or the interview or questionnaire and the manner in verification and crediting customer’s account. The memo is
which each instrument is administered. returned for filing.
Memo creates a journal entry in a cash and balance journal.
• In an interview, since the analyst (interviewer) and the person(s) Data processing produces ages receivable report.
interviewed meet face to face, there is an opportunity for greater Memo becomes a part of customer safe deposit active list.
flexibility in eliciting information. Data processing produces safe deposit revenue report.
Copy is sent to safe deposit and another copy kept on file .
• The interviewer is also in a natural position to observe the Customer receipt of payment mailed to customer.
subjects and the situation to which they are responding. In
contrast, the information obtained though a questionnaire is
limited to the written responses for the subjects to predefined
questions. • A structure chart is a working tool and an excellent way to keep
Fact Analysis track of the data collected for a system.
• As data are collected, they must be organized and evaluated • There are several variations of structure chart, locates the module
and conclusions drawn for preparing a report to the user for associated with the IPO on the hierarchy chart, and identifies
final review and approval. the data elements along the line linking the module to a higher
• Many tools are used for data organization and analysis. level (parent).

• Input/output analysis identifies the elements that are related

to the inputs and outputs of a given system. Flowcharts and Deposit Account Journal
Verify and
data flow diagrams are excellent tools for input/output analysis. HEAD
TELLER
Process Detailed
payment
• Data flow diagrams are also used to analyze the safe deposit Transaction Data
billing system. Receipt Payment
• They can be very effective in settings that pose few constraints 1 Unpaid
on data flow diagram whose content is equivalent to the Extract Balance 5 Cash and
Account Balance
information-oriented flowchart . to Read Expiring Customer File Customer Journal

• It shows the general steps in the safe deposit billing system. As Box
an input/output analysis technique, it enables the analyst to Reading
focus on the logic of he system and develop feasible alternative.
2
• The circles (also called bubbles) represent a processing point Read Apply New
expiration Billing 3 Prepare Accounting
within the system. The open rectangles represent data stores or date and Renewal
Statement Department
Rate Cycle
points where data are stored. The square are departments or
people involved in the billing system. The major steps in the
billing process are extracting the customer account, applying

102
 Safe

SYSTEMS ANALYSIS
Information-Gathering Methods
Deposit Box Rates
Categories of Information
Review literature,
Kinds of information Information procedures and forms

Describing
• Policies On-site observation
• Goals
The
• Objective organization

• Organization
User Information gathering Interviews Data organization
• Arbitary Relationships staff Information
tools
• Information Requirements
The work
• Interpersonal Relationships itself

• Work flow Questionnaires

• Methods and procedure
• Work schedule
Information about User Staff Where Does Information Originate ?
• Another kind of information for analysis is knowledge about • Information is gathered from tow principal sources: personnel
or written documents from within the organization and from
the people who run the present system – their job functions
the organization’s environment. The primary external sources
and information requirements, the relationships of their jobs
are :
to the existing system, and the interpersonal network that holds
the user group together. 1. Vendors
• We are actually focusing on people’s roles, authority 2. Government documents
relationships, hob status and functions, information 3. Newspapers and professional journals.
requirements, and interpersonal relationships. Ø The primary internal sources are:
• Information of this kind highlights the organization chart 1. Financial reports.
and establishes a basis for determining the importance of the
2. Personnel staff.
existing system for the organization.
3. Professional staff (legal counsel, EDP [electronic data
• In summary, the major focus is to find out what people the processing] auditor, etc).
analyst is going to be dealing with and what each person expects
to get out of a candidate systems before it goes though design 4. system documentation or manuals.
and final implementation. 5. The user of user staff.
• Once such information is secured, the next step is to show 6. Reports and transaction documents.
how various jobs hang together within work schedules and • Hardware vendors are traditional sources of information about
procedures. systems and software. Other equipment manufactures provide
Information about Work Flow information about competitive system’s A third source that
\Workflow focuses on what happens to the data though various has experienced tremendous growth during the past decade is
points in a system. This can be shown by a data flow diagram or the software house.
a system flowchart. • There are thousands of software packages on the market to
A data flow diagram represents the information generated at each suit virtually every problem area with reasonable modifications.
processing point in the system and the direction it takes from • Independent listings of software packages and their vendors
source to destination. are available through associations such as computerworld and
In contrast, a system flowchart described the physical system. The DATAPRO, or other organizations with experience in the
information available from such charts explains in the procedures application under consideration.
used for performing tasks and work schedules. Details on charts • Other external sources if information are government
are converted. documents, technical newspaper, and professional journal.
Computerwrold, for example, provided weekly information
about new hardware, hardware installations, software
developments, and trends in the field.
• Articles are also published in system development,
documentation, and EDP journals, such as Communications
of the ACM and Journal for System Management. They provide
invaluable updates in the system area.

103
 • Internal sources of information are limited to the user staff, Review
SYSTEMS ANALYSIS

company personnel, and various reports. User personnel are • Intial Investigation
the font-line contacts for acquiring and validating information
• Fact Finding Techniques
about a system.
• Observation
• An important sources of information is the key employee
who has been in the user area for years and is familiar with • Interview
present activities and applications. As we shall se in some cases, • Investigation
that is the only source available to the analyst. • Questionnaire
Information-gathering Tools Questions
Ø No two projects are ever the same. This means that the analyst 1. Why is it difficult to manage system development?
must decide on the information gathering tool and how it
must be use.
Ø Although there are no standard rules for specifying their use,
an important rule is that information must be acquired accurately,
methodically, under the right conditions, and with minimum
interruption to user personnel.
Ø For example, if the analyst need only information available in
existing manuals, then interviewing is unnecessary except where
the manual is not up to date. If additional information is 2. What important information does the user’s request form
needed, on-site observation or a questionnaire may be provide? Why is it so important in the initial investigation?
considered. Therefore, we need to be familiar with various
information-gathering tools. Each tool has a special function,
depending on the information needed.
Review of Literature, Procedure, and Forms
• Very few system problems are unique. The increasing number
of software packages suggests that problem solutions are
becoming standardized.
3. Why is it difficult to determine user requirements? IIustrate
• Therefore, as a first step, a search of the literature though
professional references and procedures manuals, textbooks,
company studies, government publications, or consultant
studies may prove invaluable.
• The primary drawback of this search is time. Often it is difficult
to get certain reports. Publications may be expensive, and the
information may be outdated due to a time lag in publication.
• Procedures manuals and forms are useful sources for he analyst.
Describe about input/output analysis.
They describe the format and functions of the present system.
• Included in most manuals are system requirements that help
determine however various objectives are met. Up-to-date
manuals save hours of information-gathering time.
Unfortunately in many cases, manuals do not exist or are
seriously out of date.
• Included in the study of procedures and manuals is close look
at existing forms. Printed forms are widely used for capturing
and providing information. What is the difference between Open ended and Closed ended
Questions asked in an interview?
• The objective is to understand how forms are use.
What are some of the disadvantages of interviewing?
The following questions may be useful.
Where structured analysis used in the system specification?
1. Who uses the form(s) ? How important are they to the user?
Compare Waterfall and Iterative Enhancement model.
2. Do the forms include all the necessary information ? What
items should be added or deleted?
3. How many departments receive the existing form(s) ? Why?
4. How readable and easy to follow is the form?
5. How does the information in the form help other users make
better decisions? What other uses does the form offer the user
area?

104
References

SYSTEMS ANALYSIS
Hoffer, Jeffrey A.
Modern systems analysis and design
2nd ed. Delhi : Pearson Education Asia, 2000
Sarkar, A.K.
Systems analysis, data processing and
quantitative techniques
New Delhi : Galgotia Publications, 1997
Hawryszkiewycz, Igor
Introduction to systems analysis & design
4th ed. New Delhi : Prentice Hall of India, 2002
Awad, Elias M.
Systems analysis and design
New Delhi : Galgotia Publications, 1997
Heuring, Vincent P.
Computer systems design and architecture
Delhi : Pearson Education Asia, 1997
Whitten, Jeffrey L.
Systems analysis and design methods
5th ed. New Delhi : Galgotia Publications, 2001
Shelly, Gary B.
Systems analysis and design
3rd ed. New Delhi : Galgotia Publications, 1999
Website Addresses
www.scit.wlv.ac.uk
www.privcom.gc.ca
www.conferences.global-investor.com
www.umsl.edu
Notes

105
 LESSON 21 :
SYSTEMS ANALYSIS

FACT FINDING TECHNIQUES

Topics Covered • The emphasis is not on giving advice or passing moral

• Onsite Observation judgment on what is observed.
• Observation methods • Furthermore, care is taken no to argue with the persons being
observed or to show hostility toward one person and undue
• Interview and Questionnaires (In Detail) friendliness toward another.
Objectives When human observers are used, four alternative observation
Upon completion of this Lesson, you should be able to: methods are considered :
• Explain about the onsite observation method Natural or contrived.
• Discuss the Problems in observation method • A natural observation occurs in a setting such as the employee’s
• Describe about the method interviewing place of work; a contrived observation is et up by the observer
• Discuss the advantage of interview in place lie a laboratory.

• Recollect the fact finding method which we have gone through Obtrusive or unobtrusive.
in the previous Lesson before reading this Lesson • An obtrusive observation takes place when the respondent
On-Site Observation knows he/she is being observed; an unobtrusive observation
takes place in a contrived way such as being a one-way mirror.
• Another information-gathering tool used in system studies is
one-site observation. It is the process of recognizing and noting Direct or indirect.
people, objects, and occurrences to obtain information. • A direct observation takes place when the analyst actually
• The analyst’s role is that of an information seeker who is observes the subject or the system at work. In an indirect
expected to be detached (therefore unbiased) from the system observation, the analyst uses mechanical devices such as cameras
being observe. and videotapes to capture information.
• This role permit participation with the user staff openly and Structured or unstructured.
freely. • In a structured observation the observer looks for and records
• The major objective of on-site observation is to get as close as a specific action such as the number of soup cans a shopper
possible to the “real” system being studied. picks up before choosing one.
• For this reason it is important that the system. • Unstructured methods place the observer in a situation to
• For example, if the focus of the analysis is communication, observe whatever might be pertinent at the time.
one needs to know as much s possible about the modes of • Any of these methods may be use in information gathering.
communication available though the organization structure Natural direct, obtrusive, and unstructured observation are
and the aspects of the physical layout that might adversely frequently used to get an overview of an operation.
affect communication. • The degree of structure is increased when observations have a
The following questions can serve as a guide for on-site specific purpose. An example is tracing the rout of a sales
observations. invoice though a system.
1. What kind of system is it? What does it do? • The degree of obtrusiveness may decrease when one wants of
2. Who runs the system? Who are the important people in it? observe the tasks that make up a given job.
3. What is the history of the system? How did tit get to its • For example the analyst may want to create a list of the activities
present stage of development? of production supervisor by observing him/her form a remote
location. Indirect observation could be used in a similar manner.
4. Apart form its formal function, what kind of system is it in
comparison with other systems in the organization? Is it fast • For instance, the daily routine of a bank teller may be observed
paced or is it a leisurely system that responds slowly to external indirectly via a video camera.
crises? • Finally, contrived situations re used to test or debug a candidate
• As an observer, the analyst follows a set of rules. While making system. They are also used in training program to help evaluate
observations, he/she is more likely to listen than talk and to the progress of trainees.
listen with a sympathetic and genuine interest when • Electronic observation and monitoring methods are becoming
information is conveyed. widely used information-gathering tools because of their speed,
efficiency, and low cost.

106
• For example, some truck fleets use an electronic recorder system • There is information of a more difficult nature that user staff

SYSTEMS ANALYSIS
that records, analyzes, and reports information (online) about may be reluctant opt give directly, however-for example,
the hours and minutes a vehicle was driven faster than 60 miles information on company politics or satisfaction with the
per hour, the number of hours an engine was idle in a day, and supervisor.
how much out-of-service time a vehicle had. • When asked by direct questions, the respondent may yield
• These and other electronic methods expedite the information- information that is invalid; yet properly handled, information
gathering process in systems analysis. can be successfully obtained with interviews or questionnaires.
On-site observations are not without problems Interviews
1. Intruding into the user’s area often results in adverse reactions • The interview is a face-to-face interpersonal role situation in
by the staff. Therefore, adequate preparation and training are which a person called the interviewer asks a person being
important. interviewed questions designed to gather information about a
2. Attitudes and motivations of subjects cannot be readily problem area.
observed only the actions that result from them. • The interview is the oldest and most often used device for
3. Observation are subject to error due to the observer’s gathering information in system work. It has qualities that
misinterpretation and subjective selection of what to observe behavioral and on-site observations do not possess.
, as well as the subjects’ altered worked pattern during It can be used for Two Main Purposes
observation.
(1)As an exploratory device to identify relations or verify
4. Unproductive, long hours are often spent in an attempt to information, and
observe specific, one-time activities or events.
(2)To capture information as it exists.
In deciding to use an on-site Observation, Several • Validity is no small problem. Special pains are taken to eliminate
Questions are Considered interview bias.
1. What behavior can be observed that cannot be described in • We assume that information is more valid, the more freely it is
other ways? given.
2. What data can be obtained more easily or more reliably by • Such an assumption stressed the voluntary character of the
observation than by other means? interview as a relationship freely and willingly entered into by
3. What assurances can be given that the observation process is the respondent.
not seriously, affecting the system or the behavior being • If the interview is considered a requirement, the interviewer
observed? might gain the respondent’s time and attention, but cannot be
4. What interpretation needs to be made about observational certain of the accuracy of the information gathered during the
data to avoid being misled by the obvious? interview.
5. How much skill is required and available for the actual • In an interview, since the analyst (interviewer) and the person
observation? interviewed meet face to face, there is an opportunity for
• For on-site observation to be done properly in a complex flexibility in eliciting information.
situation it can be very time-consuming. • The analyst is also in a position to observe the subject.
• Proper sampling procedures must be used to ascertain the • In contrast, the information obtained though a questionnaire
stability of the behavior being observed. is limited to the subject’s written responses to predefined
• Without a knowledge of stability, inferences drawn from small questions.
samples of behavior (small time slices) can be inaccurate. There are four primary advantages of he
Interviews and Questionnaires interview
• As we have seen, on-site observation is directed primarily toward 1. Its flexibility makes the interview a superior technique for
describing and understanding event as they occur. It has exploring areas where not much is known about what question
limitations when we need to learn about people’s perceptions, to ask or how to formulate questions.
feelings, or motivations, however. 2. It offers a better opportunity than the questionnaire to evaluate
• Therefore, other information-gathering tools are also use for the validity of the information gathered. The interviewer can
analysis. observe not only what subject say but also how they say it.
• Information-gathering tools fan be categorized by their degree 3. It is an effective technique for eliciting information about
of directness. If we wish to know about something, we simply complex subjects and fro probing the sentiments underlying
ask someone about it directly, but we may not get an answer. expressed opinions.
• Most of the information-gathering tools used in system analysis 4. Many people enjoy being interviewed, regardless of the subject.
are relatively direct. This is a strength because much of the They usually cooperate in a study when all they have to do is
information needed can be acquired by direct questions. talk. In contrast, the percentage of returns to a questionnaire is
relatively low: oven less than 20 percent. Attractive designed
questionnaires that are simple to return, easy to follow, and

107
 presented in a context that inspires cooperation improve the • Discouraging distracting conversation controls the direction
SYSTEMS ANALYSIS

return rate. of the interview.

• The major drawback of the interview is he long preparation • During stages setting the interview3r evaluated the cooperation
time. Interviews also take a lot of time to conduct, which of the interviewee.
means time and money. So whenever a more economical • Both the content and tone of the responses are evaluated.
alternative captures the same information, the interview is
• How well the interview goes depends on whether the
generally not used.
interviewee is the friendly type, the timid type who needs to be
The Art of Interviewing coaxed to talk, or the resident expert, who bombards the analyst
• “Interviewing an art”. Few analysts learn it in school, but most with opinions disguised as facts.
of them develop expertise though experience though • In any case, the analyst adjusts his/her own image to counter
experience. that of he interviewee.
• The interviewer’s art consists of creating a permissive situation Establishing Rapport
in which the answers offered are reliable.
• In one respect, data collection is an imposition on user staff
• Respondents’ opinions are offered with no fear of being time and an intrusion into their privacy.
criticized by others.
• Even though the procedure is authorized by management in
• Primary requirements for a successful interview are to create a advance, many staff members are reluctant to participate.
friendly atmosphere and to put the respondent at ease.
• There is seldom a direct advantage I n supplying information
• Then the interview proceeds with asking questions properly, to outsiders, regardless of their credentials. There is a strong
obtaining reliable responses, and recording them accurately and perception that it may do them harm.
completely.
• This factor makes it important to gain and maintain rapport
Arranging the Interview with the user staff.
• The interview should be arranged so that the physical location, • The investigation is an art.
time of he interview, and order of interviewing assure privacy Although there are no ground rules to follow, there arepitfalls
and minimal interruption. to avoid.
• Usually a neutral location that is non-threatening to the a. Do not deliberately mislead the user staff about the purpose
respondent is preferred. of the study. A careful, well-thought-out briefing of participants
• Appointments should be made well in advance and a fixed should not provide any more detail than is necessary. Too much
time period adhered to as closely as possible. technical detail may tend to confuse people. The briefing should
• Interview schedules generally begin at the top of the be consistent for all participants to avoid rumors.
organization structure and word down so as not to offend b. Assure interviewees confidentiality that no information they
anyone. offer will be released to unauthorized personnel. The promise
Guides to a Successful Interview of anonymity is very important.

• Interviewing should be approached as logically as c. Avoid personal involvement in the affairs of the user’s
programming. department or identification with one faction a the cost of
another. This may be difficult when several groups are involved
In an Interview, the following steps should be Taken in the study.
1. Set the stage for the interview. d. Avoid show in off you knowledge or sharing information
2. Establish rapport; put the interviewee at ease. received from other sources.
3. Phrase questions clearly and succinctly. e. Avoid acting like an expert consultant. This can reduce the
4. Be a good listener; avoid arguments. objectivity of the approach and discourage people form freely
giving information.
5. Evaluate the outcome of the interview.
f. Respect the time schedules and preoccupations of your subjects.
Stage setting Do not make an extended social event out of the meeting. If
• This is an “ice breaking,” relaxed, informal phase where the the subject does nto complain, subordinates might, especially
analyst opens the interview by focusing on if they are waiting to see the subject (boss).
(a)the purpose of the interview, g. Do not promise anything you cannot or should not deliver,
(b) why the subject was selected, and such as advice or feedback.
(c) the confidential nature of the interview. h. Dress and behave appropriately for the setting and the
circumstances of the user contact.
• After a favorable introduction, the analyst asks the first question
and the respondent answers and goes right through the i. Do not interrupt the interviewee. Let him/her finish talking.
interview.
• The job of the analyst should be that of a reporter rather than
a debater.

108
Asking the questions 2. Copies of all information-gathering tools – questionnaires,

SYSTEMS ANALYSIS
• Except in unstructured interviews, it is important that each interview schedules, observation guides – are placed in the
question is asked exactly as tit is worded. Rewording or notebook for future reference.
imprompt explanation may provoke a different answer or bias 3. Copies of all data- originals or duplicates – are include. Loss of
the response. key data, even temporarily, can be costly.
• The questions must also be asked in the same order as they 4. Minutes of all meetings as well as a record of discussion,
appear on the interview schedule. decisions, and changes in design all become part of the
• Reversing the sequence could destroy the comparability of the notebook.
interviews. • The organization of the notebook is also important. In some
• Finally, each question must be asked unless the respondent, in cases, a purely chronological arrangement will suffice.
answering a previous question, has already answered the next • In others, system of categories with cross-classification would
one. be appropriate.
Obtaining and recording the response • Proper indexing makes it easier to retrieve information when
needed.
• Interviewers must be prepared to coax respondent to elicit
further information when necessary. The “probing” technique Review
enables the interviewer to act as a catalyst, for example:
Interview: I see what you men. Could you elaborate further on Onsite Observation
that? Observation methods
Analyst (interviewer): How do you feel about separating the present Problems in observation method
loan division into commercial and loan departments? Interview
Financial vice president (respondent): well, I’m not sure. Advantage of interviewing
Sometimes I think that we have to take this route eventually.
Analyst: I see. Can you tell me more about that? Questions
List the problems faced while interviewing.
• These statements indicate that the analyst is listening, is
interested, understands what the respondent is trying to say,
and is making an effort to gain more information. The
information received during the interview is recorded for later
analysis.
Data recording and the notebook.
• Many system studies fail because of poor data recording. Care
must be taken to record the data, their source, and time of A question may be closed or open ended. Illustrate the difference.
collection.
• If there is no record of a conversation, the analyst runs the risk
of not remembering enough details, attributing them to the
wrong source, or otherwise distorting the data.
• The form of the notebook varies according to the type of
study, the amount of data, the number of analysts, and their
individual preferences.
• The “notebook” may be a card file, a set of carefully coded file What are the advantages of interviewing?
folders, or a loose-leaf binder. It should be bound and the
pages numbered.
Data Capture and the Notebook
1. Originals or duplicate copies of all notes taken during
investigation are documented. They are the chief sources of
interview and observational data, as well as background
information on the system. Each page of notes should be
numbered serially, and a running chronological record of them
should be kept. The name of the analyst, the date the notes
were taken, and surrounding circumstances are all important.
Since handwritten notes often are not intelligible to others. It
is good to have them transcribed or typed soon after they are
taken.

109
 References
SYSTEMS ANALYSIS

Hoffer, Jeffrey A.
Modern systems analysis and design
2nd ed. Delhi : Pearson Education Asia, 2000

Sarkar, A.K.
Systems analysis, data processing and
quantitative techniques
New Delhi : Galgotia Publications, 1997

Hawryszkiewycz, Igor
Introduction to systems analysis & design
4th ed. New Delhi : Prentice Hall of India, 2002

Awad, Elias M.
Systems analysis and design
New Delhi : Galgotia Publications, 1997

Heuring, Vincent P.
Computer systems design and architecture
Delhi : Pearson Education Asia, 1997

Whitten, Jeffrey L.
Systems analysis and design methods
5th ed. New Delhi : Galgotia Publications, 2001

Shelly, Gary B.
Systems analysis and design
3rd ed. New Delhi : Galgotia Publications, 1999

Website Addresses
www.scit.wlv.ac.uk
www.privcom.gc.ca
www.conferences.global-investor.com
www.umsl.edu
Notes

110
 LESSON 22 :

SYSTEMS ANALYSIS
FACT FINDING TECHNIQUES

Topics Covered Types of Interviews and Questionnaires

• Questionnaire • Interviews and questionnaires vary widely in form and structure.
• Types of interviews Interviews range from the highly unstructured, where neither
the questions nor the respective responses are specified in
• Various types of Questions advance, to the highly structured alternative in which the
Objectives questions and response are fixed. Some variation within this
Upon completion of this Lesson, you should be able range is possible.
to The Unstructured Alternative
• Differentiate various types of Interviews • Ø In unstructured interview is a relatively nondirective
• Explain the types of Questions asked to collect data .Also you information-gathering technique. It allows respondent to
should be able to differentiate the types. answer questions freely in their own words.
Questionnaires • The responses are spontaneous rather than forced.
• In contrast to the interview is the questionnaire, which is a • They are self-revealing and personal rather than general and
term used for almost any tool that has questions to which superficial.
individuals respond. It is usually associated with self- • The role of the analyst an interview is to encourage the
administered tools with items of the closed or fixed alternative respondent to talk freely and serve as a catalyst to the expression
of feeling and opinions.
type.
• This is best achieved in a permissive atmosphere in which the
By its nature, a questionnaire offers the following subjects have no feeling of disapproved.
advantage • The Structured Alternative
1. It is economical and requires less skill to administer than the • In the structured approach, the questions are presented with
interview. exactly the same wording and in the same order to all subjects.
2. Unlike the interviews, which generally questions one subject at • If the analyst asks a subject, “Would you like to see a
a time, a questionnaire, can be administered to large numbers computerized approach to solving your accounts receivable
of individuals simultaneously. problem?” and asks another subject,” How do you feel about
3. The standardized wording and order of the questions and he computers handling accounts receivable?” the response may
standardized instruction for reporting response ensure not be the same even though the subjects both have the same
uniformity of questions. In contrast, the interview situation opinion. Standardized questions improve the reliability of he
is rarely uniform form one interview to the next. responses by ensuring that all subjects are responding to the
4. The respondents feel greater confidence in the anonymity of same questions.
questionnaire than in that of an interview. In an interview, the • Structured interviews and questionnaires may differ in the
analyst usually knows the user staff by name, job function, or amount of structuring of the questions.
other identification. With a questionnaire, respondents give • Questions may be either closed or open-ended. An open-ended
opinions without fear that the answer will be connected to question requires no response direction or specific response. In
their names. a questionnaire, it is written with space.
5. The questionnaire places les pressure on subjects for immediate Examples of open-Ended Questions
responses. Respondents have time to think the questions over
and do calculations to provide more accurate data. • Now that you have had the new installation for six months,
how would you evaluate the benefits?
• The advantage of the self-administered questionnaire
outweigh disadvantage, especially when cost is a consideration. • What is your opinion regarding the “no smoking” policy in
The principal disadvantage is a low percentage of returns. the DP center?

• Another disadvantage is that many people have difficulty • If you had a choice, how would you have designed the present
information center?
expressing themselves in writing, especially when responding
to east (open) questions. Many dislike writing. Because of these Examples of Fill-in-the Blank of your Questions
disadvantages, the interview is probably superior to the • What is the name of the MIS director of your firm.
questionnaire.
• How many analysis handle the accounts receivable conversion?
• What is the average number of calls you receive from clients ?

111
 Provided for the response Open-ended and closed questions have advantages and limitations.
SYSTEMS ANALYSIS

Such questions are more often used in interviews than in Open-ended questions are ideal in exploratory situation where
questionnaires because scoring takes time. new ides and relationships are sought. The main drawback is the
• Closed questions are those in which the responses are presented difficulty of inter-
as set of alternatives. Examples of Multiple-Choice Questions
These are five major varieties of closed • What is the average salary of an entry-level analyst? (Please
questions check one)
1. Fill-in-the blanks questions request specific information .These • Under $15,000
responses can then be statistically analyzed. • $15,000-$19,999
2. Dichotomous (yes/no type) questions that offer two answers • $20,000-$24,999
have advantage similar to those of the multiple-choice type
• Over $25,000
(explained later). The problem is making certain that a reliable
responses can be answered by yes or no; otherwise, and • Please check one category that best describes the business of
additional choice (e.g. yes no, I don’t know) should be included. the firm where you are employed.
The questions sequence and content are also important. • Saving bank
3. Ranking scales questions ask the respondent to rank a list of • College, school, library, association
items in order of importance or preference. The first questions • Computer service
asks the respondent to rank five statements on the basis of
how they describe his/her present job. Industrial company
4. Multiple-choice questions offer respondents specific answer • Outside computer consulting
choices . This offers the advantage of faster tabulation and less • Other (please describe)
analyst bias due to the order in which the answers are given.
Respondents have a favorable bias toward the first alternative An Example of Rating Scale Question
item. Alternating the order in which answer choices are listed • How satisfied are you with the following aspects of you present
may reduce bias but at the expense of additional time to respond job? (Please Circle one for each question)
to the questionnaire. In any case, it is important.
Examples of Dichotomous Questions
Very Dissatisfied No Satisfied Very
• Are you personally using a microcomputer in your business? Dissatisfied Opinion Satisfied
(please circle one yes no
• If not, do you plan to be using one in the next 12 months?
(please circle one) yes no. 1. They way my job
provides for steady 1 2 3 4 5
• In the performance of your work, are you personally involved
employment
in computer hardware/software purchase decisions? (please
2.The chance to be
circle one) yes no.
responsible for the 1 2 3 4 5
An Example of a Ranking Scales Questions work of others.

• Please rank the five statements in each group on the basis of 3.The pleasantness of
the working 1 2 3 4 5
how well they describe the job mentioned on the front page.
conditions.
Write a “1” by the statement that best describes the job; write a
“2” by the statement that provides the next best description,
4. The chance to make
and continue ranking all five statements, using a “5” for the
use of my best 1 2 3 4 5
statement that describes he fob least well.
abilities.
• Workers on this job…..
— Are busy all the time.
— Have work where they do things for other people. • Interpreting the subjective and the tedious responses to open-
— Try out their own ideas. ended questions. Other drawback include potential analyst bias
in interpreting the data and time-consuming tabulation.
— Are paid well in comparison with other workers.
— Have opportunities for advancements.
• Closed questions are quick to analyze but typically most costly
to prepare. They are move appropriate for securing factual
To be aware of these types of bias when constructing multiple- information (for example, about age, education, sex, and salary).
choice questions.
• They have the additional advantage of ensuring that answers
5. Rating scales questions are an extension of the multiple-choice are given in frame of reference consistent with the line of
design. The respondent is offered a range of responses along a inquiry.
single dimension.

112
Structured and Unstructured Interview 2. Question wording.

SYSTEMS ANALYSIS
Technique a. Is the question worded for the subject’s background and
Interview Advantage Drawback
experience?
Type b. Can the question be misinterpreted? What else could it mean
to a respondent?
Structured I. Easy to administer and I. High initial preparation cost c. Is the frame of reference uniform for all respondents?
evaluate due to II. Standardization of questions tends to
d. Is the wording biased toward a particular answer?
standardization reduce spontaneity
II. Required limited training III. Mechanizes interviewing, which makes
e. How clear and direct is the question?
III. Easy to train it impractical for all interview settings 3. Question Format.
new staff a. Can the question best be asked in the form of check
answer(answered by a word or two or by a number) or with a
follow-up free answer?
Unstructured Ø Provides for greater Ø More information of questionable use is
b. Is the response from easy to use or adequate for the job?
creativity and spontaneity gathered
in interviewing Ø Takes more time to conduct-therefore, c. Is the answer to the question likely to be influenced by the
Ø Facilities deeper costly preceding question? That is, is there any contamination effect?
understanding of the Ø Requires extensive training and Reliability of Data from Respondents.
feeling and standing of the experience for effective results.
interviewee
• The data collected from the user staff are presumed to accurately
Ø Offers greater flexibility
correspond with the actual way in which events occur.
in conducting an overall • If such reports are the only source of data, there may be several
interview uncontrolled sources of error :
1. The respondent’s perceptual slant. Perceptual ability is known
Procedure for Questionnaire to vary. Reports of a given event from several staff members
Construction who have no training in careful observation often have little
The procedure for constructing a questionnaire consists of six resemblance to one another.
steps: 2. The respondents failure to remember just what did happen.
1. Decide what data should be collected; that is, define the problem Assuming that he or she received a fairly reliable impression of
to be investigated. an event at the time that it happened, it generally become more
difficult with the passage of time to describe the details of an
2. Decide what type of questionnaire (closed or open-ended)
event.
should be used.
3. Reluctance of persons being interviewed to report their “true”
3. Outline the topic for the questionnaire and then write the
impressions of what occurred. A subject often distorts
question.
descriptions of events for fear of retaliation, a desire not to
4. Edit the questionnaire for technical defects or biases that reflect upset others, or a general reluctance to verbalize a particular
personal values. type of situation.
5. Pretest (try out) the questionnaire to see how well in works. 4. Inability of subjects to communicate their reports or inability
6. Do a final editing to ensure that the questionnaire is ready for of the analyst to get from subjects the information that they
administration. This include a close look at the content, form, are qualified to provide.
and sequ3ence of questions as well as the appearance and
The Reliability-Validity Issue
clarity of the procedure for using the questionnaire.
• An information-gathering instrument faces two major tests:
Ø A critical aspect of questionnaire construction is the formulation
reliability and validity. Before administering the instrument,
of reliable and valid question.
the analyst must ask and answer the questions: What is the
Ø To do a satisfactory job, the analyst must focus on question reliability of the measuring instrument? What is its validity?
content, wording, and format. The following is a checklist of
• The term reliability is synonymous with dependability
what to consider.
consistency, and accuracy. Concern of reliability comes from the
1. Question content necessity for dependability in measurement. Using the
a. Is the question necessary? Is it a part of other questions? questionnaire as an example, reliability may be approached in
b. Does the question adequately cover the area intended? three ways:

c. Does the subject(s) have proper information to answer the 1. If we administer the game questionnaire to the same subject,
question? will we get the same or similar results? This question implies a
definition of reliability as stability, dependability, and
d. Is the question biased in a given direction? predictability.
e. Is the question likely to generate emotional feelings that might
lead to untrue responses?

113
 2. Does the questionnaire the true variables it is designed to Reliable and unreliable Test Scores
SYSTEMS ANALYSIS

measure? This question focuses on the accuracy aspect of

1 2 3
reliability.
“True” Scores from Scores f rom
3. How much error of measurement is there in the proposed
Scores Reliable Unreliable
questionnaire? Errors of measurement are random errors
stemming from fatigue or fortuitous conditions at a given Ra Questionnaire Rank Questionnaire Rank

time, or fluctuation in mood that extent that errors of nk

measurement that errors of measurement are present in a 92 1 96 1 72 3
questionnaire. To the extent that errors of measurement are 81 2 82 2 89 1
present in a questionnaire, it is unreliable. Thus, reliability is 70 3 69 3 51 5
viewed as the relative absence of errors of measurement in a 59 4 61 4 74 2
measuring instrument. 40 5 55 5 67 3
• To illustrate, suppose we administered a questionnaire to
measure the attitude of the user staff toward a new computer
installation. The “true” scores of the five staff members wear • The analyst intended to measure. For this reason, it is important
92 (excellent attitude), 81, 70, 59, and 40. Suppose further that to pretest a questionnaire for validity as well as for reliability.
the same questionnaire was administered again to the same • It can be concluded, then that the adequacy of an information-
group within the same time period and the scores were 96, 82, gathering tool is judged by the criteria of validity and reliability.
69, 61, and 55. Although not a single case hit the “true” score Both depended on the design of the instrument as well as the
again, the second test showed he same rank order. The reliability way it is administered.
in these examples is extremely high. Review
• Now suppose that the last set of scores had been 72, 89, 51, 74,
and 67. They are the same five scores, but they have a different Questionnaire
rank order. In this case, the test is unreliable. There are three
sets of scores. The rank orders of the first two sets of scores
Types of questions
vary exactly. Even though the test scores in the tow column are Types of interviews
not the same, they are in the same rank order. To this extent,
the test is reliable. The opposite case is shown in column (1) Questions
and (3). The rank order changed, making the test unreliable. 1. Differentiate each types of Questions.
• It can be seen, the, that for an information-gathering instrument
to be interpretative, it must be reliable.
• Unreliable measurement is overloaded with error. Although
high reliability is no guarantee of good questionnaire results,
there can be no good results without reliability. It is a necessary,
but not sufficient, condition for the value of questionnaire
results and their interpretation.
• The most common question that defines validity is : Does the
instrument measure what we think it is measuring? 2.Explain about the types of interviewing method to collect data.
• It refers to the notion that the questions asked are worded to
produce the information sought. In contrast, reliability means
that the information gathered is dependable enough to be
used for decision making. Invalidity, the emphasis is on what
is being measured.
• For example, an analyst administers a questionnaire to a user
group to measure their understanding of a billing procedure
and has included in the questionnaire only factual items that
identify the parts of the billing system.
• The questionnaire is not valid because, whereas it m ay measure
employees’ factual knowledge of the billing system, it does
not measure their understanding of it.

114
References

SYSTEMS ANALYSIS
Hoffer, Jeffrey A.
Modern systems analysis and design
2nd ed. Delhi : Pearson Education Asia, 2000

Sarkar, A.K.
Systems analysis, data processing and
quantitative techniques
New Delhi : Galgotia Publications, 1997

Hawryszkiewycz, Igor
Introduction to systems analysis & design
4th ed. New Delhi : Prentice Hall of India, 2002

Awad, Elias M.
Systems analysis and design
New Delhi : Galgotia Publications, 1997

Heuring, Vincent P.
Computer systems design and architecture
Delhi : Pearson Education Asia, 1997

Whitten, Jeffrey L.
Systems analysis and design methods
5th ed. New Delhi : Galgotia Publications, 2001

Shelly, Gary B.
Systems analysis and design
3rd ed. New Delhi : Galgotia Publications, 1999

Website Addresses
www.scit.wlv.ac.uk
www.privcom.gc.ca
www.conferences.global-investor.com
www.umsl.edu
Notes

115
SYSTEMS ANALYSIS

LESSON 23 :
FACT FINDING TECHNIQUES

Topics Covered Three stages of decision making (Herbert Simon)

• Brainstroming
• Delphi Method
Objectives
Upon completion of this Lesson, you should be able to:v
Explain the about the brainstormingv
Explain about Delphi method
Decision Making VS Problem Solving
What is the difference between decision making and problem
solving?

1. Intelligence
“Information is Power”
• Decision making - you choose from alternatives 2.Design
• Problem solving - you determine the response that will alleviate ”Think out of the Box”
a problem
3.Choice
Decisions ”What makes or breaks you”
Programmed Intuitive Approach
• Routine Decisions made under reactions to emotion, hunches, or “gut
• Repetitive feelings” are risky.
• Follow established procedures. Emotions can rule these decisions.
Non Programmed Odiorne identified five emotional attachments that
• Little or no precedent. can hurt decision makers:

• Unstructured. Fastening on unsubstantiated facts and sticking with them.

Being attracted to scandalous issues and heightening their
• Follow your philosophy. significance.
Pressing every fact into a moral pattern.
Overlooking everything except the immediately useful.
Having an affinity for romantic stories and finding such
information more significant than any other kind, including hard
evidence.
Decision Situatio• ns
• Certainty - outcomes are known in advance.
• Risk - some idea of the probabilities associated with the different
outcomes is known.
Uncertainty - very little or no information on outcomes.

116
Decision making by Groups • The Delphi Method is based on a structured process for

SYSTEMS ANALYSIS
Advantages collecting and distilling knowledge from a group of experts by
means of a series of questionnaires interspersed with controlled
• Greater knowledge. opinion feedback (Adler and Ziglio, 1996).
• Wider range of alternatives.
• According to Helmer (1977) Delphi represents a useful
• Increased acceptance of groups decision by members. communication device among a group of experts and thus
• Group members better understand the decision and the facilitates the formation of a group judgement. Wissema (1982)
alternatives. underlines the importance of the Delphi Method as a
• Most important - avoids more mistakes. monovariable exploration technique for technology forecasting.
• He further states that the Delphi method has been developed
Disadvantages in order to make discussion between experts possible without
• One individual may dominate and/or control. permitting a certain social interactive behavior as happens during
• Pressure to conform. a normal group discussion and hampers opinion forming.
• Competition can develop and slant the process. • Baldwin (1975) asserts that lacking full scientific knowledge,
• Tend to accept the first solution and not give as much decision-makers have to rely on their own intuition or on expert
consideration to the other alternatives. opinion. The Delphi method has been widely used to generate
forecasts in technology, education, and other fields (Cornish,
• Most important - speed of process is reduced. 1977).
Four barriers to effective decision • The technology forecasting studies which eventually led to the
making development of the Delphi method started in 1944. At that
1. Complacency time General Arnold asked Theodor von Karman to prepare a
2. Defensive avoidance forecast of future technological capabilities that might be of
3. Panic interest to the military (Cornish, 1977).

4. Deciding to decide • Arnold got the Douglas Aircraft company to establish in 1946
a Project RAND (an acronym for Research and Development)
to study the “broad subject of inter-continental warfare other
then surface.”
• In 1959 Helmer and fellow RAND researcher Rescher published
a paper on “The Epistemology of the Inexact Sciences,” which
provide a philosophical base for forecasting (Fowles, 1978).
• The paper argued that in fields that have not yet developed to
the point of having scientific laws, the testimony of experts is
permissible. The problem is how to use this testimony and,
specifically, how to combine the testimony of a number of
experts into a single useful statement.
• The Delphi method recognizes human judgement as legitimate
and useful inputs in generating forecasts. Single experts
sometimes suffer biases; group meetings suffer from “follow
Aids to creativity the leader” tendencies and reluctance to abandon previously
stated opinions (Gatewood and Gatewood, 1983, Fowles,
• Brainstorming - pre senting a problem to a group of people
1978).
and allowing them to present ideas to its solution.
• In order to overcome these shortcomings the basic notion of
• Gordon Technique - similar to brainstroming but no one except the Delphi method, theoretical assumptions and
the group leader knows the exact nature of the real solution.
methodological procedures developed in the 1950s and 1960s
• Brainwriting - group members jot down their ideas in response at the RAND Corporation.
to a problem situation without discussion. Anonymously,
papers are exchanged with others who add their thoughts and
• Forecasts about various aspect of the future are often derived
through the collation of expert judgement. Dalkey and Helmer
repeat the process until all have participated. developed the method for the collection of judgement for
such studies (Gordon and Hayward, 1968).
The Delphi Method
• Fowles (1978) asserts that the word Delphi refers to the
Definition and Historical Background hallowed site of the most revered oracle in ancient Greece.
• The objective of most Delphi applications is the reliable and Forecasts and advices from gods were sought through
creative exploration of ideas or the production of suitable intermediaries at this oracle.
information for decision making. • However Dalkey (1968) states that the name “Delphi” was
never a term with which either Helmer or Dalkey (the founders

117
 of the method) were particularly happy. Dalkey (1968) to Fowles (1978) anonymity, controlled feedback, and statistical
SYSTEMS ANALYSIS

acknowledged that it was rather unfortunate that the set of response characterize Delphi.
procedures developed at the RAND Corporation, and designed • The group interaction in Delphi is anonymous, in the sense
to improve methods of forecasting, came to be known as that comments, forecasts, and the like are not identified as to
“Delphi”. their originator but are presented to the group in such a way as
• He argued that the term implies “something oracular, to suppress any identification.
something smacking a little of the occult”, whereas, as a matter • In the original Delphi process, the key elements were (1)
of fact, precisely the opposite is involved; it is primarily concerned structuring of information flow, (2) feedback to the participants,
with making the best you can of a less than perfect kind of and (3) anonymity for the participants. Clearly, these
information. characteristics may offer distinct advantages over the
• One of the very first applications of the Delphi method carried conventional face-to-face conference as a communication tool.
out at the RAND Corporation is illustrated in the publication • The interactions among panel members are controlled by a
by Gordon and Helmer (1964). Its aim was to assess the panel director or monitor who filters out material not related
direction of long-range trends, with special emphasis on science to the purpose of the group (Martino, 1978). The usual
and technology, and their probable effects on society. problems of group dynamics are thus completely bypassed.
• The study covered six topics: scientific breakthroughs; Fowles (1978) describes the following ten steps for the Delphi
population control; automation; space progress; war prevention; method:
weapon systems (Gordon and Helmer, 1968). The first Delphi 1. Formation of a team to undertake and monitor a Delphi on a
applications were in the area of technological forecasting and given subject.
aimed to forecast likely inventions, new technologies and the
2. Selection of one or more panels to participate in the exercise.
social and economic impact of technological change (Adler and
Customarily, the panelists are experts in the area to be
Ziglio, 1996).
investigated.
• In terms of technology forecasting, Levary and Han (1995)
3. Development of the first round Delphi questionnaire
state the objective of the Delphi method as to combine expert
opinions concerning the likelihood of realizing the proposed 4. Testing the questionnaire for proper wording (e.g., ambiguities,
technology as well as expert opinions concerning the expected vagueness)
development time into a single position. 5. Transmission of the first questionnaires to the panelists
• When the Delphi method was first applied to long-range 6. Analysis of the first round responses
forecasting, potential future events were considered one at a 7. Preparation of the second round questionnaires (and possible
time as though they were to take place in isolation from one testing)
another.
8. Transmission of the second round questionnaires to the
• According to Wissema (1982), unfortunately the Delphi panelists
method is also sometimes used for a normal inquiry among a
9. Analysis of the second round responses (Steps 7 to 9 are
number of experts. Delphi has found its way into industry,
reiterated as long as desired or necessary to achieve stability in
government, and finally, academe. It has simultaneously
the results.)
expanded beyond technological forecasting (Fowles, 1978).
10. Preparation of a report by the analysis team to present the
• Since the 1950s several research studies have used the Delphi conclusions of the exercise
method, particularly in public health issues (such as, policies
for drug use reduction and prevention of AIDS/HIV) and • Delbecq et al., (1975) argue that the most important issue in
education areas (Adler and Ziglio, 1996; Cornish, 1977). this process is the understanding of the aim of the Delphi
exercise by all participants. Otherwise the panelists may answer
The Basics of the Delphi Method inappropriately or become frustrated and lose interest.
• The Delphi method is an exercise in group communication • The respondents to the questionnaire should be well informed
among a panel of geographically dispersed experts (Adler and in the appropriate area (Hanson and Ramani, 1988) but the
Ziglio, 1996). The technique allows experts to deal systematically literature (Armstrong, 1978; Welty, 1972) suggest that a high
with a complex problem or task. degree of expertise is not necessary. The minimum number of
• The essence of the technique is fairly straightforward. It participants to ensure a good group performance is somewhat
comprises a series of questionnaires sent either by mail or via dependent on the study design.
computerized systems, to a pre-selected group of experts. • Experiments by Brockhoff (1975) suggest that under ideal
• These questionnaires are designed to elicit and develop circumstances, groups as small as four can perform well.
individual responses to the problems posed and to enable the • Before deciding whether or not the Delphi method should be
experts to refine their views as the group workprogresses in used, it is very important to consider thoroughly the context
accordance with the assigned task. within which the method is to be applied (Delbecq et al. 1975).
• The main point behind the Delphi method is to overcome the • A number of questions need to be asked before making the
disadvantages of conventional committee action. According decision of selecting or ruling out the Delphi technique (Adler
and Ziglio, 1996):

118
• What kind of group communication process is desirable in • Goldschmidt (1975) agrees that there have been many poorly

SYSTEMS ANALYSIS
order to explore the problem at hand? conducted Delphi projects. However, he warns that it is a
• Who are the people with expertise on the problem and where fundamental mistake to equate the applications of the Delphi
are they located? method with the Delphi method itself, as too many critics do.
• What are the alternative techniques available and what results • There is, in fact, an important conceptual distinction between
can reasonably be expected from their application? evaluating a technique and evaluating an application of a
technique.
• Only when the above questions are answered can one decide
whether the Delphi method is appropriate to the context in • On the other hand there have been several studies (Ament,
which it will be applied. Adler and Ziglio (1996) further claim 1970; Wissema, 1982; Helmer, 1983) supporting the Delphi
that failure to address the above questions may lead to method.
inappropriate applications of Delphi and discredit the whole • A study conducted by Milkovich et al. (1972) reports the use of
creative effort. the Delphi method in manpower forecasting. The results of
• The outcome of a Delphi sequence is nothing but opinion. the comparison indicated high agreement between the Delphi
estimate and the actual number hired and less agreement
• The results of the sequence are only as valid as the opinions of
between quantitative forecasts and the number hired. Another
the experts who made up the panel (Martino, 1978). The panel
study by Basu and Schroeder (1977) reports similar results in a
viewpoint is summarized statistically rather than in terms of a
general forecasting problem.
majority vote.
• They compared Delphi forecasts of five-year sales with both
• The Delphi method has got criticism as well as support. The unstructured, subjective forecasts and quantitative forecasts that
most extensive critique of the Delphi method was made by
used regression analyses and exponential smoothing. The
Sackman (1974) who criticizes the method as being unscientific
Delphi forecasting consisted of three rounds using 23 key
and Armstrong (1978) who has written critically of its accuracy.
organization members. When compared against actual sales
• Martino (1978) underlines the fact that Delphi is a method of for the first two years, errors of 3-4% were reported for Delphi,
last resort in dealing with extremely complex problems for 10-15% for the quantitative methods, and of approximately
which there are no adequate models. Helmer (1977) states that 20% for the previously used unstructured, subjective forecasts.
sometimes reliance on intuitive judgement is not just a
• In general, the Delphi method is useful in answering one,
temporary expedient but in fact a mandatory requirement.
specific, single-dimension question. There is less support for
• Makridakis and Wheelright (1978) summarize the general its use to determine complex forecasts concerning multiple
complaints against the Delphi method in terms of (a) a low factors. Such complex model building is more appropriate for
level reliability of judgements among experts and therefore quantitative models with Delphi results serving as inputs
dependency of forecasts on the particular judges selected; (b) (Gatewood and Gatewood, 1983). This point is supported by
the sensitivity of results to ambiguity in the questionnaire that Gordon and Hayward (1968) who claim that the Delphi
is used for data collection in each round; and (c) the difficulty in method, based on the collation of expert judgement, suffers
assessing the degree of expertise incorporated into the forecast. from the possibility that reactions between forecasted items
Martino (1978) lists major concerns about the Delphi method: may not be fully considered. The need for the cross impact
• Discounting the future: Future (and past) happenings are not matrix method of forecasting integrated with the Delphi
as important as the current ones, therefore one may have a method is pointed out by many researchers (Gordon and
tendency to discount the future events. Hayward, 1968; Gatewood and Gatewood, 1983; Adler and
• The simplification urge: Experts tend to judge the future of Ziglio, 1996). An improvement in forecasting reliability over
events in isolation from other developments. A holistic view the Delphi method was thought to be attainable by taking into
of future events where change has had a pervasive influence consideration the possibility that the occurrence of one event
cannot be visualized easily. At this point cross-impact analysis may cause an increase or decrease in the probability of occurrence
is of some help. of other events included in the survey (Helmer, 1978). Therefore
cross impact analysis has developed as an extension of Delphi
• Illusory expertise: some of the experts may be poor forecasters. techniques.
The expert tends to be a specialist and thus views the forecast
in a setting which is not the most appropriate one. Review
• Sloppy execution: there are many ways to do a poor job.
Execution of the Delphi process may loose the required Brainstroming
attention easily. Delphi method
• Format bias: it should be recognized that the format of the
questionnaire may be unsuitable to some potential societal
participants.
• Manipulation of Delphi: The responses can be altered by the
monitors in the hope of moving the next round responses in
a desired direction.

119
 Questions Notes
SYSTEMS ANALYSIS

1. Explain about brainstorming with an example.

Describe about the history about Delphi method

References
Hoffer, Jeffrey A.
Modern systems analysis and design
2nd ed. Delhi : Pearson Education Asia, 2000

Sarkar, A.K.
Systems analysis, data processing and
quantitative techniques
New Delhi : Galgotia Publications, 1997
Hawryszkiewycz, Igor
Introduction to systems analysis & design
4th ed. New Delhi : Prentice Hall of India, 2002
Awad, Elias M.
Systems analysis and design
New Delhi : Galgotia Publications, 1997
Heuring, Vincent P.
Computer systems design and architecture
Delhi : Pearson Education Asia, 1997
Whitten, Jeffrey L.
Systems analysis and design methods
5th ed. New Delhi : Galgotia Publications, 2001
Shelly, Gary B.
Systems analysis and design
3rd ed. New Delhi : Galgotia Publications, 1999
Website Addresses
www.scit.wlv.ac.uk
www.privcom.gc.ca
www.conferences.global-investor.com
www.umsl.edu

120
 LESSON 24 :

SYSTEMS ANALYSIS
FLOW DIAGRAMS

Topics covered 0038 else

• Flow Graph 0039 if CurrentGuessSquared >= Number then
0040 MaximumValue := CurrentGuess;
• Produce Flow Graph 0041 else
Objectives 0042 MinimumValue := CurrentGuess;
Upon completion of this Lesson, you should be able to: 0043 end if;
0044 end if;
• Create flow graph for the given problem
0045 end loop;
Flowgraph analysis 0046 return CurrentGuess;
• A flowgraph analysis is concerned with statically determining 0047 end SquareRoot;
the number of different paths by which flow of control can • The first stage in constructing a flowgraph is to note that at
pass through an algorithm. some stage flow of control will enter the subprogram and will
• It can be argued that a developer or maintainer must be able to at some stage leave the subprogram. This produces an initial
conceptualise the flow of control through an algorithm in flowgraph as follows.
order to fully understand its dynamic behaviour.
• Unless such an understanding is available the developer will
not be able to fully predict the dynamic behaviour of the
software and thus will not be able to ensure that all possible
contingencies are allowed for in its design or implementation.
Producing a simple flowgraph
Although a flowgraph analysis can be made at the design stage
this lesson will concentrate upon the production of flowgraphs
from source code, as this is a pre-requisite for the technique of
white box testing.
0014 function SquareRoot( Number : in FLOAT; • A flowgraph consists of a number of nodes, shown as circles
0015 Accuracy : in FLOAT) return FLOAT is containing identifying letters, connected by arcs which have
0016 arrows indicating the direction in which flow of control will
0017 MaximumValue : FLOAT; pass.
0018 MinimumValue : FLOAT; • The flowgraph above indicates that flow of control enters the
0019 CurrentGuess : FLOAT; subprogram at node a, flows through the arc and leaves at
0020 CurrentGuessSquared : FLOAT; node b. The construction of the flowgraph continues by refining
0021 CurrentError : FLOAT; the flow of control within the subprogram, between points a
0022 CloseEnough : BOOLEAN := FALSE; and b.
0023
• Refinement proceeds by dividing the implementation into parts
0024 begin — SquareRoot
where flow of control has a single entry and exit point. In the
0025 if Number > 1.0 then
SquareRoot function there is a sequence of four parts.
0026 MaximumValue := Number;
0027 MinimumValue := 0.0; The first part comprises the declaration and initialisation of the
0028 else local variables between lines 0017 and 0024, the second comprises
0029 MaximumValue := 1.0; the if structure between lines 0025 and 0031, the third is the while
0030 MinimumValue := Number; loop between lines 0032 and 0045 and the last is the single return
0031 end if; statement on line 0046. The flowgraph can be refined to reflect
0032 while not CloseEnough loop these three regions of code, producing the following flowgraph.
0033 CurrentGuess := (MaximumValue +
MinimumValue) / 2.0;
0034 CurrentGuessSquared := CurrentGuess *
CurrentGuess;
0035 CurrentError := abs( Number+
CurrentGuessSquared);
0036 if CurrentError <= Accuracy then
0037 CloseEnough := TRUE;

121
SYSTEMS ANALYSIS
structures, for example an elsif structure or a case structure of
the following forms, a more complex flowgraph would be
required.
• — Three way elseif structure — Three way case structure
• If FirstCondition then case SelectionValue is
• — First actions. when => FirstValueList
• Elsif SecondCondition then — First actions.
• — Second actions. when=> SecondValueList
• Else — Second actions.
• — Third actions. when others =>
• End if; — Third actions
• End case;

• The four parts where flow of control enters and leaves are
shown between nodes a and c, c and d, d and e and between e
and b.
• The first and last of these arcs require no further refinement as
they represent regions where simple sequences of instructions, • Additional elsif options or case options in the sequential
within which flow of control moves sequentially from selection structures will cause additional arcs connecting the
instruction to instruction. two nodes to be added. Inserting a two way selection flowgraph
• The second arc requires further refinement which can proceed into the SquareRoot flowchart to represent the two way if
by substituting the standard two way flowgraph for the arc structure between lines 0025 and 0031, will produce the
between c and d. The standard two way flowgraph is as follows. following flowgraph.

• Flow of control enters the flowgraph at node s and leaves at

node t, following one of the two arcs connecting the nodes.
• This flowchart can be used to represent flow of control through
if statements of the following forms.
— One way if structure — Two way if structure
if Condition then if Condition then • Refinement continues with the arc between nodes d and e
— Actions. — First actions. which represent the while loop in the implementation. The
end if; else standard loop flowgraph is as follows.
— Second actions.
end if;
• For the one way if structure flow of control can cause the
Actions to either be performed or omitted. For the two way if
structure flow of control can cause either First actions or Second
actions to be performed.
• The two possible flows of control are represented by the two
arcs connecting the nodes. For more complex sequential selection
• Flow of control can pass straight from node l to node m
122 without following the circular arc back to the node.
• This would be the case for a while loop if the first time the • The arc between d and f represents a sequence of simple

SYSTEMS ANALYSIS
condition controlling the loop was tested, it evaluated false. If instructions and requires no further refinement, the arc between
a for loop was being represented then flow of control would f and d represents the nested if statement which will have to
avoid the circular route if the loop conditions were such that be refined in two stages.
the body of the loop was not executed. • The first stage of refinement will substitute a standard two
• The circular route represents the body of the loop and in way selection flowgraph to represent the outermost if,
circumstances where flow of control enters the loop body a producing the following flowgraph.
representation of flow of control would indicate that node l
was visited more than once indicating that the circular arc was
followed. Inserting the standard loop flowgraph into the
SquareRoot flowchart produces the following refinement.

• The construction of the flowgraph continues by the refinement

of the body of the loop. The first refinement would divide it
• The final refinement will replace one of the arcs between f and
d with a two way flowgraph to represent the two way if structure
into a sequence of two parts, the first is the sequence of
on lines 0039 to 0043.
statements between lines 0026 and 0028.
• The second part is the nested if statements between lines 0029 • The final, completely refined, flowchart for the SquareRoot
and 0037. Substituting a flowgraph representing a sequence of function is as follows.
two parts into the arc which represents the body of the loop
produces the following flowgraph.

Flowgraph complexity analysis

• The complete flowgraph which has been produced by successive
refinement from the source code now indicates all the possible

123
 • The situation where there are as many arcs as nodes produces
SYSTEMS ANALYSIS

paths by which flow of control can pass through the SquareRoot

function. flowgraphs such as the two right hand graphs above where
one arc must either duplicate an existing connection between
• In its current state it provides a simple pictorial representation
two nodes or define a loop arc connecting a node to itself. In
of the dynamic complexity of the subprogram, which can be
both cases the additional arc has changed the topology of the
compared visually with other flowgraphs to compare the relative
graph by defining a region within the graph.
complexity of two or more subprograms.
• A more satisfactory approach to deriving a measure of • It can be shown that for every additional arc above the number
of nodes another closed region is added to the graph. The
complexity from a flowgraph would require some measurement
following sequence of flowgraphs illustrate that adding arcs
of the graph.
increases the number of regions.
• The most obvious measurement might be to count the number
of nodes and the number of arcs. In the final SquareRoot
flowgraph above there are 8 nodes and 10 arcs. Each node
represents a location within the software where a simple
sequential flow of control joins with another simple sequential
flow of control and each arc represents the flow of control
through a simple sequence.
• Although a count of the number of arcs and nodes gives
some indication of the complexity of a flowgraph, the real
indication of the software’s complexity is in the topological
relationship of the nodes and arcs.
• The topology of a graph is the number of non connected areas
on the graph, each non-connected area is known as a region
and number of regions is independent of the precise way in
which the graph is laid out.
• The following three flowcharts have a similar number of nodes
and arcs, but the two right hand flowcharts intuitively have a • Thus the number of regions in a flowgraph is the most
greater complexity than the left hand chart as they have a greater important indicator of complexity and can be derived either by
number of regions. counting the number of regions on the flowgraph, including
the external region in the count.
• Alternatively the number of nodes and arcs can be counted
and the number of regions decided by using the formula
regions = arcs - nodes + 2
• This measure of the complexity of an algorithm, the number
of regions in its flowgraph, is known as McCabes complexity
metric.
• Although this technique established a metric for the complexity
of an algorithm, it does not give any indication of the
appropriate complexity which should be aimed for. Cognitive
psychologists have determined that a human is only capable of
maintaining and manipulating cognitive models which contain
seven plus or minus two, i.e. between five and nine, cognitive
chunks of information.
• Assuming that a region on a flowgraph is equivalent to a
cognitive chunk then it can be concluded that subprograms
should not be constructed which contain more than a maximum
of about nine regions and preferably should be limited to less
• The left hand flowgraph has four nodes and three arcs, the than seven.
middle four nodes and four arcs and the right hand flowgraph
three nodes and three arcs. Review
• The relationship between the number of arcs and the number Flow Graph Analysis
of nodes is significant. Where a flowgraph has one fewer arcs Producing Flow Graph
than nodes it can be argued that every arc must connect one Flowgraph complexity analysis
node with another node, without any two nodes being
connected by more than one arc. This will produce a flowgraph Questions
consisting of a single region, as shown on the left hand Discuss about Flow graph analysis
flowgraph above. 1
• Continuing the argument it can be shown that there can never
124be less than this number of arcs as this would result in some
nodes being unconnected with the rest of the flowgraph.
2 New Delhi : Galgotia Publications, 1997

SYSTEMS ANALYSIS
3 Notes
4
5
Produce a flow graph for a sequence of code of your own choice.
1
2
3
4

References:
Heuring, Vincent P.
Computer systems design and architecture
Delhi : Pearson Education Asia, 1997
Whitten, Jeffrey L.
Systems analysis and design methods
5th ed. New Delhi : Galgotia Publications, 2001
Shelly, Gary B.
Systems analysis and design
3rd ed. New Delhi : Galgotia Publications, 1999
Bennett, Simon
Object-oriented systems analysis and
Design using UML
2nd ed. New Delhi : McGraw Hill Book, 2002
Booch, Grady
Object-oriented analysis and
design : with applications
2nd ed. Reading : Addison-Wesley Publishing, 2000
Hoffer, Jeffrey A.
Modern systems analysis and design
2nd ed. Delhi : Pearson Education Asia, 2000
Kain, Richard Y.
Advanced computer architecture :
A systems design approch
New Delhi : Prentice Hall of India, 1996
Sima, Dezso
Advanced computer architectures :
A design space approch
Delhi : Pearson Education Asia, 1997
Sarkar, A.K.
Systems analysis, data processing and
quantitative techniques
New Delhi : Galgotia Publications, 1997
Hawryszkiewycz, Igor
Introduction to systems analysis & design
4th ed. New Delhi : Prentice Hall of India, 2002
Awad, Elias M.
Systems analysis and design

125
SYSTEMS ANALYSIS

LESSON 25 :
STANDARD DOCUMENTATION TECHNIQUE

Topics covered ==> results (= inputs & outputs): documents

• Standard documentationTechnique ð verify transformations at milestones
Objectives Documentation
Upon completion of this Lesson, you should be able to: ==> supported by standards
• Explain about Standard Documentation. • Internal technical documentation:

SOFTWARE LIFE-CYCLES – The results of each phase

Elements and Definitions – The rationale and assumptions behind the decisions
Made in each phase
LifeCycle
– Layouts and results of tests
ANSI / IEEE Std 729-1983
– Error & fixes log
• A life-cycle is
• External technical documentation:
– a period of time that
– System structure
– starts when a software product is conceived and
– Required environment
– ends when the product is no longer available for use.
– Instructions for installation
• Organised in phases
– Maintenance & operation
– Guidelines for trouble shooting
• End-user documentation:
2
– User handbook
– Quick reference
Requirements
– Guided tour
The – Standard set-up
System Design
WATERFALL Milestone
LIFE-CYCLE • A scheduled event
Detailed Design
– For which some project member or manager is
Accountable and
Implementation – That is used to measure progress.
• Supported by standards
Installation & Testing Standards
•Project independent
Maintenance –rules and procedures
–embedded in a common system of terms
–and quality criteria
–that ensure inter-project adaptability
Phases of a Life-Cycle
–and compatibility of solutions.
• Requirements
•Important organisations: ANSI, IEEE
• System Design
• Detailed Design
• Implementation
• Testing & Installation
• Operations & Maintenance
• Retirement

126
 The Communication Process and Public

SYSTEMS ANALYSIS
Speaking
14 Milestones • By focusing on the process of communication and the rhetorical
The
situation, a speaker can maximize the effectiveness of messages.
Requirements WATERFALL
• This means that an effective speaker doesn’t “write” a speech in
LIFE-CYCLE isolation and then simply stand up and deliver it. Instead, an
System Design
effective speaker develops messages in relation to the situation,
Standards the audience, and the communication goals.
Detailed Design
• Throughout the semester we will go into more detail about
how to do this, but for now it is important to understand the
Implementation following:
What the sender intends to communicate is not
Installation & Testing
always what the receiver decodes.
Documents
Maintenance • The communication process can break down in any number of
ways, and an effective speaker should not take the audience’s
understanding of messages for granted.
• An effective speaker makes sure to learn all that is possible
Introduction to the Communication about the audience and to adapt the message to that audience.
Process “Actions speak louder than words.”
Ø In its most basic form, communicating involves a sender who Non-verbal messages are usually believed more than verbal
takes his/her thoughts and encodes them into verbal and messages.
nonverbal messages that are sent to a receiver. • When there is a conflict between nonverbal and verbal messages,
Ø The receiver then decodes the messages and attempts to the audience tends to believe the nonverbal. An effective public
understand what the sender meant to communicate. speaker makes sure that the nonverbal messages compliment
and strengthen the verbal messages.
Ø The communication process is completed when the receiver
transmits verbal and nonverbal feedback to indicate his/her More Communication does not Equal
reception and understanding of the message. Better Communication.
Ø This process takes place within a context, also known as a • What’s the use of more communication if it is ineffective or
rhetorical situation, which includes all that affects the bad communication? An effective public speaker focuses on
communication process such as the sender-receiver’s culture, the quality of communication, not the quantity.
the sender-receiver’s relationship, the circumstances surrounding Becoming an Effective Listener
the sender-receiver’s interaction, and the physical environment • Listening is a vital skill, not only for this class but for life in
of the interaction. general. Becoming an effective communicator starts with
Ø Because the basic communication process is the same in every becoming a better listener.
situation, there are some similarities across all types of • The main thing to remember is that hearing does not equal
interactions. Just the same, each interaction remains distinct listening. Hearing is a physiological process that involves the
and therefore each rhetorical situation will be different. reception of vibrations by the delicate structures within our
Ø For example, think about how you communicate with another ears.
person in the library and at a party. • Listening is a psychological process that involves the
Ø In both cases you are sending messages and reacting to feedback. interpretation of what we hear. Hearing is passive—it take no
Ø But the the rhetorical situation of the library means that you effort on our part, while listening is active—it take effort and a
will be speaking in whispers, whereas at the party you will be willingness to tune in.
speaking much louder and with more animated gestures. • One of the most important parts of public speaking is learning
Ø If you were to switch styles—whispering at the party and yelling how to listen to or read your audience.
at the library—then your communication style would be • This means being able to observe and to utilize the feedback
ineffective to say the least. In both situations you are engaging from the audience. Being a good listener also helps in the
in the same communication process, but the rhetorical situations development of your speech because it allows you to gain
require you to act in different ways. skills in analyzing messages and retaining information.
• So how do you start improving your listening skills? The key is
to actively focus on your listening behavior, and to start
eliminating behaviors that lead to poor listening. These negative
behaviors include:

127
 · Mentally jumping to conclusions before the other person has
SYSTEMS ANALYSIS

2nd ed. Reading : Addison-Wesley Publishing, 2000

finished speaking.
Hoffer, Jeffrey A.
· Focusing on how the person communicates rather than what is Modern systems analysis and design
being communicated.
2nd ed. Delhi : Pearson Education Asia, 2000
· Starting to think of a response before the other person has
Kain, Richard Y.
finished a thought.
Advanced computer architecture :
· Being aware of such behaviors, and actively trying to eliminate A systems design approch
them is a major step toward being a more effective
New Delhi : Prentice Hall of India, 1996
communicator.
Sima, Dezso
Review
Standard documentation Advanced computer architectures :
A Design space approch
System Life cycle
Becoming an effective public speaker starts with an understanding Delhi : Pearson Education Asia, 1997
of the communication process and the listening process. Even Sarkar, A.K.
though the process of communicating is similar in all interactions, Systems analysis, data processing and
each specific situation will require you to make several choices Quantitative techniques
about how to get your message across.
New Delhi : Galgotia Publications, 1997
Questions Hawryszkiewycz, Igor
Describe about the communication process. Introduction to systems analysis & design
1 4th ed. New Delhi : Prentice Hall of India, 2002
2 Awad, Elias M.
3
Systems analysis and design
4 New Delhi : Galgotia Publications, 1997
5

Relate the SDLC with dcumentation.

1
2
3
4
5

References0
Heuring, Vincent P.
Computer systems design and architecture
Delhi : Pearson Education Asia, 1997
Whitten, Jeffrey L.
Systems analysis and design methods
5th ed. New Delhi : Galgotia Publications, 2001
Shelly, Gary B.
Systems analysis and design
3rd ed. New Delhi : Galgotia Publications, 1999
Bennett, Simon
Object-oriented systems analysis and
Design using UML
2nd ed. New Delhi : McGraw Hill Book, 2002
Booch, Grady
Object-oriented analysis and
Design : with applications

128
 CHAPTER III
LESSON 26 : SYSTEM INVESTIGATION
OVERVIEW DATA AND FUNCTIONAL
MODELLING

SYSTEMS ANALYSIS
Topics covered which is accepted because of its strong points over other
• Overview of data and functional modelling traditional approaches.

OBJECTIVES The structural system analysis has the following

main characteristics:
Upon completion of this Lesson, you should be able to:
• Function diagram
• The system is developed in the top - down order;
• During system analysis and design, several tools, techniques
• DFD
and models are used to record and analyze the current system
Overview of functional and data and new requirements of users, and define a format for the
modelling future system;
• This deals with techniques applied in information system • The major tools used in structural system analysis include:
analysis, data modeling and normalization. function diagram, data flow diagram, data dictionary, process
• This Lesson shows a process of providing full specification of specification, Entity-Relationship diagram;
systems to users to help them consider and accept. • Separation between physical model ad logical model. A physical
• This specification is also a major information source for model is often used in surveying the current system and
designers of the new system. designing the new system while a logical model is used in
• It not only specifies the system’s objectives but also describes analyzing system’s requirements. This is a significant advantage
the work and its constraints to which designers have to comply. brought about by the structural system analysis method;
• Acknowledging users’ role in different steps of system
Analysis of structured system development;
• This part discusses the process of system analysis, analysis • Different steps in structural analysis and designing can be carried
methods and tools supporting the analysis of data collected in
out at the same time rather than in one by one order. Each step
previous surveys.
can improve the analysis and designing made in a previous
Overview of system analysis step;
• System analysis is a relatively young field in mankind’s • Structural analysis is supported by advanced technology in both
knowledge but demand for system analysis existed many hardware and software, therefore system development with
centuries before the introduction of computers. this method is less complicated;
• In mid 19 century, practitioners in labor, organization and • Structural analysis when put together with the prototype
methodology had established many improved methods of method can help users and analysts have an idea of the new
working. system and help make best use of both methods.
• This is the first approach to system analysis. Two models of structural system analysis
• With the development of information technology, system Waterfall Model
analysis science also develops more and more vigorously and
has a significant role in a life cycle of an IT application and of • Has been a basis for a majority of structural system analysis
IT projects in general. methods since the 1970s. This model consists of different
phases carried out one after the other. Each phase can be assigned
• At the moment, there is no method that ensures success and to a group of experts.
that can be viewed as a “right” way for analysis but the
application of structured system analysis increases the chance Spiral model
of success for most of typical applications and it proves efficient • Initiated by Barry Boehm, has become more and more popular
in a range of analysis in real life. and a basis to iterative development systems.
• Until today, system approach is still viewed as a sound • This approach also consists of various phases carried out one
foundation for structured system analysis. after the other as in the Waterfall model.
• Structural system analysis is a modern approach to different • However, the system development process is divided into
analysis and design phrases of the system development process different steps and smoothened after repetitive steps, the system
becomes more perfect after each repetitive steps.

129
 • In this model, system developer can hand system’s functions • For users, what they care about is what functions the program
SYSTEMS ANALYSIS

over to users more frequently rather than giving them all the can perform if it meets the professional need dictated by the
functions at the end of the development process. system, if its reliability is prove while testing with real figures,
if the interface is users-friendly.
Nature of analysis
• Analysis is the focus of system developing and is the stage • Analysis plays a very important part in the life cycle of the
system because this activity relates to almost all other activities
when system designers have to work at two levels of definition
and all subjects participated in the system.
regarding the study of situational issues and possible solutions
in terms of “what to do” and “how to do”. Role and requirement of system analysts
System analysis process in its most general form • The system analyst is a key member of any systems
includes the following main step: development project. In a broader sense, the systems analyst
plays several roles:
• Identify the operation of the existing system;
• Understand what the existing system is doing;
• Archaeologist and scribe: As a systems analyst, one of the main
jobs is to uncover detail and to document business policy that
• Understand the need of the users; may exist only as “tribal folklore”, passed down from
• Decide on what the new system should be doing; generation to generation of users.
• Decide on how the new system will function. • Innovator: The systems analyst must separate the symptoms
• In the process of system analysis, it is not always possible to of the user’s problem from the true causes. With his or her
study every aspect of each of the above steps and this is the knowledge of computer technology, the analyst must help the
time to pay attention to the following: user explore useful, new applications of computers.
• If the method of working applied to participants of system • Mediator: The system analyst who often finds himself in the
development (users, analysts, designers, and programmers) is middle of users, managers, programmers, auditors and various
efficient? other players, all of whom frequently disagree with one another.
• If the update of changes that happen in the process of system • Project leader: Because the systems analyst is usually more
development is touched upon; experienced than the programmers on the project and since he
• Tool for analysis; is assigned to the project before the programmers begin
working, there is a natural tendency to assign project
• If workload allocation is reasonable? (Users have to take part management responsibilities to analyst.
in 2 systems (old and new) at the same time);
• If documents are easy to understand to all participants? This Means that, as a Systems Analyst,
you Need
Importance of analysis in system’s life cycle • More than just the ability to draw flowchart and other technical
• A system’s analysis and development life cycle include the diagrams;
following tasks: survey, analysis, design, implementation, • Skills to interview users, mediate disagreements;
system testing and approving, installation and maintenance.
• Application knowledge to understand and appreciate the user’s
• Main subjects in the whole life cycle of the system are: users, business;
mangers and technical experts including analysis, design and
program specialist...) • Computer skills to understand the potential uses of computer
hardware and software in the user’s business;
• The primary purpose of the analysis activity is to transform its
two major inputs, users policy and system charter, into • Able to view a system from many different perspectives;
structured specification. This involves modeling the users’ • Able to partition it into levels of subsystems;
environment with functioning diagrams, data diagrams, entity- • Able to think of a system in abstract terms as well as physical
relationship diagrams and the other tools of the system analysis. terms.
• The quality of system analysis can have a big effect on speed of Popular methods of system analysis
system designing, the programming and time for testing because
• In the following presentation, you will be introduced to using
50 per cent of faults in the system originated from shortcomings
a range of tools and techniques that enable analysts to have a
in system analysis.
better understanding and to find a solution for every single
• Programmers can complain about slow speed of work because case of application.
they have to review analysis and designing.
• The usage of tools and techniques forms an approach named
• This shows the bad quality of system analysts (because of structure system analysis.
inadequate experience or improper working attitude).
• Structure system analysis originated from observations that
• Moreover, speed of system analysis activities is also a very principles of structure programming can also applied to analysis
important issues because there are always complaints about and designing stage.
time, etc. And the products of the system analysts are often
specification description and diagrams of technical nature and The moving towards structure system analysis can
these are not highly valued. be explained by the following description:

130
Graphic: composed of variety of diagrams, supported by detailed In the current example, the function hierarchy

SYSTEMS ANALYSIS
textual material that, in many cases, serves as reference material diagram is as follows
rather than the main body of the specification.
Partitioned: so that individual portions of the specification can be
read independently of other piece.
Minimally redundant: so that changes in the user requirements
can usually be incorporated in just one part of the specification.
This approach is now used in the majority of systems development
organizations, as well as a large number of engineering-oriented
organizations.
Tools supporting analysis: Functioning diagram, data flow
diagram, and relationship diagram...
• In the process of system analysis, analysts often construct
models to give an overview or stress on aspects of the whole
system. This enables analyst to contact users in the best way
and when users’ need is changed, it is possible to modify or
construct a new model.
Analysts use model to
• Concentrate on important features of the system, pay less
attention to less important ones;
• Be able to respond to changes or changes in user’s requirements
with low cost and risk;
• Properly understand users’ environment and write documents Data flow Diagram
Describe the information flow in the system The next step of
in the same way that designers and programmers construct the
system analysis is to consider in detail the information necessary
system.
for the implementation of functions discussed above and the
Three important modeling tools used in one necessary for the improvement of the functions. Modeling
system analysis is tool frequently used for this purpose is data flow diagrams.
Functional diagram (FD) Data flow diagram will support 4 main activities
• A functional diagram is used to show system’s functions that • Analysis: DFD is used to determine requirements of users.
will be constructed and the implementation process of data • Design: DFD is used to map out plan and illustrate solutions
diagram. Moreover, function diagram will also be used to to analysts and users while designing a new system.
determine the appearance frequency of smaller process in the
data flow chart. • Communication: One of the strength of DFD is its simplicity
and ease to understand to analysts and users;
• If during the construction of functional diagram, analysts
identify new functions, the analysts need to determine if it is a • Documents: DFD is used to provide special description of
wrong move to ignore the discovered functions. It is necessary requirements and system design. DFD provide an overview of
to decide to add or remove in the most appropriate way. key functional components of the system but it does not
provide any detail on these components. We have to use other
• Functional analysis with the help of modeling tools provides tools like database dictionary, process specification to get an
important details that will be used often in later stages of idea of which information will be exchanged and how.
analysis.
The data dictionary is an organized listing of all the data elements
• With detailed job description, information processing and pertinent to the system, with precise, rigorous definitions so that
exchanging process, input and output of every function will both user and systems analyst will have a common understanding
help analysts understand more clearly system’s requirements. of all inputs, outputs, components of stores, and intermediate
• However, it is necessary to note that function approach to issue calculations.
is not a comprehensive approach.
The data dictionary defines the data elements by doing the
• A function diagram only shows what to do not how to do. In followings
a functional diagram, a function is divided into many smaller
• Describing the meaning of the flows and stores shown in the
functions and each smaller function contains many even smaller
data flow diagrams;
ones.
• Describing the composition of aggregate packets of data
Constructing diagram is a process of division, from a higher
moving along the flow;
function to appropriate smaller functions. Diagrams need to be
presented clearly, simply, exactly, and fully and balanced. Function • Describing the composition of packets of data in stores;
of the same level has the same level of difficulty need to be on the
same page.

131
 • Where does the system get information from to work?
SYSTEMS ANALYSIS
• Specifying the relevant values and units of elementary chunks
of information in the data flows and data stores. • And where does it give work results to?
• Describing the details of relationships between stores that are Regardless of the ways it is described, the data flow
highlighted in an entity-relationship diagram. diagram needs to meet the following
The system analysis can ensure that the dictionary is complete, requirements:
consistent, and non-contradictory. He can examine the dictionary • Without explanation in words, the diagram can still tell the
on his own and ask the following questions: system’s functions and its information flowing process.
• Has every flow on the data flow diagram been defined in the Moreover, it must be really simple for users and systems analysts
data dictionary? to understand.
• Have all the components of composite data elements been • The diagram must be balancely laid out in one page (for small
defined? systems) and in every single page showing system’s functions
• Has any data element been defined more than once? of the same level (for larger systems).
• Has the correct notation been used for all data dictionary It is best for the diagram to be laid out with computer supporting
definition? tools, because that way the diagram will be consistent and
• Are there any data elements in the data dictionary that are not standardized. Also, the adjustment process (when needed) will be
referenced in the functioning diagrams, data flow diagrams, or done quickly and easily.
entity-relationship diagrams. Review
Building a data dictionary is one of the more important aspects Role of AnalystPopular method of system analysis
and time consuming of systems analysis. But, without a formal Data Flow diagram
dictionary that defines the meaning of all the terms, there can be
Functional diagram, Data dictionary
no hope for precision.
The process specification Questions
Discuss about Data Flow diagram
As we know, there are a variety of tools that we can use to produce
a process specification: 1
Decision tables, structured English, pre/post conditions, 2
flowcharts, and so on. All most systems analysts use structured
3
English. But, any method can be used as long as it satisfies two
4
important requirements:
• The process specification must be expressed in a form that can 5
be verified by the user and the systems analysts;
Produce a Functional diagram with a real system
• The process specification must be expressed in a form that can
be effectively communicated to the various audiences involved. 1
The process specification represents the largest amount of detailed 2
work in building a system model. Because of the amount of 3
work involved, you may want to consider the top – down
4
implementation approach: begin the design and implementation
phase of your project before all the process specifications have 5
been finished.
The activity of writing process specifications regarded as a check of
the data flow diagrams that have already developed. In the writing
process specifications, you may discover that the process
specifications needs additional functions, input data flow or output
data flow...
Thus, the DFD model may be changed, revisions, and corrections
based on the detailed work of writing the process specifications.
Data flow diagram can be described in
the following ways
• What functions should the system perform?
• Interaction between functions?
• What does the system have to transfer?
• What inputs are transferred to what outputs?
• What type of work does the system do?

132
References:

SYSTEMS ANALYSIS
Heuring, Vincent P.
Computer systems design and architecture
Delhi : Pearson Education Asia, 1997
Whitten, Jeffrey L.
Systems analysis and design methods
5th ed. New Delhi : Galgotia Publications, 2001
Shelly, Gary B.
Systems analysis and design
3rd ed. New Delhi : Galgotia Publications, 1999
Bennett, Simon
Object-oriented systems analysis and
Design using UML
2nd ed. New Delhi : McGraw Hill Book, 2002
Booch, Grady
Object-oriented analysis and
Design : with applications
2nd ed. Reading : Addison-Wesley Publishing, 2000
Hoffer, Jeffrey A.
Modern systems analysis and design
2nd ed. Delhi : Pearson Education Asia, 2000
Kain, Richard Y.
Advanced computer architecture :
A systems design approch
New Delhi : Prentice Hall of India, 1996
Sima, Dezso
Advanced computer architectures :
A design space approch
Delhi : Pearson Education Asia, 1997
Sarkar, A.K.
Systems analysis, data processing and
quantitative techniques
New Delhi : Galgotia Publications, 1997
Hawryszkiewycz, Igor
Introduction to systems analysis & design
4th ed. New Delhi : Prentice Hall of India, 2002
Awad, Elias M.
Systems analysis and design
New Delhi : Galgotia Publications, 1997
Notes

133
SYSTEMS ANALYSIS

LESSON 27 :
DATA FLOW DIAGRAM

Topics covered
• Data Flow Diagram
Objectives
Upon completion of this Lesson, you should be able to:
• Discuss the various notation used in the DFD
The main components of data flow
diagram are
• The process: The process shows a part of the system that
transforms inputs into outputs; that is, it shows how one or
more inputs are changed into outputs. Generally, the process is
represented graphically as a circle or rectangle with rounded edges.
The process name will describe what the process does.
• The flow: The flow is used to describe the movement of
information from one part of the system to another. Thus,
the flow represents data in motion, whereas the stores represent
data at rest. An arrow into or out of a process represents a flow
graphically.
• The store: the store is used to model a collection of data packets
at rest. Two parallel lines represent a store graphically. The name
of a store identified the store is the plural of the name of the A data flow diagram
packets that are carried by flows into and out of the store. Data Flow Diagram Notations
• External factors: External factors can be a person, a group of
You can use two different types of notations on your data flow
persons or an organization that are not under the studying
diagrams:
field of the system (they can stay in or out of the organization),
but has certain contact with the system. The presence of these Yourdon & Coad or Gane & Sarson.
factors on the diagram shows the limit of the system and Process Notations
identifies the system relationship to the outside world. External
factors are important components crucial to the survival of
every system, because they are sources of information for the
systems and are where system products are transferred to. An
external factor tends to be represented by an rectangle, one
shorter edge of which is omitted while the other is drawn by a Yourdon and Coad
duplicated line. Process Notations
• Internal factors: While the external factors’ names are always
Process
nouns showing a department or an organization, internal
A process transforms incoming
factors’ names are expressed by verbs or modifiers. Internal
data flow into
factors are systems’ functions or process. To distinguish itself
outgoing data flow.
from external factors, an internal factor is represented by an
rectangle, one shorter edge of which is omitted while the other Gane and Sarson
is drawn by a single line. Process Notation
Datastore Notations
You can construct DFD model of system
with the following guidelines
How to Draw Data Flow Diagrams (DFD)
What are Data Flow Diagrams?
Data flow diagrams illustrate how data is processed by a system in Yourdon and Coad
terms of inputs and outputs. Datastore Notation

134
 Discuss about various notation used in DFD

SYSTEMS ANALYSIS
DataStore
Datastores are repositories of 1
data in the system. They are
2
sometimes also referred to as
3
files.
4
5

1.Precision Tools sells a line of high quality woodworking tools.

Gane and Sarson
When customers place orders on the company’s website , the
Datastore Notations
system checks to see if the items are in stock, issues a atatus
Dataflow Notations Dataflow
message to the customer and generates a shipping order to the
Dataflows are pipelines through
warehouse, which fills the order. When the order is shipped ,
which packets of information flow.
the customer is billed. The system also produces various
Label the arrows with the name of
reports.
the data that moves through it.
(i) Draw a context diagram for the order system
(ii) Draw a DFD diagram 0 for the order system
(iii) Name four attributes that you can use to define a process in
the order system.
External Entity (iv) Name four attributes that you can use to define an entity in
External Entity Notations
External entities are objects the order system
outside the system, with Do you think DFD’s are more appropriate to the subject, usage
which the system communi- and system world?
cates. External entities are
sources and destinations of References
the system’s inputs and Heuring, Vincent P.
outputs. Computer systems design and architecture
Delhi : Pearson Education Asia, 1997
Whitten, Jeffrey L.
Systems analysis and design methods
• Choose meaningful names for processes, flows, stores, and 5th ed. New Delhi : Galgotia Publications, 2001
terminators
Shelly, Gary B.
• Number of processes Systems analysis and design
• Re-draw the DFD many times 3rd ed. New Delhi : Galgotia Publications, 1999
• Avoid overly complex DFD Bennett, Simon
• Make sure the DFD is consistent internally and with any Object-oriented systems analysis and
associated DFD Design using UML
To recap, DFD is one of the most important tools in a structured 2nd ed. New Delhi : McGraw Hill Book, 2002
system analysis. It presents a method of establishing relationship
Booch, Grady
between functions or processes of the system with information it
Object-oriented analysis and
uses. DFD is a key component of the system requirement
specification, because it determines what information is needed Design : with applications
for the process before it is implemented. 2nd ed. Reading : Addison-Wesley Publishing, 2000
Many systems analysts reckon that DFD is all they need to know Hoffer, Jeffrey A.
about structured analysis. On the one hand, this is because DFD Modern systems analysis and design
is the only thing that a systems analyst remembers after reading a 2nd ed. Delhi : Pearson Education Asia, 2000
book focussing on DFD or after a course in structured analysis.
Kain, Richard Y.
On the other hand, without the additional modeling tools such Advanced computer architecture :
as Data Dictionary, Process Specification, DFD not only can’t show
A systems design approch
all the necessary details, but also becomes meaningless and useless.
New Delhi : Prentice Hall of India, 1996
Review
Sima, Dezso
Data Flow Diagram Advanced computer architectures :
Questions A design space approch

135
 Delhi : Pearson Education Asia, 1997
SYSTEMS ANALYSIS

Sarkar, A.K.
Systems analysis, data processing and
Quantitative techniques
New Delhi : Galgotia Publications, 1997
Hawryszkiewycz, Igor
Introduction to systems analysis & design
4th ed. New Delhi : Prentice Hall of India, 2002
Awad, Elias M.
Systems analysis and design
New Delhi : Galgotia Publications, 1997
Notes

136
 LESSON 28 :

SYSTEMS ANALYSIS
DFD AND ER DIAGRAM

Topics covered
• Data Flow Diagram
• Entity Relationship Diagram
Objectives
Upon completion of this Lesson, you should be able to:
• Discuss the about ER Diagram
In the example of library management system, corresponding to
each level of function hierarchy diagram, we develop the data flow
diagrams:

137
 Summary A. A triangle-headed connection line displays this relationship.
SYSTEMS ANALYSIS

At the end of function analysis phase, we have 2 diagrams: the The non-triangle headed end shows to the table with one entity
function hierarchy diagram and the data flow diagram. They will and the other end shows the table with various entities.
be a basis for finding out entities and relationships between them Assume that we have 2 entities in table A and table B, a many -
(which is defined in the Entity-Relationship diagram). many relationship will exist between them if:
Entity-Relationship diagram (ERD) With each entity in table A, there are several entities in table B and
Though the relationship among data warehouse is not emphasized with each entity in table B, there are several entities in table A. A
in data flow diagram, it is well reflected in ERD. When developing connection line displays this relationship with triangle at both
a new information system, analyst often has discussion with users, ends.
especially database manager, on the current system. It’s they who In fact, the many - many relationship is often transferred to the
have the responsibilities to collect necessary information about one - many relationship via “connection entity” with 2 upper
the system required by system analyst. ERD is one of the most entities.
useful model forming tools to organize this discussion. ERD is
Thus, of the 3 types of relationships, the one - many relationship
network model that describes stored data of a system at a high
is the most important and popular because the one - one
level of abstraction. For system analyst, ERD has a major benefit:
relationship can be integrated in a table, the many - many
it highlights the relationship between data stores on DFD which
relationship is transferred to one - many relationship by creating a
would otherwise only be seen in the specification process.
“connection entity”, which facilitates the data modeling.
The main Components of an ERD Include In the example of library management system, we see the following
• Entity relationships:
• Attribute We realize that: one book or magazine (documents) must be
• Relationship belong to one language, but one language can have many books
Entity is a subject, a duty, or an event that has a significant meaning or magazines, so this relationship is one - to - many(one language
to the future system and is displayed by a rectangle with round has many documents).
corners. Each entity has its own name. In some cases, entities of The similar relationships are: documents and nation, documents
the same sort can be merged into one entity type. and collection, documents and specialty.
Entity type of a system is defined base on the outcome of system With the magazines: we realize that each magazine category has
function analysis. many volumes (depend on years, months, and numbers...), but
The simplest approach to decide whether a type of information one volume must be belong to one magazine category, so this
should be put in the model as a type of entity is to make up the relationship is one - to - many.
following question: Are these information tables useful for the The relationship between department and readers is also one -to
system? If the answer is yes, system analyst has to identify the - many relationships, because one reader must belong to one and
basic entities that create flows in the data table. only one department, but one department can have many readers
After a suitable type of entity, entity nature have been identified, (staffs).
the next important step is to define the information that needs to And the last relationship
be archived for each entity. the relationship between readers and documents: This is a special
• Attributes are the characteristics of the entity displayed by fields relationship: one reader can borrow many documents, and one
or columns of a table. document can be borrowed by many readers at different time
Relationship shows connections among the system’s entities. (because, when a reader gives back a document, it can be borrowed
Triangle headed arrows display these connections. by another reader again). So we can say that this relationship is
“many - to -many” relationship, and separate it into 2 “one - to -
There are 3 major Types of Relationship used in ERDs
many” relationships and one entity, the Borrowing/
• One - one relationship Returning_Ticket entity, with its primary key is the compose of
• One - many relationship the primary key of document entity, the primary key of reader
• Many - many relationship entity, and the BORROW_DATE attribute.
Let’s assume that we have 2 entities in tables A and table B, a one So we have the Entity-Relationship diagrams as
- one relationship will exist between them if: follow
With each entity in table A, there is a corresponding entity in table
B and vice versa, with each entity in table B, there is a corresponding
entity in table A. A normal connection line displays this
relationship.
Assume that we have 2 entities in table A and table B, a one -
many relationships will exist between them if:
With each entity in table A, there are several entities in table B and
with each entity in table B, there is one and only one entity in table

138
 an active list of over 100 books each identified by a universal code

SYSTEMS ANALYSIS
called an ISBN number.
(i) Draw an ERD for the Top Text information system
(ii) Indicate cardinality
FastFlight Airlines is a small air carrier operating in three
northeastern states. FastFlight is the process of computerizing its
passenger reservation system. The following data were identified:
reservation number, flight number, flight date, origin, destination,
departure time, arrival time, passenger name and seat number.
(i) Create an ERD, including cardinality for the reservation system.
References
Heuring, Vincent P.
Computer systems design and architecture
Delhi : Pearson Education Asia, 1997
Whitten, Jeffrey L.
Systems analysis and design methods
5th ed. New Delhi : Galgotia Publications, 2001
Shelly, Gary B.
Systems analysis and design
3rd ed. New Delhi : Galgotia Publications, 1999
Bennett, Simon
Object-oriented systems analysis and design using
UML
2nd ed. New Delhi : McGraw Hill Book, 2002
Booch, Grady
Object-oriented analysis and design : with
applications
2nd ed. Reading : Addison-Wesley Publishing, 2000
Hoffer, Jeffrey A.
Modern systems analysis and design
2nd ed. Delhi : Pearson Education Asia, 2000
Kain, Richard Y.
Advanced computer architecture : a systems design
approch
New Delhi : Prentice Hall of India, 1996
Sima, Dezso
Advanced computer architectures : a design space
Mayille is a rural village with a population of 500. Until now approch
Mayville was served by a bookmobile from a larger town. The
Delhi : Pearson Education Asia, 1997
Mayville village council has authorized funds for a small public
library and you have volunteered to set up an information system Sarkar, A.K.
for the library. Assume that the library will have multiple copies Systems analysis, data processing and quantitative
of certain books. techniques
(i) Draw an ERD for the Mayille library system New Delhi : Galgotia Publications, 1997
(ii) Indicate cardinality. Hawryszkiewycz, Igor
Top Text Publishing is a textbook publishing company with a Introduction to systems analysis & design
headquarters location, a warehouse and three sales offices that 4th ed. New Delhi : Prentice Hall of India, 2002
each have a sales offices that each have sales manager and sales
Awad, Elias M.
reps. Top Text sells to schools, colleges and individual customers.
Many authors write more than one book for Top text and some Systems analysis and design
books are written by more than one author. Top text maintains New Delhi : Galgotia Publications, 1997

139
SYSTEMS ANALYSIS

LESSON 29 :
OVERVIEW DATA MODELLING

Topics covered relationships and then drawing a diagram that accurately depicts
• Data modelling the system. This applies equally to the design of a new system or
the analysis of an existing one.
Objectives The end result of data modeling should be a clear picture of how
Upon completion of this Lesson, you should be able to: information is stored and related within a proposed, or existing,
• Discuss the about data modelling system.
Data Modelling Systems Analysis Entities
• What is systems modeling and what is the difference between On this we illustrate the concept of an entity, which can be applied
logical and physical system models? to almost anything that is significant to the system being studied.
Some examples of information systems and entities are listed
• What is data modeling and what are its benefits? below:
• Can you recognize and understand the basic concepts and Airline system: Aircraft, Passenger, Flight, Airport.
constructs of a data model?
Banking system: Customer, Account, Loan.
• Can you read and interpret a entity relationship data model? A precise definition of ‘entity’ is not really possible, as they even
• When in a project are data models constructed and where are vary in nature. For example, in the airline system, whilst an aircraft
they stored? is a physical object (entities often are) a flight is an event and an
• Can you discover entities and relationships? airport is a location. However entities are nearly always those things
• Can you construct an entity-relationship context diagram? about which data will be stored within the system under
investigation.
• Can you discover or invent keys for entities?
Note that entities are always named in the singular; for example:
• Can you construct a fully attributed entity relationship diagram
customer, account and loan, and not customers, accounts and
and describe all data structures and attributes to the repository
loans.
or encyclopedia?
This course uses symbols that are standard in the IT industry.
What is Data modeling? This uses the soft-box symbol shown to represent an entity. If a
site uses a different symbol set, this is not a problem, as data
modeling techniques are the same regardless of the symbols being
used.
Systems Analysis – Entity Types &
Occurrence
Similar entity occurrences are grouped together and collectively
termed an entity type. It is entity types that are identified and
drawn on the data model.
An entity occurrence identifies a specific resource, event, location,
notion or (more typically) physical object.
In this course the term ‘entity’ is, by default, referring to entity
type. The term entity occurrence will be specifically used where that
is relevant.
Each entity has a data group associated with it. The elements of
the data group are referred to as the ‘attributes ‘ of the entity. The
An entity is something about which data will be stored within the distinction between what is an attribute of an entity and what is
system under consideration. In this example the data group invoice an entity in its own right is often unclear. This is illustrated shortly.
can be identified as a system entity. Systems Analysis– Entity Naming
The other main component on a data model is the relationship Entity names are normally single words and the name chosen
line. A Relationship is an association between two entities to should be one familiar to the users. The entity name can include a
which all of the occurrences of those entities must conform. qualifier in order to clarify their meaning. However, if different
The relationship is represented by a line that joins the two entities, names are currently used to describe a given entity in different
to which it refers. This line represents two reciprocal areas of the organization then a new one should be chosen that is
relationships:That of the first entity with respect to the second, original, unique and meaningful to all of the users.
and that of the second entity with respect to the first.
Data modeling is all about identifying entities and their

140
For example, the terms ‘signed contract’, ‘sale’ and ‘agreement’ There are six potential entities listed. From this initial list we will

SYSTEMS ANALYSIS
might be recreated as the entity ‘completed’. consider the ‘suppliers price list’ to be a likely attribute of the
Conversely an organization may be using a ‘catch all’ term to entity ‘supplier’. Therefore we shall consider this within the context
describe what the analyst identifies as being a number of separate of the supplier entity. The ‘invoicing details’ are stated to be
entities. For example the term ‘invoice’ may be being used to attributes of the ‘order record’ entity, so we shall also discount
describe 3 invoice types - each of which is, in fact, processed in a this as a potential entity at this stage.
different manner. Remember that entities are described in the singular as they relate
In this case prefixing the entity names with qualifiers, is likely to to entity types. ‘Customer’ for example represents the entity type
be the best solution. ‘customer’ which encompasses an infinite number of ‘customer’
entity occurrences.
Systems Analysis – Entity Identification
It is usual for an experienced analyst to use an intuitive approach Taking these four as our list of potential entities, each will be
to identifying entities, in order to produce a shortlist of things discussed in turn:
that could potentially be entities. The viability of each of these can Systems Analysis – Entity Identification –
then be considered using a set of entity identification guidelines. Exercise # 2
This should result in some of them being confirmed as entities, In many business systems, information about the customer is of
whilst others will be rejected. great importance. An insurance company or bank, for example,
In this exercise you will be asked to identify a set of potential could not function without a customer database on which
entities within a simple business scenario. This should help you comprehensive personal details are stored. This customer database
to understand and appreciate the entity identification guidelines also serves as an essential resource for selling new financial products
better. and services.
Read the following case study. Study this information carefully But how much customer information is likely to be stored by City
and see if you can identify the entities - remember that entities are Cameras?
those things about which data will be stored. Are they even going to record the name & address of their
Make your own list of those things that you think are likely to be customers?
entities, before moving to the next screen. Interviews with the owner reveal the answer to be that he has no
Systems Analysis – Entity Identification real interest in storing ‘information’ about his customers. He only
Case Study records their details onto any necessary warranty documents and
then sends these off to the appropriate supplier.
City Cameras is an independent retailer of cameras, video-cameras
and accessories. The owner fulfils the roles of shopkeeper and Therefore, in the context of this system customer is NOT an
manager and he purchases a variety of products from a number entity.
of different suppliers. Systems Analysis – Entity Identification –
The owner can check on different suppliers wholesale and Exercise # 3
recommended retail prices with reference to their price lists, as It is a natural assumption that all retail businesses would hold a
shown. significant amount of product information. However in this study
the only level of product information is that which is held on the
During a normal day several customers will enter the shop and a
suppliers’ price lists.
number of them will buy one or more of the products on sale.
Lets look again at the suppliers price list in the case study. This
At some stage the owner may decide that one or more product
confirms that product information is held within this system and
lines need to be re-ordered, following a visual stock-take. He will
it is apparent from the case study that products are of real interest.
then consult the latest suppliers price lists to see who is offering
the best deals on given product lines. So have we Identified an Entity?
Following this, he will ring one or more of the suppliers to order At this stage it would be likely that product would be considered
some of their products. At the same time he will also make a to be an entity. However, you will shortly see why the analysis
written record of the orders that have been placed with each supplier phase needs to be iterative - enabling decisions to be altered later,
on a separate sheet of paper. These records are then used to verify if necessary.
incoming orders and invoicing details.
Systems Analysis– Entity Identification –
Exercise #1
With reference to the case study information, make a list of all of
those things mentioned in the case study that could be entities -
that is the potential entities.
Your list should look something like that shown below:
Suppliers Price List, Customer, Product, Order, Invoicing Details
& Supplier

141
 Systems Analysis– Entity Identification – References
SYSTEMS ANALYSIS

Exercise # 4 Heuring, Vincent P.

Computer systems Design and Architecture
Delhi : Pearson Education Asia, 1997
Whitten, Jeffrey L.
Systems Analysis and Design Methods
5th ed. New Delhi : Galgotia Publications, 2001
Shelly, Gary B.
Systems Analysis and Design
3rd ed. New Delhi : Galgotia Publications, 1999
Bennett, Simon
Object-Oriented systems Analysis and
Design using UML
2nd ed. New Delhi : McGraw Hill Book, 2002
Booch, Grady
Object-oriented Analysis and
Design : with applications
Once again a natural assumption would be that a retail business
2nd ed. Reading : Addison-Wesley Publishing, 2000
would store substantial information about its’ suppliers.
Hoffer, Jeffrey A.
On requesting to see information about City Cameras’ suppliers,
Modern systems Analysis and Design
the owner once again reaches for the suppliers’ price lists.
2nd ed. Delhi : Pearson Education Asia, 2000
Lets look again at the suppliers’ price list in the case study. Each of
these lists has the name, address and telephone number of the Kain, Richard Y.
supplier on the first page. The suppliers’ price list is the only place Advanced Computer Architecture :
where City Cameras stores information about suppliers. A systems Design Approch
Whilst the early investigation indicated that ‘product’ was probably New Delhi : Prentice Hall of India, 1996
an entity, it now becomes apparent that the unique identification Sima, Dezso
of a product and access to the product information is also only Advanced computer Architectures :
possible after locating the relevant suppliers price list.
A Design space Approch
It has now been established that all of the information that is
Delhi : Pearson Education Asia, 1997
stored in relation to the two potential entities ‘product’ and
‘supplier’ are held in the same place - the suppliers’ price list. This Sarkar, A.K.
means that the suppliers’ price list is an entity and that both Systems analysis, Data Processing
product and supplier represent information held within this entity. and Quantitative Techniques
Both supplier and product are therefore identified as being New Delhi : Galgotia Publications, 1997
attributes of the entity ‘suppliers price list’.
Hawryszkiewycz, Igor
Systems Analysis– Entity Identification – Introduction to Systems Analysis & Design
Exercise # 5 4th ed. New Delhi : Prentice Hall of India, 2002
What about the potential entity: ‘Order’. Investigation reveals
that the re-ordering process consists of visual stocktaking on an Awad, Elias M.
ad-hoc basis, followed by mental recall of those suppliers that Systems Analysis and Design
stock the identified products. New Delhi : Galgotia Publications, 1997
The appropriate suppliers price lists are then referred to for the
up-to-date pricing information and contact details and the order
is placed over the telephone. The owner keeps a written record of
the orders he places, each order on a separate sheet of paper, and
these are then filed.

142
 LESSON 30 :

SYSTEMS ANALYSIS
ENTITY IDENTIFICATION

Topics covered more of these low level facts, then this indicates that your entity
• Entity Identification search is incomplete.

Objectives However, don’t get hung up on the initial analysis. Entity

identification can continue once the drawing of the data model
Upon completion of this Lesson, you should be able to: diagram has begun. As this diagram is developed and refined
• Discuss the System analysis entity identification further entities may become apparent.
Systems Analysis – Entity Identification – Systems Analysis– Attributes & Keys
Exercise # 6 Each entity type can always be described in terms of attributes,
Having started with six potential entities (suppliers price list, and these attributes will apply to all occurrences of that given
customer, product, order, invoicing details and supplier), the entity type. In the camera shop example, all occurrences of the
analysis has identified that only two of these are in fact entities. entity ‘supplier’ could be described by an identifiable set of
We eliminated customer, as no customer information is recorded attributes, including:
or stored within this retail outlet. The Supplier Name, the Supplier Address, Telephone Number,
The stored information relating to both a product and a supplier etcetera, as shown.
was found to only exist within the suppliers’ price list. Therefore
Suppliers’ Price List was identified as being the only entity amongst
these three.
Order was confirmed as a system entity and the invoicing details
were identified early on as being an attribute of this entity.
Even in this simple scenario it should be apparent that entity
identification needs careful consideration. Interestingly, both of
the entities that were identified existed as documents within the
system. Entities are often synonymous with discrete information
stores within a system - whether physical or electronic.
The precise definition of what is an entity and what is an attribute
will not always be clear. Therefore the process of entity identification
should be iterative, enabling the review of decisions made earlier.
Remember, entity types are always named in the singular and this
name then represents all of the occurrences of that entity type.
Systems Analysis – Entity Identification Guidelines
There are a variety of methods that can be employed when trying A given attribute belonging to a given entity occurrence can only
to identify system entities. There follows a series of entity have one value. Therefore, if a supplier could have more than one
identification guidelines, which should prove helpful to the address or telephone number then this should be determined
inexperienced analyst: before defining the attributes of that entity type.
An informal questioning approach can be adopted, in which the In this example the defined entity may require two or three address
analyst asks targeted questions to determine what information is and/or telephone number attributes. It is the maximum practical
necessary and whether or not that information is recorded within instances of a given attribute that should be catered for in the
the system. entity type definition.
During face to face discussions with users the nouns (or given Systems Analysis – Entity Keys
names of objects) should be recorded - as these often indicate An entity is defined by its attributes. Furthermore, each entity
those things that are entities within a system. occurrence can be uniquely identified, by using an attribute or a
The existing documentation often contains clues as to the combination of attributes as a key.
information that needs to be held and once again the nouns in the The primary key is the attribute (or group of attributes) that serve
text may indicate potential entities. to uniquely identify each entity occurrence. Consider the problem
Every fact that is required to support the business is almost certainly that might arise if the name and address of an individual were
an attribute (or data item). In turn each of these attributes will used as the primary key for identifying the patients within a
belong to an entity. If no ‘parent’ entity can be found for one or hospital.

143
 Take the example of a patient called David Smith living at 23 Systems Analysis– Relationship Link Phrase
SYSTEMS ANALYSIS

Acacia Avenue. He has a son also called David Smith living at the
same address.
Name and Address would not necessarily provide a unique
identifier and confusion could easily arise, potentially creating a
mix up with the patient records.
For this reason, in a hospital system patients each have a Patient
Number as their primary key. The first property of the relationship statement is the relationship
link phrase. This should be a short description of the nature of
If two or more data items are used as the unique identifier, then
the relationship, typically between three and five words long. It is
this represents a compound key. For example, a compound key
always read clockwise with respect to the entities that it links, so in
used to identify a book could be ‘Title’ together with ‘Author’.
this example:
There may be occasions of authors using a previously used title
’Manager is responsible for department’, and ‘Department is
but not of an author using the same title for more than one of
responsibility of manager’
their own books.
If the same relationship were to be drawn with department on
Where several possible primary keys exist they are called candidate
the left hand side then the positions of the link phrases would
keys.
have to be reversed.
For example, a book could be identified, either by ‘Title’ together
Systems Analysis – Relationship Cardinality
with ‘Author’ or by the widely used unique identifier for books -
The second property of the relationship statement is the degree,
the ISBN number.
or maximum cardinality, of the relationship. If an entity has a
Where an attribute of one entity is a candidate key for another crowsfoot symbol drawn against it, then many occurrences of
entity, it is termed a foreign key. that entity may relate to the other entity. Conversely if no crowsfoot
For example, the attribute ‘Author’ belonging to the entity Book is drawn against it, at most one occurrence of that entity may relate
is a foreign key within the entity Author. You may be able to think to the other entity.
of some shortcomings to the use of this attribute as the primary
key, for example two authors having the same name.
It is worth noting that entity relationships are often indicated by
the presence of foreign keys.
Systems Analysis – Relationships
In this example: Each company employs one or more employees,
but Each employee is employed by only one company. This is
called a one-to-many relationship.
Maximum cardinalities may be combined to give another two
relationship types, In this example:

A relationship is the association between two entities to which all

of the occurrences of those entities must conform. The diagram
shown represents the beginnings of a data model where the
relationship between a manager and a department needs to be
defined.
The entities on data models are linked by relationship lines and
Each manager is responsible for only one department and each
together these are the only two components that make up a data
department is the responsibility of only one manager. This is
model diagram. A relationship is an association between two
called a one-to-one relationship.
entities to which all of the occurrences of those entities must
conform. And in this example
Every relationship line shows two reciprocal relationships:
That of the first entity with respect to the second and that of the
second entity with respect to the first. In this example a manager
is responsible for a department and a department is the
responsibility of a manager.
Each relationship line has three distinct properties: Firstly the
relationship link phrase, secondly the degree or cardinality of the Each lecturer teaches one or more courses and each course is taught
relationship and thirdly the participation or optionality of the by one or more lecturers. This is called a many-to-many relationship.
relationship. These three properties combine to form the To recap, three different relationship types have been illustrated,
relationship statement. one-to-many, one-to-one and many-to-many.

144
Questions Sarkar, A.K.

SYSTEMS ANALYSIS
1. What is system analysis and structured system analysis? Systems Analysis, Data processing and
Quantitative Techniques
2. Please tell several models used to analyse system.
New Delhi : Galgotia Publications, 1997
3. Why does system analysis play an important role in the system’s
development life cycle? Hawryszkiewycz, Igor
Introduction to systems Analysis & Design
4. Please tell the roles of system analysts.
4th ed. New Delhi : Prentice Hall of India, 2002
5. What are the popular tools used during the system analysis?
Awad, Elias M.
6. What is BFD? Why is it important?
Systems analysis and design
7. What are the main components of BFD?
New Delhi : Galgotia Publications, 1997
8. What are the main components of DFD?
Notes
9. What is data dictionary? Please tell some of its main
components.
10. What is process specification? Please tell some of its main
components.
11.Base on which foundation do you build the ERD? What are
their main components?
12. What are some of the popular relationships?
13. What is recursive relationship?
14. What are some popular normalization used in the building
and testing of models?
References
Heuring, Vincent P.
Computer Systems Design and Architecture
Delhi : Pearson Education Asia, 1997
Whitten, Jeffrey L.
Systems Analysis and Design Methods
5th ed. New Delhi : Galgotia Publications, 2001
Shelly, Gary B.
Systems Analysis and Design
3rd ed. New Delhi : Galgotia Publications, 1999
Bennett, Simon
Object-Oriented systems Analysis and
Design using UML
2nd ed. New Delhi : McGraw Hill Book, 2002
Booch, Grady
Object-Oriented Analysis and
Design : with Applications
2nd ed. Reading : Addison-Wesley Publishing, 2000
Hoffer, Jeffrey A.
Modern systems analysis and Design
2nd ed. Delhi : Pearson Education Asia, 2000
Kain, Richard Y.
Advanced Computer Architecture :
a systems Design approch
New Delhi : Prentice Hall of India, 1996
Sima, Dezso
Advanced computer Architectures :
a Design space Approch
Delhi : Pearson Education Asia, 1997

145
SYSTEMS ANALYSIS

LESSON 31 :
RELATIONSHIPS

Topics covered In order to identify the degree of the relationship between the
• Relationships entities X and Y the following two questions need to be asked.

Objectives Question 1
Can an occurrence of X to be associated with more than one
Upon completion of this Lesson, you should be able to:
occurrence of Y?
• Discuss the various notation used in entity relation modelling
Question 2
Systems Analysis – Relationship Participation Can an occurrence of Y to be associated with more than one
The third and final property of the relationship statement is the occurrence of X?
participation or optionality. A solid line shows that an entity
Each of these questions can be answered ‘Yes’ or ‘No’ and both
occurrence must be associated with each occurrence of the other
questions must be answered. This means that there are four
entity. In this example:
possible outcomes as shown in the table.

Each passenger must possess a ticket, and Each ticket must belong
to a passenger. A dotted line shows that an entity occurrence may
be associated with each occurrence of the other entity, In this
example
The nature of the relationship associated with each outcome is as
follows:
Option 1, Question1 equals Yes, Question2 equals No.
In this case a one-to-many relationship has been identified,
represented by the relationship line shown.
Option 2, Question1 equals No, Question2 equals Yes
Each book may be borrowed by a borrower, and Each borrower As in the first case a one-to-many relationship has been identified,
may borrow one or more books. Furthermore, these symbols can represented by the relationship line shown.
be combined. In this example:
Option 3, Question1 equals Yes, Question2 equals Yes
In this case a many-to-many relationship has been identified.
Many-to-many relationships may be shown in the early
‘preliminary’ data model in order to aid the clarity of these early
diagrams. However, such relationships are invalid and are therefore
always re-modeled using ‘link entities’ in later diagrams. This
Each book may be recalled by a reservation, but Each reservation process is explained later in the course.
must be recalling a book. Option 4, Question1 equals No, Question2 equals No
Remember, there are only two components to a data model In this case a one-to-one link has been identified.
diagram, entities and relationships. A relationship is an association Legitimate one-to-one relationships are rare and it is likely that
between two entities to which all of the occurrences of those two this relationship is one that needs to be rationalized. The methods
entities must conform. used to investigate one-to-one relationships and to re-model them
There are three distinct properties of the relationship; firstly the where necessary are explained later in the course.
relationship link phrase, secondly the degree or cardinality of the In a one-to-many relationship the entity at the ‘one’ end is normally
relationship and thirdly the participation or optionality of the referred to as the master, and the entity at the ‘many’ end referred
relationship. These three properties are collectively termed the to as the detail entity. Some analysts adopt the ‘no dead crows’
relationship statement. rule and avoid drawing crowsfeet pointing upwards. This ensures
Systems Analysis– Identifying Relationships that detail entities are shown below the master entities to which
There are just two questions that need to be asked, in order to they belong.
establish the degree of the relationship that exists between any This makes the diagram clearer, although congestion may make
two entities. this rule difficult to enforce throughout the data model.

146
Systems Analysis– Relationship Statements This diagram represents a banking process, which maintains

SYSTEMS ANALYSIS
The relationship statement is a formal description that customer accounts. In this example, customers can withdraw or
encompasses the three properties of the relationship. deposit cash, request information about their account (for example
The relationship statement encompasses the three properties of the balance) or update their account details (for example with
the relationship. The first property is the relationship link phrase, change of address information).
the second the degree or cardinality of the relationship and the The five different symbols used in this example represent the full
third the participation or optionality of the relationship. set of symbols required to draw any business process diagram.
Systems Analysis - DFD Introduction External Entity

An external entity is a source or destination of a data flow which

is outside the area of study. Only those entities which originate or
receive data are represented on a business process diagram. The
symbol used is an oval containing a meaningful and unique
Data flow diagrams can be used to provide a clear representation identifier. In this example the customer exists outside of the
of a business function. The technique starts with an overall picture banking business system.
of the business and continues by analyzing each of the functional Process
areas of interest to the level of detail required. The technique
exploits a method called top-down expansion to conduct the
analysis in a targeted way.
The result is a series of diagrams that represent the business
activities in a way that is clear and easy to communicate. A business
model comprises one or more data flow diagrams (also known as
business process diagrams). Initially a context diagram is drawn,
which is a simple representation of the entire system under
investigation. A process shows a transformation or manipulation of data flows
within the system. The symbol used is a rectangular box which
This is followed by a level 1 diagram; which provides an overview
contains 3 descriptive elements:
of the major functional areas of the business. Don’t worry about
the symbols at this stage, these are explained shortly. Using the Firstly an identification number appears in the upper left hand
context diagram together with additional information from the corner. This is allocated arbitrarily at the top level and serves as a
area of interest, the level 1 diagram can then be drawn. unique reference.
The level 1 diagram identifies the major business processes at a Secondly, a location appears to the right of the identifier and
high level and any of these processes can then be analyzed further describes where in the system the process takes place. This may,
- giving rise to a corresponding level 2 business process diagram. for example, be a department or a piece of hardware.
This process of more detailed analysis can then continue – through Finally, a descriptive title is placed in the centre of the box. This
level 3, 4 and so on. However, most investigations will stop at should be a simple imperative sentence with a specific verb, for
level 2 and it is very unusual to go beyond a level 3 diagram. example ‘maintain customer records’ or ‘find driver’.
Identifying the existing business processes, using a technique like Data Flow
data flow diagrams, is an essential precursor to business process
re-engineering, migration to new technology, or refinement of an
existing business process. However, the level of detail required
will depend on the type of change being considered.
A data flow shows the flow of information from its source to its
Systems Analysis– DFD Notation
destination. A data flow is represented by a line, with arrowheads
There are only five symbols that are used in the drawing of
showing the direction of flow. Information always flows to or
business process diagrams (data flow diagrams). These are now
from a process and may be written, verbal or electronic. Each data
explained, together with the rules that apply to them.
flow may be referenced by the processes or data stores at its head
and tail, or by a description of its contents.

147
 Data Store
SYSTEMS ANALYSIS
In order to avoid complex flows, the same data store may be
drawn several times on a diagram. Multiple instances of the same
data store are indicated by a double vertical bar on their left hand
edge.
A data store is a holding place for information within the system: Systems Analysis – DFD Relationship
It is represented by an open ended narrow rectangle. Grid
Data stores may be long-term files such as sales ledgers, or may be There are rules governing various aspects of the diagram
short-term accumulations: for example batches of documents components and how they can relate to one another.
that are waiting to be processed. Each data store should be given
Data Flows
a reference followed by an arbitrary number.
For data flows the rules are as follows:
Resource Flow
Data flows and resource flows are allowed between external entities
and processes. Data flows are also allowed between different
external entities. However, data flows and resource flows are not
A resource flow shows the flow of any physical material from its allowed between external entities and data stores.
source to its destination. For this reason they are sometimes Processes
referred to as physical flows.
For processes the data flow rules are as follows:
The physical material in question should be given a meaningful Data flows and resource flows are allowed between processes and
name. Resource flows are usually restricted to early, high-level external entities and between processes and data stores. They are
diagrams and are used when a description of the physical flow of also allowed between different processes. In other words processes
materials is considered to be important to help the analysis. can communicate with all other areas of the business process
Systems Analysis – Drawing Data Flow diagram.
Diagrams Data Stores
Processes For data stores the data flow rules are as follows:
When naming processes, avoid glossing over them, without really Data flows and resource flows are allowed between data stores
understanding their role. Indications that this has been done are and processes. However, these flows are not allowed between
the use of vague terms in the descriptive title area - like ‘process’ or data stores and external entities or between one data store and
‘update’. another. In practice this means that data stores cannot initiate a
The most important thing to remember is that the description communication of information, they require a process to do this.
must be meaningful to whoever will be using the diagram.
Data Flows
Double headed arrows can be used (to show two-way flows) on
all but bottom level diagrams. Furthermore, in common with
most of the other symbols used, a data flow at a particular level of
a diagram may be decomposed to multiple data flows at lower
levels.
External Entities
It is normal for all the information represented within a system to
have been obtained from, and/or to be passed onto, an external
source or recipient. These external entities may be duplicated on a
diagram, to avoid crossing data flow lines. Where they are The context diagram represents the entire system under
duplicated a stripe is drawn across the left hand corner, like this. investigation. It should be drawn first, and used to clarify and
The addition of a lowercase letter to each entity on the diagram is agree the scope of the investigation. The system under
a good way to uniquely identify them. investigation is represented as a single process, connected to
external entities by data flows and resource flows.
Data Stores
The context diagram clearly shows the interfaces between the
Each store should be given a reference letter, followed by an arbitrary
system under investigation and the external entities with which it
number. These reference letters are allocated as follows:
communicates. Therefore, whilst it is often conceptually trivial, a
’D’ - indicates a permanent computer file context diagram serves to focus attention on the system boundary
’M’ - indicates a manual file and can help in clarifying the precise scope of the analysis. The
’T’ - indicates a transient store, one that is deleted after context diagram shown on this screen represents a book lending
processing. library. The library receives details of books, and orders books
from one or more book suppliers.

148
Books may be reserved and borrowed by members of the public,

SYSTEMS ANALYSIS
Notes
who are required to give a borrower number. The library will
notify borrowers when a reserved book becomes available or when
a borrowed book becomes overdue. In addition to supplying
books, a book supplier will furnish details of specific books in
response to library enquiries.
Note, that communications involving external entities are only
included where they involve the ‘system’ process. Whilst a book
supplier would communicate with various agencies, for example,
publishers and other suppliers - these data flow are remote from
the ‘system’ process and so this is not included on the context
diagram.
References
Heuring, Vincent P.
Computer systems Design and Architecture
Delhi : Pearson Education Asia, 1997
Whitten, Jeffrey L.
Systems Analysis and design methods
5th ed. New Delhi : Galgotia Publications, 2001
Shelly, Gary B.
Systems Analysis and Design
3rd ed. New Delhi : Galgotia Publications, 1999
Bennett, Simon
Object-oriented systems Analysis and
Design using UML
2nd ed. New Delhi : McGraw Hill Book, 2002
Booch, Grady
Object-Oriented Analysis and Design :
with applications
2nd ed. Reading : Addison-Wesley Publishing, 2000
Hoffer, Jeffrey A.
Modern systems Analysis and Design
2nd ed. Delhi : Pearson Education Asia, 2000
Kain, Richard Y.
Advanced Computer Architecture :
a systems Design approch
New Delhi : Prentice Hall of India, 1996
Sima, Dezso
Advanced Computer Architectures :
a Design space Approch
Delhi : Pearson Education Asia, 1997
Sarkar, A.K.
Systems Analysis, Data processing and
Quantitative Techniques
New Delhi : Galgotia Publications, 1997
Hawryszkiewycz, Igor
Introduction to systems Analysis & Design
4th ed. New Delhi : Prentice Hall of India, 2002
Awad, Elias M.
Systems Analysis and Design
New Delhi : Galgotia Publications, 1997

149
SYSTEMS ANALYSIS

LESSON 32 :
CONTEXT DIAGRAM

Topics Covered There are three different methods, which provide a practical way to
• Context Diagram start the analysis. These are introduced below and any one of
them, or a combination, may prove to be the most helpful in any
Objectives given investigation:
Upon completion of this Lesson, you should be able to:
Systems Analysis – Resource Flow
• Discuss about context diagrams Analysis
Systems Analysis Context Diagram Resource flow analysis may be a useful method for starting the
Guidelines analysis if the current system consists largely of the flow of goods,
Firstly, draw and name a single process box that represents the as this approach concentrates on following the flow of physical
entire system. objects.
Next, identify and add the external entities that communicate Resource flow analysis may be a useful method for developing
directly with the process box. Do this by considering origin and diagrams if the current system consists largely of the flow of
destination of the resource flows and data flows. goods. Physical resources are traced from when they arrive within
the boundaries of the system, through the points at which some
Finally, add the resource flows and data flows to the diagram. action occurs, to their exit from the system. The rationale behind
In drawing the context diagram you should only be concerned this method is that information will normally flow around the
with the most important information flows. These will be same paths as the physical objects.
concerned with issues such as: how orders are received and checked,
Systems Analysis – Organizational
with providing good customer service and with the paying of
Structure Analysis
invoices. Remember that no business process diagram is the
The organizational structure approach starts from an analysis of
definitive solution - there is no absolute right or wrong.
the main roles that exist within the organization, rather than the
Systems Analysis– Level 1 Diagrams goods or information that is flowing around the system.
Identification of the key processes results from looking at the
organizational structure and deciding which functional areas are
relevant to the current investigation. By looking at these areas in
more detail, and analyzing what staff actually do, discrete processes
can be identified.
Starting with these processes, the information flows between them
and between these processes and external entities are then identified
and added to the diagram.
Systems Analysis – Document Flow
Analysis
There is no formula that can be applied in deciding what is, and
The document flow analysis approach is appropriate if the part of
what is not, a level 1 process. Level 1 processes should describe
the business under investigation consists principally of flows of
only the main functional areas of the system, and you should
information in the form of documents or computer input and
avoid the temptation of including lower level processes on this
output.
diagram. As a general rule no business process diagram should
contain more than 12 process boxes.# Document flow analysis is particularly useful where information
The level 1 diagram shows the main functional areas of the system flows are of special interest. The first step is to list the major
under investigation. As with the context diagram, any system documents and their sources and recipients. This is followed by
under investigation should be represented by only one level 1 the identification of other major information flows such as
diagram. telephone and computer transactions. Once the document flow
The level 1 diagram is surrounded by the outline of a process box diagram has been drawn the system boundary should be added.
that represents the boundaries of the system. Because the level 1
diagram depicts the whole of the system under investigation, it
can be difficult to know where to start.
There are three different methods, which provide a practical way
to start the analysis. These are explained in the following section
and any one of them, or a combination, may prove to be the
most helpful in any given investigation.

150
Systems Analysis – Top Down Expansion In the level 2 diagram four processes of interest have been identified

SYSTEMS ANALYSIS
and the numbering of these processes must reflect the parent
process. Therefore the level 2 processes are numbered 3.1, 3.2, 3.3
and 3.4
Suppose that of these four level 2 processes, one was of sufficient
interest and complexity to justify further analysis. This process,
let’s say 3.3, could then be further analyzed resulting in a
corresponding level 3 diagram. Once again the numbering of these
processes must reflect the parent process. Therefore these three
level 3 processes are numbered 3.3.1, 3.3.2 and 3.3.3.
Systems Analysis – DFD Numbering Rules
The screen explains the process of top down expansion and
illustrates that whilst there can only be one context and one level 1
diagram for a given system, these normally give rise to numerous
lower level diagrams.
Each process within a given data flow diagram may be the subject
of further analysis. This involves identifying the lower level
processes that together constitute the process as it was originally
identified. This procedure is known as top-down expansion or
leveling.
As a business process diagram is decomposed, each process box
becomes a boundary for the next, lower level, diagram.
Systems Analysis – Top Down Expansion
Illustrated
The process boxes on the level 1 diagram should be numbered
arbitrarily, so that no priority is implied. Even where data from
one process flows directly into another process, this does not
necessarily mean that the first one has to finish before the second
one can begin.
Therefore the processes on a level 1 diagram could be re-numbered
without affecting the meaning of the diagram. This is true within
any business process diagram - as these diagrams do not imply
time, sequence or repetition.
However, as the analysis continues beyond level 1 it is important
that a strict numbering convention is followed. The processes on
level 2 diagrams must indicate their parent process within the level
1 diagram. This convention should continue through level 3
diagrams, and beyond, should that level of analysis ever be
required.
The diagram on this screen clearly illustrates how processes on
In order to illustrate the process of top-down expansion, consider lower level diagrams identify their ancestral path.
the three processes shown within this business process diagram. Systems Analysis - When to Stop Top
No detail is shown, only the outline of the process boxes, which Down Expansion
have been identified during the drawing of a level 1 diagram. It is important to know when to stop the process of top-down
Any area of a level 1 diagram is likely to require further analysis, as expansion. Usually this will be at level 2 or level 3.
the level 1 diagram itself only provides a functional overview of There are 3 useful guidelines to help you to decide when to stop
the business system. the analysis:
Therefore, below the level 1 diagram there will be a series of lower Firstly, if a process has a single input data flow or a single output
level diagrams. These are referred to as level 2, level 3, etcetera. In data flow then it should be apparent that there is little point in
practice, level 2 is usually sufficient and it is unusual to carry out an analyzing it any further.
analysis beyond level 3.
Secondly, when a process can be accurately described by a single
In this example the process numbered 3, at level 1, will be active verb with a singular object, this also indicates that the analysis
investigated further thereby giving rise to a level 2 diagram. has been carried out to a sufficiently low level. For example, the
process named validate enquiry contains a single discrete task.

151
 Finally, ask yourself if anything useful will be gained by further (i) Draw a context diagram for the order system
SYSTEMS ANALYSIS

analysis of a process. Would any more detail influence your (ii) Draw a DFD diagram 0 for the order system
decisions?
(iii) Name four attributes that you can use to define a process in
If the answer is no, then there is little point in taking the analysis the order system.
further.
(iv) Name four attributes that you can use to define an entity in
Systems Analysis– Keeping DFDs Clear the order system
In this section a variety of simple techniques are introduced to
References
show how a business process diagram can be clarified. The examples
used do not relate to any specific scenario but are hypothetical Heuring, Vincent P.
abstracts used for the purpose of illustration. Computer systems Design and Architecture
Delhi : Pearson Education Asia, 1997
Exclude Minor Data Flows
Where information is being retrieved from a data store, it is not Whitten, Jeffrey L.
necessary to show the selection criteria, or key, that is being used to Systems Analysis and Design Methods
retrieve it. 5th ed. New Delhi : Galgotia Publications, 2001
In the banking example, the customer details are shown being Shelly, Gary B.
retrieved from the data store but the key used to retrieve this Systems Analysis and Design
information is not shown. 3rd ed. New Delhi : Galgotia Publications, 1999
Where a data store is being updated, only the data flow representing Bennett, Simon
the update needs to be shown. The fact that the information Object-Oriented systems Analysis and
must first be retrieved does not need to be shown. Design using UML
Only the most important reports, enquiries, etcetera should be 2nd ed. New Delhi : McGraw Hill Book, 2002
shown on the diagram. Communications that are of less
Booch, Grady
significance can, if necessary, be detailed in support documentation.
Object-Oriented Analysis and
Combining Data Stores Design : with applications
In a similar way, data stores that are holding related information 2nd ed. Reading : Addison-Wesley Publishing, 2000
should be suffixed with a lower case letter.
Hoffer, Jeffrey A.
Related data stores can also be combined, and where this is the Modern systems Analysis and Design
case the numbers placed after the identifying alphabetic character
are not shown. 2nd ed. Delhi : Pearson Education Asia, 2000
Kain, Richard Y.
Combining External Entities
Advanced computer Architecture :
Another way to reduce the complexity of a business process
A systems Design Approach
diagram is to combine any related external entities.
New Delhi : Prentice Hall of India, 1996
For example, a business system will often be dealing with different
units from within the same external organization, and these can Sima, Dezso
be combined into a single external entity. Where these units are Advanced computer Architectures :
uniquely identified a number should follow the entity identification a Design space Approach
letter. However, when they are combined the numbers placed Delhi : Pearson Education Asia, 1997
after the identifying alphabetic character are not shown.
Sarkar, A.K.
Combining Processes
Systems Analysis, Data processing and
Firstly, where a diagram is considered to contain too many Quantitative Techniques
processes, those that are related can often be combined. As a
New Delhi : Galgotia Publications, 1997
general rule no business process diagram should contain more
than 12 process boxes. Hawryszkiewycz, Igor
Introduction to systems Analysis & Design
In some examples multiple process boxes can be identified as
being related and can be combined into a single process box with 4th ed. New Delhi : Prentice Hall of India, 2002
a collective description. Awad, Elias M.
Systems Analysis and Design
Questions:.
New Delhi : Galgotia Publications, 1997
Precision Tools sells a line of high quality woodworking tools.
When customers place orders on the company’s website , the
system checks to see if the items are in stock, issues a atatus
message to the customer and generates a shipping order to the
warehouse, which fills the order. When the order is shipped , the
customer is billed. The system also produces various reports.

152
 SYSTEMS ANALYSIS
LESSON 33 :
SYSTEM MODELING

Topics Covered • Why is data modeling considered crucial?

• System modeling (data modeling) • Data is viewed as a resource to be shared by as many processes
Objectives as possible. As a result, data must be organized in a way that is
flexible and adaptable to unanticipated business requirements
Upon completion of this Lesson, you should be able to: -and that is the purpose of data modeling.
• Discuss about data modelling • Data structures and properties are reasonably permanent
An Introduction to Systems Modeling certainly a great deal more stable than the processes that use the
data. Often the data model of a current system is nearly identical
Systems Modeling
to that of the desired system.
• One way to structure unstructured problems is to draw models.
• Data models are much smaller than process and object models
• A model is a representation of reality. Just as a picture is worth and can be constructed more rapidly.
a thousand words, most system models are pictorial
• The process of constructing data models helps analysts and
representations of reality.
users quickly reach consensus on business terminology and
• Models can be built for existing systems as a way to better rules.
understand those systems, or for proposed systems as a way
to document business requirements or technical designs. System Concepts for Data Modeling
What are Logical Models? System Concepts
• Logical models show what a system ‘is’ or ‘does’. They are • Most systems analysis techniques are strongly rooted in systems
implementation-independent; that is, they depict the system thinking.
independent of any technical implementation. As such, logical • Systems thinking is the application of formal systems theory
models illustrate the essence of the system. and concepts to systems problem solving.
What are Physical Models? • There are several notations for data modeling, but the actual
model is frequently called an entity relationship diagram (ERD).
• Physical models show not only what a system ‘is’ or ‘does’,
but also how the system is physically and technically • An ERD depicts data in terms of the entities and relationships
implemented. They are implementation-dependent because described by the data.
they reflect technology choices, and the limitations of those Entities
technology choices.
• All systems contain data.
• Systems analysts use logical system models to depict business • Data describes ‘things’.
requirements, and physical system models to depict technical
designs. • A concept to abstractly represent all instances of a group of
similar ‘things’ is called an entity.
• Systems analysis activities tend to focus on the logical system
models for the following reasons: • An entity is something about which we want to store data.
Synonyms include entity type and entity class.
• Logical models remove biases that are the result of the way the
current system is implemented or the way that any one person • An entity is a class of persons, places, objects, events, or concepts
thinks the system might be implemented. about which we need to capture and store data.
• Logical models reduce the risk of missing business • An entity instance is a single occurrence of an entity.
requirements because we are too preoccupied with technical Attributes
details. • The pieces of data that we want to store about each instance of
• Logical models allow us to communicate with end-users in a given entity are called attributes.
non-technical or less technical languages. • An attribute is a descriptive property or characteristic of an
• Data modeling is a technique for defining business entity. Synonyms include element, property, and field.
requirements for a database. • Some attributes can be logically grouped into super-attributes
• Data modeling is a technique for organizing and documenting called compound attributes.
a system’s DATA. Data modeling is sometimes called database • A compound attribute is one that actually consists of more
modeling because a data model is usually implemented as a primitive attributes. Synonyms in different data modeling
database. It is sometimes called information modeling. languages are numerous: concatenated attribute, composite
• Many experts consider data modeling to be the most important attribute, and data structure.
of the modeling techniques.

153
 • An entity typically has many instances; perhaps thousands or • A binary relationship has a degree = 2, because two different
SYSTEMS ANALYSIS

millions and there exists a need to uniquely identify each instance entities participated in the relationship.
based on the data value of one or more attributes. • Relationships may also exist between different instances of the
• Every entity must have an identifier or key. same entity.
• An key is an attribute, or a group of attributes, which assumes • This is called a recursive relationship (sometimes called a unary
a unique value for each entity instance. It is sometimes called an relationship; degree = 1).
identifier. • Relationships can also exist between more than two different
• Sometimes more than one attribute is required to uniquely entities.
identify an instance of an entity. • These are sometimes called N-ary relationships.
• A group of attributes that uniquely identifies an instance of an • A relationship existing among three entities is called a 3-ary or
entity is called a concatenated key. Synonyms include composite ternary relationship.
key and compound key.
• An N-ary relationship maybe associated with an associative
• Frequently, an entity may have more than one key. entity.
• Each of these attributes is called a candidate key. • An associative entity is an entity that inherits its primary key
• A candidate key is a ‘candidate to become the primary identifier’ from more than one other entity (parents). Each part of that
of instances of an entity. It is sometimes called a candidate concatenated key points to one and only one instance of each
identifier. (Note: A candidate key may be a single attribute or a of the connecting entities.
concatenated key.)
Foreign Keys
• A primary key is that candidate key which will most commonly • A relationship implies that instances of one entity are related
be used to uniquely identify a single entity instance.
to instances of another entity.
• Any candidate key that is not selected to become the primary • To be able to identify those instances for any given entity, the
key is called an alternate key. primary key of one entity must be migrated into the other
• Sometimes, it is also necessary to identify a subset of entity entity as a foreign key.
instances as opposed to a single instance. • A foreign key is a primary key of one entity that is contributed
• For example, we may require a simple way to identify all male to (duplicated in) another entity for the purpose of identifying
students, and all female students. instances of a relationship. A foreign key (always in a child
• A subsetting criteria is a attribute (or concatenated attribute) entity) always matches the primary key (in a parent entity).
whose finite values divide all entity instances into useful subsets. • When you have a relationship that you cannot differentiate
Some methods call this an inversion entry. between parent and child it is called a non-specific relationship.
Relationships • A non-specific relationship (or many-to-many relationship) is
• Conceptually, entities and attributes do not exist in isolation. one in which many instances of one entity are associated with
many instances of another entity. Such relationships are suitable
• Entities interact with, and impact one another via relationships only for preliminary data models, and should be resolved as
to support the business mission.
quickly as possible.
• A relationship is a natural business association that exists • All non-specific relationships can be resolved into a pair of
between one or more entities. The relationship may represent
one-to-many relationships by inserting an associative entity
an event that links the entities, or merely a logical affinity that
between the two original entities.
exists between the entities.
• A connecting line between two entities on an ERD represents Generalization
a relationship. • Generalization is an approach that seeks to discover and exploit
• A verb phrase describes the relationship. the commonalties between entities.
• All relationships are implicitly bidirectional, meaning that they • Generalization is a technique wherein the attributes that are
can interpreted in both directions. common to several types of an entity are grouped into their
own entity, called a supertype.
Cardinality
• An entity supertype is an entity whose instances store attributes
• Each relationship on an ERD also depicts the complexity or that are common to one or more entity subtypes.
degree of each relationship and this is called cardinality.
• The entity supertype will have one or more one-to-one
• Cardinality defines the minimum and maximum number of relationships to entity subtypes. These relationships are
occurrences of one entity for a single occurrence of the related sometimes called IS A relationships (or WAS A, or COULD
entity. Because all relationships are bi-directional, cardinality BE A) because each instance of the supertype ‘is also an’ instance
must be defined in both directions for every relationship. of one or more subtypes.
Degree • An entity subtype is an entity whose instances inherit some
• The degree of a relationship is the number of entities that common attributes from an entity supertype, and then add
participate in the relationship. other attributes that are unique to an instances of the subtype.

154
• An entity can be both a supertype and subtype. • A complete data model can be fit on a single sheet of paper.

SYSTEMS ANALYSIS
• Through inheritance, the concept of generalization in data Process models often require dozens of sheets of paper.
models permits the the reduction of the number of attributes • Process modelers too easily get hung up on unnecessary detail.
through the careful sharing of common attributes.
Data Modeling During Systems Analysis
• The subtypes not only inherit the attributes, but also the data • Many analysts report that data models are far superior for
types, domains, and defaults of those attributes. the following reasons: (continued)
• In addition to inheriting attributes, subtypes also inherit • Data models for existing and proposed systems are far more
relationships to other entities. similar than process models for existing and proposed systems.
The Process of Logical Data Modeling Consequently, there is less work to throw away as you move
into later phases.
Strategic Data Modeling
• A study phase model should include only entities
• Many organizations select application development
relationships, but no attributes – a context data model.
projects based on strategic information system plans.
• Strategic planning is a separate project.
• The intent is to refine the understanding of scope; not to get
into details about the entities and business rules.
• This project produces an information systems strategy plan
• The definition phase data model will be constructed in at
that defines an overall vision and architecture for information
least two stages:
systems.
• Almost always, the architecture includes an enterprise data • A key-based data model will be drawn.
model. • This model will eliminate non-specific relationships, add
• An enterprise data model typically identifies only the most associative entities, include primary, alternate keys, and foreign
fundamental of entities. keys, plus precise cardinalities and any generalization hierarchies.
• A fully attributed data model will be constructed.
• The entities are typically defined (as in a dictionary) but they are
not described in terms of keys or attributes. • The fully attributed model includes all remaining descriptive
attributes and subsetting criteria.
• The enterprise data model may or may not include
relationships (depending on the planning methodology’s • Each attribute is defined in the repository with data types,
standards and the level of detail desired by executive domains, and defaults.
management). • The completed data model represents all of the business
• If relationships are included, many of them will be non-specific. requirements for a system’s database.
Looking Ahead to Systems Configuration and
• The enterprise data model is usually stored in a corporate
Design
repository.
• The logical data model from systems analysis describes
Data Modeling During Systems Analysis business data requirements, not technical solutions.
• The data model for a single system or application is usually
• The purpose of the configuration phase is to determine
called an application data model.
the best way to implement those requirements with
• Logical data models have a Data focus and a System database technology.
User perspective.
• During system design, the logical data model will be
• Logical data models are typically constructed as transformed into a physical data model (called a database
deliverables of the study and definition phases of a schema) for the chosen database management system.
project.
• This model will reflect the technical capabilities and limitations
• Logical data models are not concerned with of that database technology, as well as the performance tuning
implementation details or technology, they may be requirements suggested by the database administrator.
constructed (through reverse engineering) from existing • The physical data model will also be analyzed for adaptability
databases. and flexibility through a process called normalization.
• Data models are rarely constructed during the survey phase
Fact-Finding and Information Gathering for Data
of systems analysis.
Modeling
• Data modeling is rarely associated with the study phase
• Data models cannot be constructed without appropriate
of systems analysis. Most analysts prefer to draw process
facts and information as supplied by the user community.
models to document the current system.
• Many analysts report that data models are far superior for the • These facts can be collected by a number of techniques such as
following reasons: sampling of existing forms and files; research of similar systems;
surveys of users and management; and interviews of users
• Data models help analysts to quickly identify business and management.
vocabulary more completely than process models.
• The fastest method of collecting facts and information, and
• Data models are almost always built more quickly than process simultaneously constructing and verifying the data models is
models. Joint Application Development (JAD).

155
 Computer-Aided Systems Engineering (CASE) for careful approach is more important. However, for simple systems,
SYSTEMS ANALYSIS

Data Modeling it is not necessary to go through all the listed steps. Experienced
• Data models are stored in the repository. analysts need to have their own assessment of the complexity of
the system in every specific case.
• In a sense, the data model is metadata – that is, data about the
business’ data. Identifying attributes
• Computer-aided systems engineering (CASE) technology, In order to identify all the details of attributes of entities necessary
provides the repository for storing the data model and its for the system, an analyst can rely on the following resources:
detailed descriptions. · Interviewing users; (for example, what information the
• Using a CASE product, you can easily create professional, system has to store to control magazines in a library);
readable data models without the use of paper, pencil, erasers, · Examining report forms and other documents frequently
and templates. used in the field under question;
• The models can be easily modified to reflect corrections and · Based on analysts’ experience and knowledge in the field
changes suggested by end-users. under question, estimation or intuitional identification of
• Most CASE products provide powerful analytical tools that attributes is formed.
can check your models for mechanical errors, completeness, As thus, for every type of entity in the data model, analysts will
and consistency have to provide a list of projected attributes. At first, a number of
• All Case products support not all data model attributes can be seen as belonging to many entities, but they need
conventions. to be put in suitable lists. This issue will be studied at a later stage
of the process with the help of normalization techniques.
• It is very likely that any given CASE product may force the
company to adapt their methodology’s data modeling symbols In the example of library management system, professional rule
or approach so that it is workable within the limitations of analysis gives the following outcomes:
their CASE tool. 1. The library manages two main kinds of document books and
magazines.
Strengthening of information structure -
relationship model 2. Each book has a distinct number (for example FV9550). In
case there are more than one book with the same book name,
This part discusses detailed analysis of system information to
they still have distinct book numbers, because they may be
confirm and develop the approach discussed earlier. This part will
received at different times, from different suppliers, and the
also discuss techniques including normalization to create a well-
librarian cannot be sure whether that book was in the library or
structured model.
not.
In this methodology, relationship model is used as a data modeling
The way of building distinct number for a book depends on its
process in order to test, improve and expand the constructed data
language (exactly on 3 systems of language: Latin (F), Slav (S), and
model. Relationship model defines a list of all the attributes to
Vietnamese (VN)); size of that book (divide into 3 sides: Large
every table of entity of the data model. Depending on the
(L); Medium (V); and Small (N)), and on the number of books
supporting tool that analysts use, the attributes form a unique
on the library. For example: with number FV9550, if the book is
name of the table marked as a key attribute.
written in English (Latin language), the size of the book is Medium
The process of creating a relationship model and using it to test (V), and there were 9549 books in the library.
data model, includes the following main steps:
All information about books is stored in a book table, which
1. Define the necessary attributes in the to-be-built system; includes a list of attributes:
2. Define the type of entity suitable to attributes to limit copying
and data redundancy (normalization technique);
3. Define the potential relationships within the lists of established
attributes for every entity by choosing linking attributes. All
linking attributes express the multiple of the one - multiple
relationship;
4. With known attributes, types of entity and relationship, it is
possible to construct a scheme similar to intuition data model.
Based on this, a model with the most suitable features is
selected.
5. After the selection of a data model with the best form to
perform system requirements, comes the estimation of the
quantity of entity for every table via relationship normalization
and this is also done through model.
Despite the possibly time-consuming nature of the
implementation of the above steps, efficiency brought over by a

156
 5. The library manages readers as follows: In the Institute, there

SYSTEMS ANALYSIS
List of attributes Type of Comment are many departments, sub-departments, and in each
attributes
BOOK_NO Character Number of the book (must have) department, there are also many staffs who are readers of the
BOOK_NAME Character Name of the book (must have)
BOOK_VOL Number Volume of book (may have) library.
SIZE Character Size of the book (must have)
TIME_PUBL Number Publish time (may have) When a new staff wants to become a reader of the library, a
YEAR_PUBL Number Publish year (may have) librarian will check if the department (which the staff is working
PUB_HOUSE Character Publish house (may have)
COST Number Cost of the book (may have) in) is in the list of institute departments or not. If it is not, firstly,
AUTHOR Character Author(s) (must have) the librarian has to register that new department, and then register
CHIEF_AUTH Character Chief author (may have)
COMP_AUTH Character Compiler author (may have) the number of staff, this number will be the reader_number and
REV_AUTH Character Revise author (may have)
LANG_NO Character Language number(ISO) (must will be given back to the staff.
LANG_NAME Character have)
LANG_VN Character Language name(ISO) (must have) 6. When a reader wants to borrow a document, he (or she) has to
LANG_SYS Character Language name(in VN) (must look up the number of that document on the library cards
NATION_NO Character have)
NATION_NAME Character Language system(ISO) (must (depend on the finding fields), then he (or she) has to write the
NATION_VN Character have) number of document if it is a book, or the number of
SPEC_NO Character National number(ISO) (must
SPEC_NAME Character have) document and its volume (year, month, number), if it is a
COLL_NO Character National name(ISO) (must have)
COLL_NAME Character National name(in VN) (must magazine, down in a Borrowing ticket. And then he (or she)
KW_MASTER Character have) asks the librarian for borrowing that document. All information
KW_SLAVE Character Speciality number (must have)
COMMENT Character Speciality name (must have) in the borrowing ticket is stored in a borrowing/returning
Collection number (must have) ticket table which includes a list of attributes:
Collection name (must have)
Master Keyword (may have)
Slave Keyword (may have) If the document is a book
Comment (may have)

List of attributes Type of Comment

3. The library lists the magazines regularly by volume, by number attributes
or month, by quarter of year, or by year (it depends on publish READER_NO Character Reader number (must have)
cycle of each magazines). The library manages 3 kinds of
READER_NAME Character Reader name (may have)
magazines:
Information (TIN) magazines, Mathematics (TH) magazines, and BOOK_NO Character Book number (must have)
technical (KT) magazines. Each magazine category has a distinct
number, and each volume of one magazine category also has a BOOK_NAME Character Book number (may have)
distinct number. All information about magazine is stored in a
magazine table which includes a list of attributes: BORROW_DATE Date Borrowing date (must have)

List of attributes Type of Comment RETURN_DATE Date The date that has to return
attributes
(may have)
MAG_HEAD_NO Character Magazine header number (must have)
MAG_DETL_NO Character Magazine detail number (must have) COMMENT Character
MAG_NAME Character Magazine name (must have) Comment
START_YEAR Number Having since (must have)
MAG_SHEFL Character Where put magazine in Lib(must have)
ISSN_NO Character ISSN number (may have)
PUB_HOUSE Number Publish house
LANG_NO Character Language number(ISO) (must have)
LANG_NAME Character Language name(ISO) (must have)
LANG_VN Character Language name(in VN) (must have)
LANG_SYS Character Language system(ISO) (must have)
NATION_NO Character National number(ISO) (must have)
NATION_NAME Character National name(ISO) (must have)
NATION_VN Character National name(in VN) (must have)
SPEC_NO Character Speciality number (must have)
SPEC_NAME Character Speciality name (must have)
COLL_NO Character Collection number (must have)
COLL_NAME Character Collection name (must have)
YEAR Number Year of volume (may have)
VOLUME Number volume (may have)
NUMBER Number number of volume (may have)
MONTH Number month of volume (may have)
QUANTITY Number quantity of volume (may have)
COMMENT Character comment about volume (may have)

4. A new documents will be registered in the finding fields (for

readers to look up) in the library card.

157
 If the document is a magazine Bennett, Simon
SYSTEMS ANALYSIS

Object-Oriented systems Analysis and

Design using UML
List of attributes Type of Comment 2nd ed. New Delhi : McGraw Hill Book, 2002
attributes
Booch, Grady
READER_NO Character Reader number (must have)
Object-oriented Analysis and
Design : with Applications
READER_NAME Character Reader name (may have)
2nd ed. Reading : Addison-Wesley Publishing, 2000
MAG _NO Character Magazine number (must Hoffer, Jeffrey A.
have) Modern systems Analysis and Design
MAG _NAME Character 2nd ed. Delhi : Pearson Education Asia, 2000
Magazine name (may have) Kain, Richard Y.
VOLUME Number Advanced computer Architecture :
Magazine volume (may have) a systems Design Approch
NO Number New Delhi : Prentice Hall of India, 1996
Magazine no (may have)
Sima, Dezso
YEAR Number Advanced computer Architectures :
Magazine year (may have) a Design space Approch
MONTH Number Delhi : Pearson Education Asia, 1997
Magazine month (may have)
Sarkar, A.K.
BORROW_DATE Date
Systems Analysis, Data processing and
Borrowing date (must have)
Quantitative Techniques
RETURN_DATE Date
The date that has to return New Delhi : Galgotia Publications, 1997
COMMENT Character (may have) Hawryszkiewycz, Igor
Introduction to systems Analysis & Design
Comment 4th ed. New Delhi : Prentice Hall of India, 2002
Awad, Elias M.
With the Borrowing ticket: the librarian has to check whether the Systems Analysis and Design
document is in the library or not. If it is still in, the librarian will New Delhi : Galgotia Publications, 1997
fill information in all fields that has been enumerated in the tables
above, otherwise, the librarian has to refuse to lend the requested
book.
With the Returning ticket: the librarian only has to receive document
and check the reader number, document number in the
Borrowing/Returning ticket table and deletes it.
7. At the end of each month, or each year, librarians have to
report the document situation in the library, the borrowing,
returning documents of all departments in the institute and
the list of readers who have been keeping document overdue
References
Heuring, Vincent P.
Computer systems Design and Architecture
Delhi : Pearson Education Asia, 1997
Whitten, Jeffrey L.
Systems Analysis and Design methods
5th ed. New Delhi : Galgotia Publications, 2001
Shelly, Gary B.
Systems Analysis and Design
3rd ed. New Delhi : Galgotia Publications, 1999

158
 SYSTEMS ANALYSIS
LESSON 34 :
NORMALIZATION

Topics Covered The first normal form

• Normalization Dictates that every attribute must have a single value for any
occurrence of its entity at any one point in time. Also, a relation is
Objectives in 1NF if, and only if, it contains no repeating groups.
Upon completion of this Lesson, you should be able to: To be qualified for 2NF which only applies to composite primary
• Explain about normalization keys, every attribute of an entity must depends on the entire
Determining types of entities identifier of its entity or its value. A relation is in 2NF if, and only
(normalization) if: it is in 1NF and every non-key attribute is dependent on all
parts of the primary key.
Normalization is a process of surveying lists of
The solutions for both 1NF and 2NF are a non-loss
attributes and applying a range of analysis
decomposition that involves removing the repeating group and
principles to the lists in order to make them meet
taking its determinant with it.
the following
The nature of the 1NF is to eliminate all repeating groups in a list.
• Minimization of repetition;
By doing this, the key of the table at a higher level will be passed
• Avoidance of redundancy; over to the newly created table of the entity because there is one-
• Elimination of ambiguity. many relationship between two types of entity and the key is
Repetition is the case when one attribute appears in many entity considered as a linking attribute. The new entity then will be studied
tables. It only occurs to identifying and connection attributes and to find a key to it.
is essential in expressing relationships. To go from 1NF to 2NF, the analyst must remove any partially
Redundancy can be a non-key attribute in many tables or it can dependent attributes from their 1NF entity and create a new entity.
point to inferred data. Attributes with values resulted from simple After that, copy that part of the identifier of the original entity (on
calculation done with other attributes need to be eliminated from which the removed attributes are dependent) into the new entity.
the model. This will probably become part of the unique identifier of the
new entity.
Ambiguity can happen when meanings of attributes are not
expressed clearly to groups of users. Normalization process helps The second normal form (2NF)
analysts study the meaning of every attribute and the relationship Every attribute must depend on the entire identifier of its entity
model can only be built when a thorough understanding of every for its value. 2NF only applies to composite primary keys: a relation
attribute is achieved. This process is carried out with the help of is in 2NF if, and only if: it is in 1NF and every non_key attribute is
“functional dependence” definition (or diagrams). dependent on all part s of the primary key. The solution is again a
Function Dependence defines a relationship between a pair of non-loss decomposition that removing the attribute involved
fields in each record. In a relation including two attributes A and and taking its determinant with it.
B, B is said to be functionally dependent on A if, for every valid To move from 2NF to 3NF, the analyst must remove all
occurrence, the value of A determines the value of B. independent attributes and put them in an entity of their own.
In general, with every value of key at any point in time, a table Note that this new entity will now need a unique identifier and is
should have only one value. If an attribute is not functionally subject to the previous steps.
dependent on key, it should be in another table. From all this, a Third normal form (3NF)
fully normalized model is the one in which every attribute in the A relation is in 3NF if , and only if: it is in 2NF, and no non_key
entity table has a Function Dependence relationship to the table’s attribute is functionally dependent on another non-key attribute.
key attributes. This means that, every attribute must not depend on anything
To carry out normalization, the first task is to select a key for a list except the unique identifier of its entity for a value.
of all attributes of an entity. The key includes one or more Once Again
attributes capable of providing a unique name for every row in a
• Remove the offending attributes
table: no two entities in a type of entity have the same key.
• Take the determinant along
Let’s consider the list of attributes of an entity table put together
by an analyst is non-standard (0NF) at the beginning stage. The • The resulting relation is in 3NF
next level of the list will be the first normal form (1NF). • The initial objective has now been reached, each non-key
attribute depends only (and fully) upon the primary key.

159
 3NF is often reached in practice by inspection, in a single step. Its the other attributes are dependent on this key, so this table has
SYSTEMS ANALYSIS

meaning seems intuitively clear; it represents a formalization of been in the second normal form. The Lang_Name (language
designer’s common sense. This level of normalization is widely name), the Lang_Vn (language name in Vietnamese) and the
accepted as the initial target for a design which eliminates Lang_Sys (language system) are only dependent on one attribute:
redundancy. the Lang_No, so we have to normalize them to the third normal
The characteristic of 3NF is the removal of non-key attribute. form. Similarly with the Nation_Name , the Nation_VN depends
This means that attributes dependent on non-key attribute will on only one attribute: the Nation_No; the Spec_Name depends
be removed from the list of entities and make up a new key entity on only one attribute: the Spec_No; the Coll _Name depends on
type, which is the said, removed non-key attribute. only one attribute: the Coll _No. We have the following table: (the
attribute underlined is the primary key).
In fact, there are cases where 2 or more 3NF tables of a list of
attributes of all entities are put together into one table, the merged
table is still 2NF. This is not surprising because the merged table
may contain a group of non-key attributes, which had never been List of attributes 1NF 2NF 3NF
considered together, and they may contain one non-key dependency. BOOK_NO BOOK_NO BOOK_NO BOOK_NO
BOOK_NAME BOOK_NAME BOOK_NAME BOOK_NAME
Thus, after grouping the tables together, it’s necessary to take SIZE SIZE SIZE SIZE
3NF. TIME_PUBL TIME_PUBL TIME_PUBL TIME_PUBL
YEAR_PUBL YEAR_PUBL YEAR_PUBL YEAR_PUBL
In fact, there are some other normal forms that are not widely PUB_HOUSE PUB_HOUSE PUB_HOUSE PUB_HOUSE
used. In system analysis, analysts often use a table in 3NF. COST COST COST COST
AUTHOR AUTHOR AUTHOR AUTHOR
To finish the normalization, analyst must double-check the CHIEF_AUTH CHIEF_AUTH CHIEF_AUTH CHIEF_AUTH
COMP_AUTH COMP_AUTH COMP_AUTH COMP_AUTH
following points:
REV_AUTH REV_AUTH REV_AUTH REV_AUTH
• Is each entity in 0NF, 1NF, 2NF or 3NF? LANG_NO LANG_NO LANG_NO LANG_NO
LANG_NAME LANG_NAME LANG_NAME NATION_NO
• Check optionality of relationships. LANG_VN LANG_VN LANG_VN SPEC_NO
LANG_SYS LANG_SYS LANG_SYS COLL _NO
• Make sure that no two entities have the same unique identifier NATION_NO NATION_NO NATION_NO KW_MASTER
i.e., they are the same thing. NATION_NAME NATION_NA NATION_NA KW_SLAVE
NATION_VN ME ME COMMENT
• Remove “attributes” which are really M to 1 relationships. In SPEC_NO NATION_VN NATION_VN
short, to normalize, analysts must finish the following steps: SPEC_NAME SPEC_NO SPEC_NO LANG_NO
COLL_NO SPEC_NAME SPEC_NAME LANG_NAME
• Create a list of data items. COLL_NAME COLL_NO COLL _NO LANG_VN
KW_MASTER COLL _NAME COLL _NAME LANG_SYS
• Identify derived items. KW_SLAVE KW_MASTER KW_MASTER
COMMENT KW_SLAVE KW_SLAVE NATION_NO
• Choose a unique identifier (a “key”). COMMENT COMMENT NATION_NA
ME
• Remove repeating groups for that key (and copy across original NATION_VN
key).
SPEC_NO
• Remove “part - key” dependencies (and copy across that part SPEC_NAME
of the original key).
COLL _NO
• Remove non-key dependencies. COLL _NAME
• Bring together data items with the same key.
When a list of entities does not reach any of the above normal
forms, it is necessary to remove one or more attributes inside it,
and create more entities to replace. This means that analysts can
start with a list of planned attributes for an entity type, after going
through the 3 normal forms, (s)he can decide to give some of the
attributes in the list to other types of entity.
At the end of the normalization, the analyst has not only original
entity but also newly defined entity and they all have been fully
normalization.
In the example of library management system, the
normalization process is as follows
It is clear that any book or magazine must be published in a
language but one language can be used in different documents,
thus the relationship between book or magazine with language is
a one – many relationship. The same one – many relationship is
seen between a document and publishing country...
Firstly, we start with the book table: As we see , the book table has
no repeating group and has only one primary key: Book_No, all

160
Secondly, we normalize the reader table with its

SYSTEMS ANALYSIS
attributes and have this table
List of attributes 1NF 2NF 3NF
MAG_HEAD_NO MAG_HEAD_NO MAG_HEAD_NO MAG_HEAD_NO
List of attributes 1NF 2NF 3NF MAG_DETL_NO MAG_NAME MAG_NAME MAG_NAME
READER_NO READER_NO READER_NO READER_NO MAG_NAME START_YEAR START_YEAR START_YEAR
START_YEAR MAG_SHEFL MAG_SHEFL MAG_SHEFL
READER_NAME READER_NAME READER_NAME READER_NAME MAG_SHEFL ISSN_NO ISSN_NO ISSN_NO
ISSN_NO PUB_HOUSE PUB_HOUSE PUB_HOUSE
PUB_HOUSE LANG_NO LANG_NO LANG_NO
ADDRESS ADDRESS ADDRESS DEPT_NO
LANG_NO LANG_NAME LANG_NAME NATION_NO
LANG_NAME LANG_VN LANG_VN SPEC_NO
BIRTH_DATE BIRTH_DATE BIRTH_DATE ADDRESS LANG_VN LANG_SYS LANG_SYS COLL_NO
LANG_SYS NATION_NO NATION_NO COMMENT
DEPT_NO DEPT_NO DEPT_NO BIRTH_DATE NATION_NO NATION_NAME NATION_NAME
NATION_NAME NATION_VN NATION_VN LANG_NO
DEPT_NAME DEPT_NAME DEPT_NAME COMMENT NATION_VN SPEC_NO SPEC_NO LANG_NAME
SPEC_NO SPEC_NAME SPEC_NAME LANG_VN
COMMENT COMMENT COMMENT SPEC_NAME COLL_NO COLL_NO LANG_SYS
COLL_NO COLL_NAME COLL_NAME
DEPT_NO COLL_NAME COMMENT COMMENT NATION_NO
YEAR NATION_NAME
DEPT_NAME VOLUME MAG_HEAD_NO MAG_HEAD_NO NATION_VN
NUMBER MAG_DETL_NO MAG_DETL_NO
MONTH YEAR YEAR SPEC_NO
QUANTITY VOLUME VOLUME SPEC_NAME
COMMENT NUMBER NUMBER
MONTH MONTH COLL_NO
QUANTITY QUANTITY COLL_NAME
Thirdly, we normalize the book ticket_L&GB table
MAG_HEAD_NO
with its attributes MAG_DETL_NO
YEAR
VOLUME
NUMBER
MONTH
List of attributes 1NF 2NF 3NF
QUANTITY
READER_NO READER_NO READER_NO READER_NO

READER_NAME READER_NAME BOOK_NO BOOK_NO

BOOK_NO BOOK_NO BORROW_DATE BORROW_DATE

BOOK_NAME BOOK_NAME RETURN_DATE RETURN_DATE And the magazine ticket_L&GB table with its
attributes
BORROW_DATE BORROW_DATE COMMENT COMMENT

RETURN_DATE RETURN_DATE

COMMENT COMMENT READER_NO READER_NO List of attributes 1NF 2NF 3NF

READER_NO READER_NO READER_NO READER_NO
READER_NAME READER_NAME MAG_HEAD_NO
READER_NAME READER_NAME READER_NAME
MAG_DETL_NO
MAG_HEAD_NO MAG_HEAD_NO MAG_HEAD_NO
BOOK_NO BOOK_NO BORROW_DATE
MAG_DETL_NO MAG_DETL_NO MAG_DETL_NO
BOOK_NAME BOOK_NAME RETURN_DATE
MAG_NAME MAG_NAME MAG_NAME
COMMENT
YEAR YEAR YEAR

VOLUME VOLUME VOLUME

READER_NO
And then, the magazine table, we realize that, the list of attributes NUMBER NUMBER NUMBER
has a repeating group, it includes these attributes: Mag_head_no, READER_NAME
MONTH MONTH MONTH
mag_name, start_year, mag_shefl, issn_no, pub_house, lang_no, MAG_NAME
lang_name, lang_vn, lang_sys, nation_no, nation_name, BORROW_DATE BORROW_DATE QUANTITY
nation_vn, spec_no, spec_name, coll_no, coll_name, and YEAR
RETURN_DATE RETURN_DATE BORROW_DATE
comment, so we decompose it into a new table with a primary VOLUME
key: Mag_head_no without data loss. The remaining attributes COMMENT COMMENT RETURN_DATE
NUMBER
(mag_head_no, mag_detl_no, year, volume, number, month, COMMENT
quantity) are put in another table with a primary key including 2 MONTH
attributes: Mag_head_no, mag_detl_no. And we have the below
table

161
 References:
SYSTEMS ANALYSIS

Heuring, Vincent P.
Computer systems Design and Architecture
Delhi : Pearson Education Asia, 1997
Whitten, Jeffrey L.
Systems Analysis and Design methods
5th ed. New Delhi : Galgotia Publications, 2001
Shelly, Gary B.
Systems Analysis and design
3rd ed. New Delhi : Galgotia Publications, 1999
Bennett, Simon
Object-oriented systems Analysis and
Design using UML
2nd ed. New Delhi : McGraw Hill Book, 2002
Booch, Grady
Object-Oriented Analysis and
Design : with applications
2nd ed. Reading : Addison-Wesley Publishing, 2000
Hoffer, Jeffrey A.
Modern systems Analysis and Design
2nd ed. Delhi : Pearson Education Asia, 2000
Kain, Richard Y.
Advanced computer Architecture :
a systems Design Approch
New Delhi : Prentice Hall of India, 1996
Sima, Dezso
Advanced computer Architectures :
a Design space Approch
Delhi : Pearson Education Asia, 1997
Sarkar, A.K.
Systems Analysis, Data processing and
Quantitative Techniques
New Delhi : Galgotia Publications, 1997
Hawryszkiewycz, Igor
Introduction to systems Analysis & Design
4th ed. New Delhi : Prentice Hall of India, 2002
Awad, Elias M.
Systems analysis and design
New Delhi : Galgotia Publications, 1997
Notes

162
 SYSTEMS ANALYSIS
LESSON 35 :
INFORMATION ANALYSIS

Topics Covered • Data flow diagram also concentrates on functions, but it

• Information analysis considers the necessary information to perform the related
duties.
Objectives
• Data model and relationship model have hardly anything to
Upon completion of this Lesson, you should be able to: do with functions, they concentrate to describe the system’s
• Discuss about information analysis information in different levels and the relationship among them.
Completion of information analysis Although each model has its own characteristic and objective, they
This part concludes the description of information analysis actually have a very close relationship with each other: These models
development. The material on the system analysis process describe are the basis for designing other models. Therefore, changes in
in detail tools and techniques used in analysis completion and any model may result in changes or adjustments to secure the
provide a special description of system requirements that users conformity among models.
can evaluate and accept. Supporting tools and materials
This special description also serves as the main information source
The major tools supporting the analysis process
for designers of the system because it explains not only the
include
purposes of the system but also its scope and requirements that
designers have to comply with. The main contents consist of: • Process Description
• Corporation of new requirements • Data dictionary
• Supporting tools and materials • Seminar (meeting)
• Summary of analysis process Process Description
Process description is actually detailize the system’s requirements
Corporation of new requirements
displayed in function diagram and data flow diagram.
In this lesson, we have discussed the approaches and supporting
tools for the system analysis process, especially the function and Some of the tools for process description are: block chart, decision
data analysis. By developing models, a system analyst defines the table, structured language... Of those tools, structured language
system’s requirements in most of the cases. (structured English) is considered one of the most useful and
popular tools for process description because it is simple for users
However, in some cases, new ideas or requirements in constraint,
and other members taking part in developing the system’s life
control, improvements arise from knowledgeable users or the
cycle. Structured language consists of:
requirements which are found by analysts during the surveying
phase. • Imperative verbs
Those requirements should be discussed and agreed in written • Technical terms defined in Data dictionary, relationship model
between users and analyst and should be treated as part of the or other models
surveying document and be presented in the system’s models. • Some logical words to make up sentences and structure
Normally, new requirements are added to the current model from The process must be described by using one of the 3 main
functional diagram and adjusted in other models if necessary. developed structures in structured programming: Orderly, selective
This adjustment must be done carefully to make sure that the and repetitive
model is simply designed. It should be noted that one new Orderly structure is simply description commands for a process to
requirement can be put into the system in different ways. It is then occur following another process.
the analyst’s duty to find the simplest and most suitable way from
Selective structure is used when a decision must be made during
the users’ perspective.
the process base on 2 or more selection possibilities. The basic
In fact, there are cases where the new system is not developed base structure of the commands is: If ... Then ... Else;
on any current system because the difference between the old and
the new system is so big that there is no need to model the old CASE...
system. The modeling of the new system is done with the Repetitive structure is used when there is a need to repeat a series
methods discussed in the previous parts of this materials of actions in the process. The basic structure of the commands is:
While analyzing the system, we can see that there are 4 main models For...do While...
making up requirement specification, each model is concerned to Thus, process description is not only useful in the analysis process
one aspect of the system. but is also used to describe the designing process of the physical
• Functional diagram shows the functions that the system will system and the programming process afterwards
have to perform, not how to perform.

163
 Dictionary has, right in the first place, give clear objectives of the seminar, fix
SYSTEMS ANALYSIS

With the development of Information Technology and the time slot for presenters and direct all the comments to the set
generation of professional software, data dictionary is becoming objectives.
more popular and important to those who is interested in system Secretary: who is responsible for taking notes of all the comments
development. and may be asked to summarize the discussed points. All decisions
Data dictionaries differ due to the different defining standards, made during the seminar must be noted down carefully.
different software and hardware environments, or different users. Presenters: who are responsible for making presentations as
However, regardless of different methodologies, data dictionaries approved by the coordinator. While presenting, make sure to give
must present simple explanations, the manner to record process’s everyone discussion opportunities. Don’t try to protect what you
names, the storage manner and how to search for detail have done. Consider other people including users attending the
information of the system. seminar are those who help analysts make clear of their own
This means a Data Diagram describes the data flows in a Data requirements. Any interviewers are expected to give constructive
Flow Diagram, the structure of data packages in flowing motion comments which can be a hint, a confirmation, an idea from the
as well as the data packages in storage. It also means the specification users’ perspective or just a clarification of requirements.
of value and unit of information inside the data flow and data
Summary of analysis process
storage, the specification of the information relationships between
This material has described in detail the tools and techniques that
storage inside the entity relationship diagram
are used to complete system analysis and give a requirement
The best way to develop a Data Diagram is to use automatic specification to users to review and approve. This specification is
means (professional programs for data dictionary development) also the main source of information for the new system designers.
to enter the dictionary’s entries, and to check the accuracy and It not only explains the system’s objectives but also gives a scale
suitability of the data put into the system. In case there is not an and limitations with which designers have to comply.
automatic means, analysts should use the traditional word
Thus, at the end of the system analysis phase, analysts have to
processing system to develop a text file for the data dictionary’s
give adequate material of system requirement specification which
entries
has been approved by users. The material should the name
In short, data dictionary development is very essential and time objectives, supporting tools and methods to do the following
consuming in system analysis, without it, the analysis outcomes things:
may become meaningless
Contents and scale of system analysis
Seminar Summary of management work
The seminar technique is a meeting where analysts present their Function diagram
work in different phases. It gives discussion opportunities to
users and the system development team (including analysts, Data flow diagram
designer and programmer) to improve shortcomings in the system Data model
before it is really approved. Presenters must prepare their Relationship model
presentation very carefully and talk about it in a simple, clear and Process description
short way.
Data dictionary
They also have to be aware that this is not a scientific seminar, and
that everything they present must be made easy to understand by The result of this phase is the 3 important diagrams: the Function
the users. The key to success of the seminar is the behavior of Hierarchy Diagram, the Data Flow Diagram, and the Entity
seminar attendees themselves: any criticism, comments shouldn’t Relationship Diagram. These diagrams are very important, we
be directed to any individual who owns the matter under cannot continue without them during the system building process.
discussion, they should be directed to the common work. They are inputs for the next phase: System Design.

Thus, seminar attendees are not expected to re-design the models Questions
(in their own opinions), they are expected to point out the weak Describe Structured Analysis. List certain tools of Structured
points and irrelevant parts and give suggestions to analysts for Analysis.
them to improve those parts. The Claremont school course catalog reads as follows: “ To enroll
In case there are serious mistakes, analysts should be asked to in CIS 288 which is an advanced course , a student must complete
submit it again after successfully correcting the mistakes. After all two prerequisites –CIS 110 and CIS 286. A student who completes
models have been tested and approved, system development either one of the prerequisites and obtains the instructor’s
teams should sign approve and consider the approved models a permission, however , will be allowed to take CIS 288.”
sound foundation for the following development steps. (i) Create a decision table that describes the Claremont School
In each seminar, attendees have to agree to the following roles: course regarding eligibility for CIS 288. Show all the possible
rules.
Coordinator: who is responsible for organizing the seminar;
sending seminar invitations and hand-outs to attendees and give (ii) Draw a decision tree to represent the Claremont School catalog.
them enough time to think of the issues that will be discussed in Describe the results.
the seminar. For the best outcome of the seminar, the coordinator (iii) Why might you use a decision tree rather than a decision table?

164
City Bus Lines is developing an information system that will References
monitor passenger traffic, peak travel hours and equipments Heuring, Vincent P.
requirements. The IT manager wants you to document a process Computer systems Design and Architecture
that will determine if extra buses are needed on a route and
Delhi : Pearson Education Asia, 1997
automatically assign them if all other routes are operating on
schedule. During peak periods, however a dispatcher will be Whitten, Jeffrey L.
allowed to override the system and shift buses from one route to Systems analysis and Design Methods
another. 5th ed. New Delhi : Galgotia Publications, 2001
(i) Create a decision table that describes the bus transfer process Shelly, Gary B.
(ii) Draw a decision tree that describes bus transfer process. Systems Analysis and Design
(iii) Name four attributes that u can use to define a data flow in the 3rd ed. New Delhi : Galgotia Publications, 1999
bus information system Bennett, Simon
(iv) Name four attributes that u can use to define a data store in Object-Oriented systems Analysis and
the bus information system design using UML
The Claremont school course catalog reads as follows: “ To enroll 2nd ed. New Delhi : McGraw Hill Book, 2002
in CIS 288 which is an advanced course , a student must complete Booch, Grady
two prerequisites –CIS 110 and CIS 286. A student who completes Object-oriented analysis and
either one of the prerequisites and obtains the instructor’s design : with applications
permission, however , will be allowed to take CIS 288.”
2nd ed. Reading : Addison-Wesley Publishing, 2000
(i) Create a decision table that describes the Claremont School
Hoffer, Jeffrey A.
course regarding eligibility for CIS 288. Show all the possible
Modern systems analysis and design
rules.
2nd ed. Delhi : Pearson Education Asia, 2000
(ii) Draw a decision tree to represent the Claremont School catalog.
Describe the results. Kain, Richard Y.
Advanced computer architecture :
(iii) Why might you use a decision tree rather than a decision table?
a systems design approch
State the difference between System design and New Delhi : Prentice Hall of India, 1996
Detailed design.
Sima, Dezso
1. What is structured design? Advanced computer architectures :
2. How do system analysis and design relate to each other? a design space approch
3. What are the main phases of the design process? Delhi : Pearson Education Asia, 1997
4. What are the main tools and design techniques? Sarkar, A.K.
5. What is logical design and its main tasks? Systems analysis, data processing and
6. What is physical design and its main tasks? Quantitative techniques
7. How do you distinguish between logical design and physical New Delhi : Galgotia Publications, 1997
design? Hawryszkiewycz, Igor
8. Why do you need to identify the borderline of the computer Introduction to systems analysis & design
system in the system DFD? How do you present them in the 4th ed. New Delhi : Prentice Hall of India, 2002
model?
Awad, Elias M.
9. What are the main components of computer-user interface Systems analysis and design
design?
New Delhi : Galgotia Publications, 1997
10. Why is it necessary to design system monitoring?
11. How do you organize the system’s components?
12. What are the main modeling tool and techniques?
13. What are the tools used in data usage analysis?
14. What is navigation model and its purpose?
15. What are the main components of a database and the role of
each component?
“The lesson content has been compiled from various sources in public domain including but not limited to the
internet for the convenience of the users. The university has no proprietary right on the same.”

Rai Technology University Campus

Dhodballapur Nelmangala Road, SH -74, Off Highway 207, Dhodballapur Taluk, Bangalore - 561204
E-mail: [email protected] | Web: www.raitechuniversity.in