EVELYN HONE COLLEGE OF APPLIED ARTS AND COMMERCE
BUSINESS STUDIES DEPARTMENT
COMPUTER SECTON
SYSTEMS ANALYIS AND DESIGN I
Business Systems Concepts
General business Theory
Systems theory attempts to describe and understand the common structure, attributes and emergent
properties of all types of systems - physical, biological and social - by viewing them as systems per se
rather than an economy or a business or a machine, for example.A systems theory of business intelligence
(BI) would position BI in the context of its surrounding system - the organizational environment in which it
operates - and would predict the impact of that context on BI design. This theory would give designers a
tool that guides them on what BI technology can do and what it cannot do in a given environment and the
risks involved.
A system is a set of components that interact to accomplish some common goal or purpose. Systems are
all around us. For example, the human body‟s nervous system is a set of parts including the brain, spinal
cord, nerves, and special sensitive cells under the skin that work together to make a person feel hot, cold,
itchy and so on. A business is also a system. Its components- marketing, manufacturing, sales,
accounting, e.t.c, all work together to create a profit that benefits the employees and stockholders of the
firm. Every business system depends on a more or less abstract entity called an information system.
This system is the means by which data flow from one person or department to another and can
encompass everything from interoffice mail and telephone links to a computer system that generates
periodic reports for various users. Information systems serve all the systems of a business, linking the
different components in such a way that they effectively work toward the same purpose.The components
that make up systems may actually be made up of smaller systems; that is, systems may be made up of
levels of systems called subsystems.
Compiled by Ms. R. Lupyani
Page 1
The system‟s purpose is its reason for existing. A legislative system, for example, exists to study problems
facing voters and citizens and to pass legislation that eliminates those problems. To achieve their
purposes, some systems interact with their environment, which are any entities outside the boundaries of
the systems, while others do not.
Open System: this is a system that interacts with the environment. They receive inputs from the
environment and produce output.
Closed System: this is a system that does not interact with the environment. It is a self contained system.
All systems are open, closed systems exist only in concept, but are equally important.
Control: This is involves ensuring that a system is operating according to an acceptable level of
performance.The element of control is related to whether systems are open or closed. Systems work best
or are in control when they operate within tolerable performance levels. For example, people function best
when their body temperature is 98.6 degrees Fahrenheit. A slight deviation from 98.6 to 99.0 degrees
probably will not affect performance too much, although some difference may be noticeable. However, a
higher deviation, such as a 103 –degree fever, will change bodily functioning drastically. The system will
run down and be sluggish until the condition is corrected. If the condition continues too long, the result can
be fatal to the system. This example demonstrates the importance of control in systems of every type. All
systems have acceptable levels of performance, called Standards, against which actual performances are
compared. Activities too far above or below standards should be noted so that adjustments can be made.
The information supplied by comparing results with standard and informing the control elements of the
differences is termed feedback.
Systems use a basic control model consisting of:
1.
2.
3.
4.
A standard for acceptable performance.
A method of measuring actual performance.
A means for comparing actual performance against the standard.
A method for feedback.
Systems that can adjust their activities to acceptable levels continue to function. Those that cannot,
eventually stop. The concept of interaction with the environment, which characterizes open systems, is
essential for control. Receiving and evaluating feedback allows a system to determine how well it is
operating. If a business, for example, produces as output products or services that are high priced and of
low quality, people probably will not continue to buy them. Low sales figures are feedback, telling
management it needs to adjust the products and the way they are produced to improve performance and
bring it into line with expectations.
In contrast, closed systems sustain their operations only as long as they have adequate regulatory
information and do not need anything from the environment. Since this condition cannot exist for long,
there are no closed systems. The concept is important, however, because it demonstrates a systems
design objective: to build systems that need as little outside intervention as possible to maintain acceptable
performance. Self-regulation and Self-adjustment, therefore, are design objectives in all system
environments.
Compiled by Ms. R. Lupyani
Page 2
EVELYN HONE COLLEGE OF APPLIED ARTS AND COMMERCE
BUSINESS STUDIES DEPARTMENT
COMPUTER STUDIES SECTION
SYSTEMS ANALYSIS AND DESIGN I
Systems Analysis and Design
In business, systems analysis and design refers to the process of examining a business situation with the
intent of improving it through better procedures and methods. This section overviews systems analysis and
design and describes the work of systems analysts and the different types of users that participate in the
development process.
Systems development can generally be thought of as having two major components:


Systems Analysis is the process of gathering and interpreting facts, diagnosing problems, and
using the information to recommend improvements to the system.
Systems Design is the process of planning a new system or one to replace or compliment an
existing system. But before this planning can be done, the old system must be understood and
determine how computers can be best used (if at all) to make its operation more effective.
Consider, for example, the stockroom operations of a clothing store. To better control its inventory and
gain access to more up-to-date information about stock levels and reordering, the store asks a systems
analyst to computerize its stockroom operations. Before the analyst can design a system to capture data,
update files, and produce reports, the analyst needs to know more about how the store currently operates:
What forms are being used to store information manually, such as requisitions, purchasing
Compiled by Ms. R. Lupyani
Page 3
Systems analysts do more than solve current problems. They are frequently called upon to help handle the
planned expansion of a business. In the case of the clothing store, the systems study is future-oriented,
since no system currently exists. Analysts assess as carefully as possible what the future needs of the
business will be and what changes should be considered to meet these needs. In this instance and in most
others, analysts may recommend alternatives for improving the situation. Usually more than one strategy is
possible.
Working with managers and employees in the organization, systems analysts recommend which alternative
to adopt, based on such concerns as the suitability of the solution to the particular organization and setting,
as well as the employee support the solution is likely to have. Sometimes the time required to develop one
alternative, compared with others, is the most critical issue. Costs and benefits are also important
determinants. In the end, management, which will pay for and use the result, actually decides which
alternative to accept. Once this decision is made, a plan is developed to implement the recommendation.
The plan includes all systems design features, such as new data capture needs, file specifications,
operating procedures, and equipment and personnel needs. The systems design is like the blueprint for a
building: it specifies all the features that are to be in the finished product.
Analysis specifies what the systems should do. Design states how to accomplish the objective. Each of
the processes mentioned involve people. Managers and employees have good ideas about what works
and what does not, about what flows smoothly and what causes problems, about where change will be
needed and where it is not. Keys that make the organizations work. Thus, communicating and dealing
with people are very important parts of the systems analyst‟s job.
WHAT SYSTEMS ANALYSIS IS NOT
Systems analysis has been defined but it is also important to know what systems analysis is NOT.

It is NOT:
Studying a business to see which existing processes should be handled by computer and which
should be done by non-computerized methods. The emphasis is on understanding the details of a
situation and deciding whether improvement is desired or feasible. The selection of computer and
non computer methods is secondary.

It is NOT:
Determining what changes should be made. The intent of the systems investigation is to study a
business process and evaluate it. Sometimes, not only is change not needed, it is not possible.
Change should be a result, not an intent.
Compiled by Ms. R. Lupyani
Page 4

It is NOT:
Determining how best to solve an information systems problem. Regardless of the organization,
the analyst works on business problems. It would be a mistake to distinguish between business
and systems problems, since there are no systems problems that are not first business problems.
Any suggestion should be considered first in light of whether it will improve or harm the business.
Technically attractive ideas should not be pursued unless they will improve the business system.
Roles of the Systems Analyst
The responsibilities of analysts, as well as their titles, vary among organizations. Listed below are the most
common sets of responsibilities assigned to systems analysts.
1. Systems Analysis Only: the analyst‟s sole responsibility is conducting systems studies to learn
relevant facts about a business activity. The emphasis is on gathering information and determining
requirements. Analysts are not responsible for systems design. (Information Analysts)
2. Systems Analysis and design. Analysts carry out complete systems studies but have the added
responsibility of designing the new system. People who are responsible for both systems analysis
and design work on fewer projects than information analysts but spend more time on each one.
(systems designers, application developers)
3. Systems Analysis, Design, and Programming. Analysts conduct the systems investigation,
develop design specifications, and program software to implement the design. (programmer
analyst)
Qualities/ Skills of a System Analyst
A systems analyst facilitates the development of information systems and computer applications. The
systems analyst performs systems analysis and design. Systems analysis is the study of a business
problem or need in order to recommend improvements and specify the requirements for the solution.
System design is the specification or construction of a technical, computer-based solution as specified by
the requirements identified in a systems analysis.
The most important skills a systems analyst must possess would be analytical, technical, management and
interpersonal Skills.
Compiled by Ms. R. Lupyani
Page 5
Analytical Skills: This is the point where good problem solving skills come into play. In order to find
the best possible solution, the systems analyst will have to define the problem and come up with a way
to solve it that is most beneficial to everyone; the analyst must be able to understand the function, and
problem, and should possess an open mind (creativity) in order to see problems from different angles
and find different ways to solve them.
Experience with past systems further reinforces the ability to find the best possible solution. One can
look at what they have done in the past and compare it to what they have to do currently. This skill is
obviously received the longer one works as a systems analyst. All in all a systems analyst needs to
analyze and solve problems in an efficient manner so as to achieve results and meet deadlines.
Technical Skills: Technical expertise and attention to detail are critical. The analyst must be
knowledgeable of technology; technology changes so quickly that there is almost a major improvement
in technology every month. Ability to follow up new technology is also one of the most important skills
that a system analyst must have. The analyst is not expected to know the intricacies of programming,
but a decent general knowledge of concepts and terms is essential.
The analyst must also be knowledgeable of business. The analyst is not expected to be an expert in
business but a decent understanding of the client's world is required.
Management Skills He or she should be able to mentally handle having several projects to monitor
simultaneously, while possessing the ability to organize, prioritize, and show initiative in attacking the
problem at hand. The analyst should also possess the ability to manage less experienced individuals.
He/ she should possess good leadership skills.
Communication Skills: The system analyst should possess excellent written and verbal communication skills.
This is so because they must be able to converse back and forth with the client over what the problem is and how
to go about finding the best solution. They must be able to ask the questions needed to understand the entire
scope of the project and communicate well with others i.e. to explain and present problems and solutions clear
and to the point
Possessing the ability to communicate with clients and coworkers is a very important step for a systems analyst
to succeed on the job.
Compiled by Ms. R. Lupyani
Page 6
Interpersonal Skills A systems analyst needs to be able to cooperate and get along with others while thriving in
a team-oriented environment. The analyst should be able to coordinate activities and work in a team environment;
act as a team member by providing information and support to team efforts. Interpersonal skills refer to how one
relates with others.
Above all, the analyst is a problem solver. He or she is person who views the analysis of problems as a challenge
and who enjoys devising workable solutions. When necessary, the analyst must be able to systematically tackle the
situation at hand through skilful application of tools, techniques, and experience. The analyst must also be a
communicator capable of relating meaningfully to other people over extended periods of time. Systems analysts need
enough computer experience to program, to understand the capabilities of computers, to glean information
requirements from users and to communicate what is needed to programmers. The systems analyst must be a selfdisciplined, self motivated individual who is able to manage and coordinate innumerable project resources, including
other people.
Compiled by Ms. R. Lupyani
Page 7
EVELYN HONE COLLEGE OF APPLIED ARTS AND COMMERCE
BUSINESS STUDIES DEPARTMENT
COMPUTER SECTON
SYSTEMS ANALYIS AND DESIGN I
Project Initiation
Information systems applications originate from virtually all areas of firms and pertain to vastly differing
business problems. This section discusses the reasons requests are made for systems assistance and the
origin of application proposals. Requests for information systems are typically motivated by one of three
general objectives.



Solve a Problem
An activity, process, or function that does not presently or may not in the future meet performance
standards or expectations unless remedial actions are taken.
Example: Reduce excessive data entry errors by eliminating the manual entry of sales details.
Capitalize on an opportunity
A change to expand or improve business performance and competitive achievements.
Example: Capture a large base of customers by offering a new airline frequent flier program
focusing on discounted airfares.
Respond to a directive
An order, request, or mandate originating from a legislative or management authority to provide
information or performance.
Example: Report annually to the Zambia Revenue Authority using prescribed formats, interest
earned on savings, checking, and time deposit accounts.
To achieve these objectives, firms typically undertake projects for one or more of the following reasons- the
five C‟s.
Compiled by Ms. R. Lupyani
Page 8
Reasons for Initiating Information Systems Projects
Capability
Capability involves the organization being capable of processing transactions quickly and efficiently.
Information systems add capability in three ways.
I.
II.
III.
Improved processing speed
Using the computer‟s inherent ability to calculate, sort, and retrieve data and information
with greater speed than that of people doing the same tasks is desired.
Increased Volume
Providing the capacity to process a greater amount of activity, perhaps to take advantage
of new business opportunities. Often a result of growth that causes business to exceed
the capacities and procedures underlying the achievements to date
Faster Information Retrieval
Locating and retrieving information from storage. Conducting complex searches
Control
I.
Greater accuracy and Improved Consistency
Carrying out computing steps, including arithmetic calculation correctly, and in the same way each
time.
II. Better security
Safeguarding sensitive and important data in form that is accessible only to authorized personnel.
Communication
I.
II.
Enhanced Communication
Speeding the flow of information and messages between remote locations as well as within offices.
Includes the transmission of documents within offices.
Integration of Business Areas
Coordinating business activities taking place in separate areas of an organization, though capture
and distribution of information.
Cost
I.
II.
Cost Monitoring
Tracking the cost of labor, goods, and facilities to determine how actual costs compare with
expectations.
Cost Reduction
Using computing capability to process data at a lower cost than possible with other methods, while
maintaining accuracy, and performance levels.
Compiled by Ms. R. Lupyani
Page 9
Competitive Advantage
I.
II.
III.
IV.
Lock in Customers
Changing the relationship with and services provided to customers in such a way that they will not
choose to change suppliers.
Lock out Competitors
Reducing the likelihood that competitors will be able to enter the same market because of the way
the organization uses information systems.
Improve Arrangements with Suppliers
Changing the pricing, service, or delivery arrangements, or relationship between suppliers and the
organization to benefit the firm.
New Product Development
Introducing new products with characteristics that use or are influenced by information technology.
Sources Of Project Requests
There are five sources of project requests. The requestors inside the organization are department
managers, senior executives, users, and systems analysts. In addition stake holders outside the
organization may request information systems projects. Depending on the origin of the request and the
reason for it, requestors may seek either completely new applications or changes in existing one.
Departments Managers
Frequently, persons who deal with day-to-day business activities, whether employees or managers, are
looking for assistance within their departments. For example, a business manager in a large medical clinic
supervises the preparation of patient claim forms submitted to insurance companies, which reimburse the
clinic for medical care. Even though the business manager knows that preparing insurance claims is
necessary to aid the patient and ensure that the clinic is reimbursed, he or she may dissatisfied with the
amount of time the staff devotes to the task, especially when much insurance information (such as patient
name, age, and the name of the attending physician) is already available in the patient‟s records. Pointing
out the duplication work, the book keepers express their desire to be free of the clerical tasks involved in
processing claims. This example is typical of cases where managers ask for systems projects. An ongoing
activity needs improvement, either to solve a problem, (for example too many errors, excessive costs, or
inconsistent work) or to improve the efficiency of a job.
The department manager requesting a systems project may not consider the interaction between
departments, even though the potential for such interaction can be high.
Compiled by Ms. R. Lupyani
Page 10
Senior Executives
Senior executives, such as presidents, board chairpersons, and vice presidents, usually have information
about the organization that is not available to department managers. That information, coupled with the
broader responsibilities these executives assume (they manage entire organizations rather than individual
departments), influences the systems project requests they make. For example, the vice president for
manufacturing who knows that an additional production plant will be built in another city within two years
may want to launch a systems project to develop a centralized production planning system- one that will
enable management to plan manufacturing at both plants at the same time. This project spans several
departments (including manufacturing, inventory control, and purchasing) at two locations and involves
many other managers.
The project requests submitted by senior executives are generally broader in scope than those prepared by
department managers. Consider how many departments and divisions of an organization are included
within the scope of a systems request to design and implement a new corporate-wide budget system or a
financial planning model. Such projects tend to cut across more of the organization than does an inventory
control system.
Systems Analysts.
Sometimes systems analysts see areas where projects should be developed and either write a systems
proposal themselves or encourage a manager to allow the writing of a proposal on their behalf. For
instance, an analyst who sees that a university‟s course registration procedure is slow, error prone, and
generally inefficient may prepare a project proposal for a new registration system. The request prescribes
the development of a system that takes advantage of new easy-to-use data entry terminals to speed
registration.
Normally, proposals for operating systems, such as those for course registration, are prepared by
department managers. However, in this case, the analyst has information about new equipment and
technology that makes a more efficient registration system possible. The department manager, who is not
responsible for researching computer technology, may not take the initiative for developing a systems
proposal to facilitate registration procedures.
Stakeholders and Outside Groups
Developments outside the organization also lead to project requests. For example, government contractors
are required to use special cost accounting systems with government-stipulated features. The internal
Revenue service also specifies the format for many of the tax documents that must be prepared; the
employer has no choice in the matter.
Compiled by Ms. R. Lupyani
Page 11
Quite often, new demands from external groups bring about project requests, either for new systems or
changes in current ones. Projects originating from this source are just as important as those from within
the organization. In some cases, such as when there are strict deadlines imposed by the outside agency,
these projects may take on a higher priority than ones from, say, department managers.
Users
Users can also be sources of a project request. The user is the one involved in the use of a system, as well
as in the way procedures are done. If they need things to be changed in order to help them perform in the
way they think is efficient and effective, they may come up with such a proposal.
The Project Plan
The information system project plan comprises of the following:







Investigation of Request- The request from employees and users in organizations are examined to
determine precisely what the originator wants.
Feasibility Study- The system requested is examined to determine if it is feasible. There are 3 aspects in
the feasibility study:
1.
Technical Feasibility: can the work for the project be done with current equipment, existing
software technology, and available personnel? If new technology is required, what is the likelihood
that it can be developed.
2.
Economic Feasibility: are there sufficient benefits in creating the system to make the costs
acceptable? Or, are the costs of not creating the system so great that the project must be
undertaken?
3.
Operational Feasibility: Will the system be used if is developed and implemented? Will there be
resistance from users that will undermine the possible application benefits?
A feasibility report is produced after the feasibility study is completed.
Existing System- the existing system, if any, is examined to understand its operations, strengths and
weaknesses.
Terms of Reference- terms and phrases constantly referred to during the project are identified and defined.
User Requirements- user requirements are specified according to what the system is intended to do for the
users.
Task Listing: Tasks involved in carrying out the objectives of the project in order to attain the set goal are
listed and divided accordingly.
Key players: people who will play a significant role in the project are identified in order to make a team.
Compiled by Ms. R. Lupyani
Page 12
EVELYN HONE COLLEGE OF APPLIED ARTS AND COMMERCE
BUSINESS STUDIES DEPARTMENT
COMPUTER SECTON
SYSTEMS ANALYIS AND DESIGN I
Requirements Determination
A Requirement is a feature that must be included in the new system. Requirements Determination involves
three (3) major activities of requirements anticipation, requirements investigation and requirements
specification.
Requirements Anticipation
The Systems analyst investigates the system based on past experience. Having had experience in a
particular business area or having encountered systems in an environment similar to the one currently
under investigation will influence the systems analysts‟ study. They may foresee the likelihood of certain
problems or features and requirements for a new system. As a result, the features they investigate for the
current system, questions they raise, or methods employed may be based on this familiarity.
On the other hand, experience from previous studies can lead to investigation of areas that would
otherwise go unnoticed by an inexperienced analyst. Having the background to know what to ask or which
a spects to investigate can be a substantial benefit to the organization. On the other hand, if a bias is
introduced or shortcuts are taken in conducting the investigation, requirements anticipation is a problem.
Compiled by Ms. R. Lupyani
Page 13
Requirements Investigation
This activity is at the heart of systems analysis. Using a variety of tools and skills, analysts study the
current system and document its features for further analysis. Requirements investigation relies on factfinding techniques and includes methods for documenting and describing system features.
Requirements Specification
The data produced during the fact-finding investigation are analyzed to determine requirements
specifications, the description of features for a new system. This activity has three interrelated parts:



Analysis of Factual Data
The data collected during the fact-finding study and included in data flow and decision analysis
documentation are examined to determine how well the system is performing and whether it will
meet the organization‟s demands.
Identification of Essential Requirements
Features that must be included in a new system, ranging from operational details to performance
on the criteria, are specified.
Selection of Requirements fulfillment Strategies
The methods that will be used to achieve the stated requirements are selected. These form the
basis for system design, which follows requirements specification.
All three activities are important and must be performed correctly. Requirements specification places a
great deal of responsibility on the systems analyst, for the quality of the work performed at this point will
show up later in the characteristics of the new system.
Analysts structure their investigation by seeking answers to these four major questions:
 What is the basic business Process?
 What data are used or produced during that process?
 What are the limits imposed by time and the volume of work?
 What performance controls are used?
FACT-FINDING TECHNIQUES
These are the specific methods analysts use for collecting data about requirements. These include
interview, questionnaire, record inspections (on-site) review and observation. Analysts usually employ
more than one of these techniques to help ensure an accurate and comprehensive investigation.
Interview
Analysts use interviews to collect information from individuals or from groups. The respondents are
generally current users of the existing system or potential users of the proposed system. In some
Compiled by Ms. R. Lupyani
Page 14
instances, the respondents may be managers or employees who provide data for the proposed system or
who will be affected by it. Although some analysts prefer the interview to other fact-finding techniques, it is
not the best source of application data. Because of the time required for interviewing, other methods must
also be used to gather the information needed to conduct an investigation.
It is important to remember that respondents and analysts converse during an interview. The respondents
are not being interrogated. Interviews provide analysts with opportunities for gathering information from
respondents who have been chosen for their knowledge of the system under study. This method is
frequently the best source of qualitative information (opinions, policies and subjective descriptions of
activities and problems). Other fact-finding methods are likely to be more useful for collecting quantitative
data (numbers, frequencies and quantities).
This method of fact-finding can be especially helpful for gathering information from individuals who do not
communicate effectively in writing or who may not have the time to complete questionnaires. Interviews
allow analyst to discover areas of misunderstanding, unrealistic expectations, and even indications of
resistance to the proposed system. Interviews can be either structured or unstructured. Unstructured
interviews, using a question-and-answer format, are appropriate when analysts want to acquire general
information about a system. This format encourages respondents to share their feelings, ideas, and
beliefs. Structured interviews use standardized questions in either an open-response or closed-response
format. The former allows respondents to answer in their own words; the latter uses a set of prescribed
answers. Each approach has advantages and disadvantages.
STRUCTURED INTERVIEW
UNSTRUCTURED INTERVIEW
 Ensures uniform wording of  Interviewer has greater flexibility in
questionsfor all respondents.
wording questions to suit respondent.
 Easy to administer and evaluate.
 Interviewer can pursue areas that
ADVANTAGES
 More objective evaluation of
arise spontaneously during interview.
bothrespondentsand answers to  May produce information about areas
questions.
that were overlooked or not thought to
 Limited Interviewer training needed.
be important.
 Result in shorter interviews.
DISADVANTAGES  Cost of preparation is high
 May inefficient use of both respondent
 Respondents many not accept high
and interviewer time.
level of structure and mechanical
 Interviewers may introduce their
posing of questions.
biases in questions or reporting
 High level of structure may not be
results.
suitable for all situations.
 Extraneous information may be
 High level of structure reduces
gathered
respondent spontaneity and ability
 Analysis and interpretation of results
of interviewer to follow up on
may be lengthy
comments of interviewee.
 Takes extra time to collect essential
facts.
Compiled by Ms. R. Lupyani
Page 15
The success of an interview depends on the skill of the interviewer and on his or her preparation for the
interview. Analysts also need to be sensitive to the kinds of difficulties that some respondents create
during interviews and know how to deal with potential problems. They need to consider not only the
information that is acquired during an interview, but also its significance.
Questionnaire
The use of questionnaires allows analysts to collect information about various aspects of a system from a
large number of persons. The use of standardized question formats can yield more reliable data than other
fact-finding techniques, and the wide distribution ensures greater anonymity for respondents, which can
lead to more honest responses. However, this method does not allow analysts to observe the expressions
or reactions of respondents. In addition, response may be limited, since completing questionnaires may
not have high priority among the respondents.
Analysts often use open-ended questionnaires to learn about feelings, opinions, and general experiences
or to explore a process or problem. Closed questionnaires control the frame of reference by presenting
respondents with specific responses from which to choose. This format is appropriate for eliciting factual
information. The high cost of developing and distributing questionnaires demands that analysts carefully
consider the objective of the questionnaire and determine what structure will be most useful to the study
and most easily understood by the respondents. Questionnaires should also be tested and, if necessary,
modified before being printed and distributed.
As with interviewee, recipients of questionnaires should be selected for the information they can provide.
The analyst should ensure that the respondent‟s background and experience qualify them to answer the
questions.
Record Review
Many kinds of records and reports can provide analysts with valuable information about organizations and
operations. In record reviews, analysts examine information that has been recorded about the system and
users. Record inspection can be performed at the beginning of the study, as an introduction, or later in the
study as a basis for comparing actual operations with what the records indicate should be happening.
Records include written policy manuals, regulations, and standard operating procedures used by most
organizations as a guide for managers and employees. They do not show what activities are actually
occurring, where the decision making power lies, or how tasks are performed. However, they can help
analysts understand the system by familiarizing them with what operations must be supported and with
formal relations within the organization.
Compiled by Ms. R. Lupyani
Page 16
Observation
Observation allows analysts to gain information they cannot obtain by any other fact-finding method.
Through observation, analysts can obtain firsthand information about how activities are carried out. This
method is most useful when analysts need to actually observe how documents are handled, how processes
are carried out, and whether specified steps are actually followed. Experienced observers know what to
look for and how to assess the significance of what they observe.
TYPES OF REQUIREMENTS
Requirements are categorized in several ways. However the main requirements are the functional and nonfunctional requirements.
Functional Requirements
These requirements explain what has to be done by identifying the necessary task, action or
activity that must be accomplished.
Non-functional Requirements
These are requirements that specify criteria that can be used to judge the operation of a system,
rather than specific behaviors. Non-functional requirements specify „how‟ rather than „what‟.
The other categories of requirements are:
Architectural Requirements
Architectural requirements explain what has to be done by identifying the necessary system
architecture of a system
Structural Requirements
Structural requirements explain what has to be done by identifying the necessary structure of a
system
Behavioral Requirements
Behavioral requirements explain what has to be done by identifying the necessary behavior of a
system
Performance Requirements
The extent to which a mission or function must be executed; generally measured in terms of
quantity, quality, coverage, timeliness or readiness. During requirements analysis, performance
(how well does it have to be done) requirements will be interactively developed across all identified
functions based on system life cycle factors; and characterized in terms of the degree of certainty
in their estimate, the degree of criticality to system success, and their relationship to other
requirements.
Design Requirements
The “build to,” “code to,” and “buy to” requirements for products and “how to execute” requirements
for processes expressed in technical data packages and technical manuals.
Compiled by Ms. R. Lupyani
Page 17
EVELYN HONE COLLEGE OF APPLIED ARTS AND COMMERCE
BUSINESS STUDIES DEPARTMENT
COMPUTER SECTON
SYSTEMS ANALYIS AND DESIGN I
Data Flow Analysis.
Analysts want to know the answers to four specific questions:




What processes make up a system?
What data are used in each process?
What data are stored? and
What data enter and leave the system?
The emphasis is clearly on data analysis. Data drives business activities. They can trigger events (for
example, new sales order data) and can be processed to provide information useful to personnel wanting to
know, for example, how well events have been handled (by measuring work quality and rate, profitability,
etc). Systems analysis recognizes the central role of business data in organizations. Following the flow of
data through business processes, which is the purpose of data flow analysis, tells analysts a great deal
about how organization objectives are accomplished. In the course of handling transactions and
completing tasks, data are input, processed, stored, retrieved, used, changed, and output.
Data flow analysis studies the use of data in each activity. It documents these findings in data flow
diagrams, which generally show the relation between processes and data, and in data dictionaries, which
formally describe the systems data and where they are used.
Def: Data flow analysis examines the use of data to carry out specific business processes within the scope
of a business investigation. It is considered as viewing the activities of a system from the view point of the
data: where they originate, how they are used or changed, and where they go, including the stops along the
way from their origin to their destination.
Compiled by Ms. R. Lupyani
Page 18
The components of data flow strategy span both requirements determination and systems design. A
prescribed notation facilitates the documentation of the current system and its analysis by all participants in
the process of determining system requirements.
Tools of Data Flow Strategy
Data flow strategy shows the use of data in the system pictorially. The tools used in this strategy show all
the essential features of the system and how they fit together. It can be difficult to fully understand the
business process through a verbal description alone; data flow tools help by illustrating the essential
components of a system and their interactions.
Data flow analysis makes use of the following tools:
1. Data Flow diagram
This is a graphic tool used to describe and analyze the movement of data through a systemmanual or automated –including the processes, stores of data, and delays in the system. Data
flow diagrams are the central tool and the basis from which other components are developed. The
transformation of data from input to output, through processes, may be described logically and
independently of the physical components (for example, computers, file cabinets, disk units)
associated with the system. They are termed logical data flow diagrams. In contrast, physical data
flow diagrams show the actual implementation and the movement of data between people,
departments, and workstations.
2. Data Dictionary
This shows logical characteristics of current systems data stores, including name, description,
aliases, contents, organization. It identifies processes where the data are used and where
immediate access to information is needed. It also serves as the basis for identifying database
requirements during system design.
3. Data Structure Diagram
This is a pictorial description of the relation between entities (i.e. people, places, events, and
things) in a system and the set of information about the entity. It does not deal with physical data
storage.
4. Structure Chart
This is a design tool that pictorially shows the relation between processing modules in computer
software. It describes the hierarchy of component modules and the data that are transmitted
between them. It includes analysis of input-to-output transformations and analysis of transactions.
Compiled by Ms. R. Lupyani
Page 19
Note: Refer to your note books to see the diagram showing the relationship of these components.
(Structured analysis components)
Notation
Data flow analysis methods were developed and promoted simultaneously by two organizations;
Yourdon, Inc, a consulting and professional development firm and McDonnell Douglas, through the
work and writings of Gane and Sarson. Logical data diagrams can be completed using only four
simple notations, i.e. special symbols or icons and the annotation that associates them with a
specific system. The use of specific icons associated with each element depends on whether the
Yourdon or Gane and Sarson is used.
1. Data FlowData move in a specific direction from an origin to a destination in the form of a
document, letter, telephone cal, or virtually any other medium.
Yourdon
Gane and Sarson
2. Processes
People, procedures, or devices that use or produce (transform) data. The physical component is
not identified.
Yourdon
Gane and Sarson
3. Source or Destination
External sources or destination of data, which may be people, programs, organizations, or other
entities, that interact with the system but are outside it boundary. The terms source and sink are
interchangeable with origin and destination.
Yourdon
Compiled by Ms. R. Lupyani
Gane and Sarson
Page 20
4. Data Store
Here data are stored or referenced by a process in the system. The data store may represent
computerized or non-computerized devices.
Yourdon
Gane and Sarson
Data Flow1
Source
DataFlow2
Data Flow4
Process
1
Destination
Data flow3Data Flow5
Data Store
Process
2
Figure 1.0a: Data flow diagram using Yourdon notation
Data Flow1
Proces
s1
Source
Data Flow
Data flow3
Data Flow4
Destination
Data flow5
Data Store
Proc
ess2
Figure 1.0b: Data flow diagram using Gane and Sarson notation
Compiled by Ms. R. Lupyani
Page 21
PARALLEL ACTIVITIES
The diagram in figure 1 shows that several data flows can be going on simultaneously. Data flows 1 and 2
may occur in parallel. This feature of data flow diagrams, to show parallel, to show parallel activities, is an
additional benefit. Other charting methods, such as flowcharts show processes activities that occur only in
a specific order, one after the other. Yet organizations have many activities have many activities occurring
at the same time with concurrent data flows. Data flow diagrams enable analysts to represent activities
more accurately by showing simultaneous activities when they are occurring.
As the name suggests, data flow diagrams concentrate on the data moving through the system, not on
devices or equipment. Throughout the process of understanding the application area, the analysts identify
and describe the data moving through the system and explain why the data are being input or output and
what processing is done. It is just as important to determine when data enter the application area as when
they leave. Sometimes data are stored for later use or from previous storage. Data flow diagrams also
show this.
ADVANTAGES OF DATA FLOW ANALYSIS
1. The simple notations are easily understood by users and business persons who are part of the
process being studied. Therefore, analysts can work with the users and actually involve them in
the study of data flow diagrams. Users can make suggestions for modifications of the diagrams to
more accurately describe the business activity.
2. They can also examine the charts and spot problems quickly so that they can be corrected before
other design works begins. If problems are not found early in the development process, they will
be very difficult to correct when they are noticed later. Avoiding mistakes early may even prevent
system failure.
3. Data flow analysis permits analysts to isolate areas of interest in the organization and study them
by examining the data that enter the process and seeing how they are changed when they leave
the process. As analysts gather facts and details, their increased understanding of the process
leads them to ask questions about specific parts of the process, which leads to still additional
investigation. The area of investigation is broken into successively lower-level details until all the
essential components and their interrelations can be understood.
A comprehensive systems investigation produces sets of many data fl ow diagrams, some providing
overviews of major processes and others going into great detail to show data elements, data stores, and
processing steps for specific components of a larger system. If analysts want to review the overall system
later, they use the higher-level overview diagrams. However, if they are interested in studying one
particular process, they use the data flow diagram for that lower-level process.
Compiled by Ms. R. Lupyani
Page 22
The level of data flow diagrams can be compared to highway and street maps that you might use when
travelling in an unfamiliar area. You first use a national map, showing major highways and cities. As you
near the city you are visiting, you need a more detailed map, showing the major parts of the city and the
access roads. After you reach the area of the city you want, a detailed street map that shows even
important landmarks, such as bridges and buildings, is especially helpful. Data flow diagrams are used the
same way. They are developed and used progressively from the general to the specific for the system of
interest.
DEVELOPING DATA FLOW DIAGRAMS
To be useful and informative, data flow diagrams must be drawn properly. This section shows how to draw
them: where to start, how to add detail to descriptions, when to add control information, and how to be
consistent in naming items included on the diagrams.
Development Process
Systems analysts must first study the current system, that is, the actual activities and processes that occur.
In the terminology of structured analysis, this is a study of the physical system. The physical system is
translated into a logical description that focuses on data and processes. It is advantageous to emphasize
data and processes in order to focus on the actual activities that occur and the resources needed to
perform them, rather than on who performs the work.
These are examples of physical system details.
Department
Copy Room or Building location
Person
Step Number
File
Procedure
During data flow analysis, these details are evaluated in terms of the logical components of data flows,
processes, data stores, origins and destinations. During the design stages that follow, system
requirements are translated into logical design details. Actual construction, such as the programming of
computer software, translates logical specifications into physical features and a working information
system. This overview of the sequence of activities for analysis and design of information systems will be a
backdrop for this discussion of data flow analysis.
Physical Data flow diagrams
Data flow diagrams are of two types:

Physical Data Flow Diagrams
Compiled by Ms. R. Lupyani
Page 23
An implementation-dependent view of the current system, showing what tasks are carried out and
how they are performed. Physical characteristics include:
Names of people
Form and document names or numbers
Names of departments
Master and transaction files
Equipment and devices used
Locations
Names of procedures

Logical Data flow diagrams
An implementation-independent view of a system, focusing on the flow of data between processed
without regard for the specific devices, storage locations, or people in the system.
The most comprehensive and useful approach to developing an accurate and complete description
of the current system begins with the development of a physical data flow diagram. The use of
physical data flow diagrams is desirable for three reasons.
1. Systems analysts typically find that it is much easier to first describe the interaction
between physical components than it is to understand the policies that are used to manage
the application. Thus, they begin identifying the people and what they do, which
documents, and information between departments and different locations.
2. Physical data flow diagrams are useful for communicating with users. Users relate easily to
people, locations and documents, since they work with each entity everyday. (Systems
analysts usually find that users consider logical data flow diagrams “abstract” because they
do not contain these familiar components.) Users can quickly point out when a step is
incorrect or missing.
3. Physical data flow diagrams provide a way to validate or verify the user‟s current view of
the system with the way it is actually operating. If there are differences they will be noted
and discussed. It is unusual to find that what a user thinks is happening differs in an
important way from what actually occurs, and these differences may account for problems
or inefficiencies- perhaps the reason a new system has been proposed.
Drawing Physical Data Flow Diagrams
Refer to the example on National Merchandising discussed in class.
Drawing a context diagram The first steps in requirements determination, are aimed at learning about the
general characteristics of the business process under investigation. The top layer of details, so to speak, is
studied. As analysts better understand those details, they delve deeply to collect more specific and
detailed information. Specific questions are pursued in increasingly greater detail using top-down analysis.
The data flow diagram in our example (National Merchandising) describes accounts payable processing at
a very general (top) level. This diagram shows that vendors submit invoices and receive cheques from the
Compiled by Ms. R. Lupyani
Page 24
organization. This accounts payable process itself requires accounts payable and vendor data. Notice that
each arrow, representing data flow, is labeled to show what data are being used. Balance data are
retrieved from the accounts payable data store for each vendor being paid, and the vendor address is
retrieved from data store.
The top level diagram is often called acontext diagram. It contains a single process, but it plays a very
important role in studying the current system. The context diagram defines the system that will be studied
in the sense that it determines the boundaries. Anything that is not inside the process identified in the
context diagram will not be part of the system study. The manner in which other organization or external
elements (i.e. sources and sinks) function is out our control and so they will not be studied in detail.
However, if they affect the processed because they are sources or sinks, the system must have an
interface, or interface, or means of interacting, with those elements outside of the system.
For example, the vendor data are an input to the accounts payable process. This indicates that the vendor
account is established outside of the system. In fact, at National Merchandising, the purchasing
department, which captures all vendor descriptive details (name, address, telephone number, etc) during
the purchasing process, is outside the scope of accounts payable. The purchasing system will not be
included in the new system, but any new design will have to provide for a way to use the vendor data
developed through that system.
Developing the first-level Physical Data Flow Diagram
A system consists of many different activities or processes. One process will contain several individual
steps. In computer programming, programmers often develop the software as a collection of independent
but interacting modules. These modules are shown in hierarchy. Process hierarchy charts are similar to
those developed by programmers.
Accounts
payable
Approv
e
invoice
Revise
balanc
e due
Write
chequ
es
The description of the accounts payable system in the context diagram requires more details. The next
step is to describe the system as we understand it at level 1 of the process hierarchy chart. The accounts
payable process consists of three lower-level processes of (1) Approve Invoice (2) Revise Balance Due (3)
Write Cheques. Hence, we want to identify the data flows, data stores, inputs and outputs that link together
the 3 processes. Each of these processes may in turn be broken down into smaller processes. Process
hierarchy charts continue to as many levels as needed to identify the activities that make up the system. In
general, any activity that generates, modifies or uses information should be included in the process
Compiled by Ms. R. Lupyani
Page 25
hierarchy chart. Some analysts find it helpful to work with all data flows first, assigning names that are
descriptive and useful. Processes are identified but unnamed until all data flows are understood. Later,
when processes are named, if the analyst has difficulty linking the data flows with appropriate names, it
may be a signal that further breakdown of the process is needed. This particular approach is a matter of
style and personal preference. It works well for some analysts and is less effective for others.
Compiled by Ms. R. Lupyani
Page 26
EVELYN HONE COLLEGE OF APPLIED ARTS AND COMMERCE
BUSINESS STUDIES DEPARTMENT
COMPUTER SECTION
SYSTEMS ANALYIS AND DESIGN I
Tools For Documenting Procedures
The making of decisions and following of procedures are an integral part of business. In fact, managing
itself is essentially decision making. Some decisions, such as whether to accept merger offers, affect entire
organizations. Others, such as deciding when to reorder supplies, are less complex, involve fewer people,
and are guided by step-by-step procedures. Both decisions and procedures, however, are important to
systems analysts when they are within the business system under investigation. This section examines
tools for studying operational procedures and decision-making steps, and the means of documenting them
for study. A tool is any device, object, or operation used to accomplish a specific task. Systems analysts
rely on tools just as other people do in their everyday activities. Tools help analysts assemble information
gathered through the data collection.There are three tools used for documenting procedures- decision
trees, decision tables, and structured English.
DECISION CONCEPTS
When analyzing procedures and decisions, the analyst must start by identifying conditions and actionsconcepts to all activities.
Condition and Decision Variables
If, when looking at a system, you ask, what are the possibilities? Or what can happen?, you are asking
about conditions, the possible states of an entity (person, place, thing, or event). Conditions vary, which is
why analysts may refer to them as a decision variables. In business, the handling of an invoice is based on
a condition that constitutes a decision variable. Some organizations insist that all invoices be signed before
payment can be authorized. In such a case, there are two alternatives for invoices received by the
Compiled by Ms. R. Lupyani
Page 27
organization: signed or Unsigned. The same invoice could also be described by other alternate conditions:
authorized or unauthorized, correctly priced or incorrectly priced.
In documenting the decision of how to process invoices (or any other procedure), the investigator must
identify both the relevant and the permissible conditions that can occur in a situation. Only those conditions
relevant to the study should be included. The fact that the invoice is signed or unsigned is a relevant
variable. However, the size of the sheet of paper on which it is printed probably is not.
Actions
When all possible conditions are known, the analyst next determines what to do when certain conditions
occur. Actions are alternatives- steps, activities, or procedures that an individual may decide to take when
confronted with a set of conditions. The actions can be quite simple in some cases and extensive in others.
DECISION TREES
A decision tree is a diagram that presents conditions and actions sequentially and thus shows which
conditions to consider first, which second, and so on. It is also a method of showing the relationship of
each condition and its permissible actions. The diagram resembles branches on a tree, hence the name.
Action
Condition
Root
Condition
Condition
Action
condition
Action
condition
Action
condition
Action
The root of the tree, on the left of the diagram, is the starting point of the decision sequence. The particular
branch to be followed depends on the conditions that exist and the decision to be made. Progression from
left to right along a particular branch is the result of making a series of decisions. Following each decision
point is the next set of decisions to be considered. The nodes of the tree thus represent conditions and
indicate that a determination must be made about which condition exists before the next path can be
chosen. The right side of the tree lists the actions to be taken, depending on the sequence of conditions
that is followed.
DECISION TABLES
Decision tables are composed of rows and columns. Each row corresponds to a single rule, with the
columns defining the conditions and actions of the rules.
You can add new rows to a decision table and fill in its cells to create new rules. When the rules are
executed, if the conditions of a given row are met, the actions in that row are performed.
Compiled by Ms. R. Lupyani
Page 28
Conditions
Condition
Statements
Decision Rules
Condition
Entries
Action
Action
Statements
Entries
TYPES OF TABLE ENTRIES
Limited-Entry Form: The basic table structure used in the previous examples, consisting of Y, N Entries is
a limited-entry form. It is one of the most commonly used formats.
Extended-Entry Form:The extended –entry form replaces Y and N with action entries telling the reader
how to decide. In this format, the condition and action statements themselves are not complete, which is
why the entries contain more details than Y and N. The limited- entry form lists conditions in the action
statement section. The X in the action entry section signals the correct action. However, the extended–
entry form has only one action statement, ACTION. For each rule, a short phrase is entered in the action
statement section.
Mixed-Entry Form: This form combines features of both the limited- and entry- forms in the same table.
Generally only one form should be used in each section of the table, but between the condition and action
sections, either form can be used.
ELSE Form: This form aims at omitting repetition through ELSE rules. To build an ELSE-form decision
table. Specify the rules with condition entries to cover all sets of actions except for one, which will be the
rule to follow when none of the other explicit conditions is true. This rule is in the final column on the right,
the ELSE column. If none of the other conditions hold, then the ELSE decision rule is followed. The ELSE
rule eliminates the need to repeat conditions that lead to the same actions.
STRUCTURED ENGLISH
Structured English is an additional method to overcome problems of ambiguous language in stating
conditions and actions in decisions and procedures. This method does not use trees or tables, but rather
narrative statements, to describe a procedure. It does not show decision rules; it states them. StructuredEnglish specifications still require analysts to identify the conditions that occur in a process, decisions that
must be made when these conditions occur, and alternative actions to take. However, this method also
allows analysts to list steps in the order which must be taken, as examples in this section will show. No
special symbols or formats are used, a feature that some dislike about decision trees and tables.
Compiled by Ms. R. Lupyani
Page 29
Furthermore, entire procedures can be stated quickly, since only English-like statements are used. The
terminology used in the structured description of an application consists largely of data names for elements
that are defined in the data dictionary developed for the project.
DEVELOPING STRUCTURED STATEMENTS
Structured English uses three basic types of statements to describe a process: sequence structures,
decision structures, and iteration structures. They work well for decision analysis and can be carried over
into programming, and software development.
Sequence StructuresA sequence structure is a single step or action included in a process. It does not
depend on the existence of any condition, and, when encountered, it is always taken. Typically, several
sequence instructions are used together to describe a process. For example, to purchase a book in a
bookstore, you would probably follow a procedure similar to the one that follows:
1.
2.
3.
4.
5.
Pick out a book
Take the book to the checkout counter
Pay for the book
Obtain a receipt
Leave the store
This example shows a sequence of five steps. None of the steps contains a decision or any conditions
that determine whether the steps are taken. Furthermore, the steps are taken in the order listed. For
instance, it would make little sense to pay for a book before picking one out. Therefore, the procedure
is described to point out the correct order of actions.
Decision Structures Structured English is another way of showing decision analysis. Therefore, the
action sequences described are often included within decision structures that identify conditions.
Decision structures thus occur when two or more actions can be taken, depending on the value for a
specific condition. One must assess the condition and then make the decision to take the stated
actions or sets of actions for that condition. Once the determination of the condition is made, the
actions are unconditional. Let us expand the bookstore example to show the decision structure. If you
go into a bookstore, you may not find a book you wish to purchase. You can show actions for either
condition: finding a desirable book and not finding a desirable book:
If a desirable book is found, Then
Take the book to the counter
Pay for the book
Be sure to obtain a receipt
Leave the store
Else
Compiled by Ms. R. Lupyani
Page 30
Do not take books to the counter
Leave the store
The decision structure, through the use of IF/THEN/OTHERWISE or IF/THEN/ELSE phrases, points out
alternatives in the decision process quite clearly. Two conditions and two actions are indicated. Notice how
sequences are contained within each condition. The IF portion contains four separate sequence
statements, while the OTHERWISE portion contains two, which is very common. In structured English, one
can embed individual structures within other structures. Writing the details in an indented format also helps
group the conditions and actions that go together. Decision structures are not limited to two conditionaction combinations. There can be many conditions.
Iteration StructuresIn routine operating activities, it is common to find that certain activities are repeated
while a certain condition exists or until a condition occurs. Iteration instructions permit analysts to describe
these cases. In searching for a book in a bookstore, you might repeat these steps:
Do While
Still examining more books:
Read the title of the book.
If the title sounds interesting
Then pick up the book and thumb through it
If you decide you want the book
Put it in the shopping basket
Else
Put it back on the shelf
End IF
Else
Continue
End Do
Take the books to the Counter
Pay for the books
Obtain the receipt
Leave the store
In this example, additional steps nested within the iteration loop give instructions on what to do when the
title sounds interesting and when the person decides to get the book. The repetition continues as long as
the condition of still examining more books exists. Then the procedure shows the steps to be taken if any
desirable books have been found.
Benefits of Structured English
 Structured English can be useful to describe conditions and actions clearly. When examining a
business setting, analysts can use Structured English to state decision rules as they are being
applied. If analysts cannot state what action to take when a decision is made, it means they need
to acquire more information to describe it.
 After activities have been described in this structured fashion, analysts can have other persons review
the narrative and quickly determine whether mistakes or omissions have been made in stating the
decision processes
Compiled by Ms. R. Lupyani
Page 31

Compiled by Ms. R. Lupyani
Page 32