System Analysis and Design

KENYA METHODIST UNIVERSITY
DEPARTMENT OF COMPUTER INFORMATION SYSTEMS
DISTANCE LEARNING MODULE
INSTRUCTION MATERIALS
COURSE CODE: CISY 222
COURSE TITLE: SYSTEM ANALYSIS AND DESIGN
Complied by: Mwenda Muriira, Department of CIS 1

CHAPTER ONE
Introduction
Definitions
System
A system is a set of inter-dependent/interrelated components (some of which may be systems in
their own right), with an identifiable boundary and which collectively accomplish certain
objectives/purpose.
Characteristics of a system
A system has 9 characteristics.
1. Components
A system is made up of components. A component is an irreducible part or aggregation
of that make up a system, also called subsystems. We can repair or upgrade the system by
changing individual components without having to make changes throughout the entire
system.
2. Interrelated Components
The components are interrelated. This means the dependence of one subsystem on one or
more subsystems. The function of one subsystem is tied to the function of others.
3. A Boundary
A system has a boundary within which all of its components are contained and which
establishes the limits of a system, separating the system from other systems. The boundary
is the line that makes the inside and outside of a system and that sends off the system from
its environments.
4. A purpose
This is the overall goal or function of a system. A system must give priority to the
objectives of the organization as a whole as compared to the objectives of a subsystem.
5. An Environment
This is everything external to a system that interacts with the system i.e. everything
outside the system’s boundary, usually the system interacts with its environment,
exchanging, in the case of an information system, data and information.
6. Interfaces
This is the point of contact where a system meets its environments or where subsystems
meet each other. eg. The interface between an automated system and its users (manual
system) and interfaces between different information systems. It is the design of good
interfaces that permits different systems to work together without being too dependent on
each other. Because an interface exists at the point where a system meets its environment,
the interface has several special, important functions outlined below:-
• Security - protecting the system from undesirable elements that may want to
infiltrate it.
• Filtering unwanted data both for elements leaving and entering the system.
• Coding and decoding incoming and outgoing messages.

• Detecting and correcting errors in its interaction with the environment.
• Buffering - providing a layer of slack between the system and its environment, so
that the system and its environment can work on different cycles and at different
speeds.
• Summarizing raw data and transforming them into the level details and format
needed throughout the system.
7. Constraint/ Controls
This is a limit to what a system can accomplish. A system must face constraints in its
functioning because there are limits – in terms of capacity, speed, or capabilities to what it
can do and how it can achieve its purpose within its environment.
8. Input
This is whatever a system gets from its environment, eg. Raw data.
9. Output
This is whatever a system returns to its environment in order to fulfill its purpose.
Feedback
A feedback may be defined as a check within a system in order to ensure that the objectives
of the system are achieved. These checks are conducted in order to find out way deviation. If any
deviation is detected, then appropriate steps are taken to ensure that the error is rectified.
Feedback may be positive or negative.
Negative Feedback
This is a system that works on the principle of trying to reduce the fluctuations around
a set standard, eg. If the credit limit of those customers who have outstanding debts is
restricted, then it is known as negative feedback since the action is taken opposite to
deviation.
Positive Feedback
It a system that attempts to increase a detected deviation, it helps the system to adjust
but acting in the same direction in which deviation has occurred, e.g. If the demand
for any product increases and as a result, production is also increased, then it is
positive feedback - it helps to increase the efficiency of the system.
Feedforward
It means to take steps to make some adjustments to the system in advance in order to face any
expected deviations in future. Feedback monitors the past results whereas feedforward deals with
future outcomes.
Computer Based system

The elements of a computer system include:-
Hardware
Software
People (Users and operators)
Database
Documentation
Procedures.

Classification of Systems
(a) Systems and their Environment

General systems theory distinguishes between closed and open system.
Open Systems
These are the system which are connected to and interact with the environment. Examples are,
the biological and social system. All business organizations are also open systems since they
must have the capacity to adopt in the future of changing competition, changing markets e.t.c.
The major components which together constitute the open system are:-
• Input – This may take the form of money, materials energy, decisions, information e.t.c
• Process- This changes input into desirable output eg. Changing data to information.
• Output – This is the systems reason for its existence
• Sensor – Stimuli, response to the effect of the environment.
• Feedback – This is the systems way of monitoring the environment it operates in, which
permits it to make adjustments to survive and maintain dynamic equilibrium.
• Standard – This allows control to be exercised, allowing variances to be assessed and
action to be where necessary.
• Comparator – This is the means by which comparison is made between the standard and
actual performance or results.
• Effectors – Takes any action to correct any variance or deviation discovered by the
comparator.
Closed Systems
A closed system is that which does not interact with its environment. The system is neither
influenced by nor influences its environment. It does not take in from or give to it. The system
behavior occurs because of internal interaction and is more relevant to scientific than social
systems. They do not obtain modification from their environments. A computer program is a
relatively closed system because it accepts only previously defined outputs. In fact, no system
can be a completely closed system for a long time.
We may also have relatively or semi-closed system where the system relates to its environment
in a prescribed and controlled way.
Difference between Open Systems and Closed Systems
Open System Closed System

- Interacts with the environment constantly - Does not interact with the Environment
- Has infinite scope - Limited Scope
- Relevant variables keep on interacting - Self Contained
- Flexible and abstract - Rigid and mathematical

(b) System and adaptability
They are classified according to a hierarchy of properties of the system.
Deterministic Systems (Mechanistic Systems)

These are the systems that function according to some predetermined procedure and have
results and future behavior predicted with certainty provided they are working correctly and
under control. A system may be classified as deterministic if it is possible to predetermine the
stages or steps through which it would pass. It is possible to examine the system and predict the
next stage from the present one. However, an unexpected mode of working may develop as a
result of errors or excessive weakness in which the case the system becomes probabilistic rather
than deterministic.
Examples include - the working of computer program, the behavior of the planet in orbit, or
business systems have a variety of uncertainties e.g. customer behavior.
Probabilistic Systems (Stochastic Systems)

These are those systems whose state and behaviour can be predicted only within certain limits,
even when they’re under control. Although some of these states in these systems may be
predicted from previous states, they can be described only in terms of probable behaviour.
Example, the inventory systems, average stock, average demand, average replenishment time
may be predicted but exact values of those factors any instance may not be known.
Cybernetic system (Self Organizing/ Adaptive)

These are systems that have to adapt to their environments/ react to stimuli, they learn from their
mistakes, so that they do not always react in the same way to a particular input.
Examples are the social systems, organizations, plants.
(C) Control of the system
Open – Loop System.

This is a system which does not act in a controlled manner, i.e no feedback, and so no measure of
performance against standards.
Closed – Loop System

A system that functions in a controlled manner e.g. A system accepts inputs, work upon them
according to some pre-defined processing rules, and produces outputs, so that it can function in a
controlled manner, must give feedback
Artificial Systems
These systems are created rather than occur by nature e.g computer programs, organization, etc.
They are usually made to support the objective of the designer and user.
Human Machine Systems

Those are systems designed to help in accomplishing certain set goals e.g. helping in decision
making. The machine elements (eg h/ware and s/ware) are relatively closed and deterministic
whereas the human elements are open and probabilistic.
Information Systems (IS)

This is a set of persons, procedures and technological and other resources that collects, transfers
and disseminates information in the system eg. Organization IS includes manual IS, informal IS,
and computer based IS.
Types of Information Systems

There are different types of information systems distinguished from each other on the basis of
what the system does or by technology used to construct the system. One of the jobs of the
system’s analyst will be to determine which kind of system will best address the organizational
problem or opportunity on which you are focusing. In addition, different classes of systems may
require different methodology techniques, and tools for development. The following are some of
the classes of information systems.
1. Transaction Processing Systems (TPS)

TPS automate the handling or transaction, which can be thought of as simple, discrete events in
the life of an organization. Data about each transaction are captured. Transaction are verified and
accepted or rejected, and validated. Transactions may be moved from process to process in order
to handle all aspects of the business activity. The analysis and design of a TPS means focusing
on the firm’s current procedures for processing transactions, whether manual or automated. This
focuses on processing and output. The goal of TPS development is to improve transaction
processing by speeding it up using fewer people, improving efficiency and accuracy integrating
it with other organizational information systems, or providing information not previously
available.
2. Management Information System (MIS)

MIS takes the relatively raw data available through a TPS and converts them into a meaningful
aggregated form that managers need to conduct their responsibilities. It provides the
management with the report usually in predetermined, fixed format eg detailed summary.
Developing an MIS calls for a good understanding of how managers use information in their
jobs. MIS often requires data from several transaction processing systems eg. Customer order
processing, raw material purchasing and employee time keeping. Developing of an MIS can,
therefore benefit from a data orientation, in which data are considered an organization resource
separate from the TPS in which they are captured. MIS is also a term used in organization as the
title of their computer services department.
3. Decision Support Systems (DSS)

DSS are designed to help organizational decision makers make decisions. It provides guidance in
identifying problems, finding and evaluating alternative solutions, and selecting of and
comparing alternatives.
Instead of providing summaries of data, as with a MIS, it provides an interactive environment in
which decision makers can quickly manipulate data and models of business operations.

A DSS is composed of a database (which may be extracted from TPS or MIS), mathematical or
graphical models of business processes, and a user interface that provides a way for the decision
maker, usually a non technical manager, to communicate with DSS.
A DSS may use both hard historical data as well as judgments (what if scenarios) about
alternative histories or possible futures. In many cases, the historical data came from a firm’s
data warehouse. One form of DSS, an executive information system, emphasizes the
unstructured capability for senior management to explore data starting at a high level of
aggregation and selectively drilling down into specific areas where more detailed understanding
of the business are required.
The SAD for a DSS often concentrates on the three main DSS components, database, model
base, and user dialogue. As with MIS, orientation is most often used for understanding user
requirement. In addition, the SAD project will carefully document the mathematical rules that
define interrelationships among different data. These relationships are used to predict future data
or to find the best solution.
4. Expert Systems (ES)

ES attempt to codify and manipulate knowledge rather than information. It provides expert with
advice by asking users a sequence of questions dependent on prior answers that lead to a
conclusion or recommendation. It simulates thinking for those with less knowledge. The focus
on developing on ES is acquiring the knowledge of the expert in the particular problem domain
knowledge engineers perform knowledge acquisition
Examples:- Physician Diagnostics.
Tools: LISP, Prolog
In addition, many organizations recognize scientific technical computing and office automation,
thus there are several other important systems concepts with which systems analysts need to be
familiar.
More Definitions
Decomposition
• This is breaking down the system into smaller, more manageable and understandable
components called the subsystem. This helps in focusing the attention on one subsystem
at a time without interference from other parts.
• Also permits different parts of the system to be built at independent times and/ or by
different people.
Modularity
A direct result of decomposition.
Refers to dividing a system up into chunks or modules of a relatively uniform size.
Coupling
This is the extent to which subsystems are dependent on each other. Subsystems should be as
independent as possible. If the subsystems are loosely coupled them, unfortunately one fails
then the other will not be affected.
Cohesion.

This is the extent to which a subsystem performs a single function. Biological systems are
very cohesive.
Any description of the system is abstract since the definition is not a system itself.
A Logical System Description portrays the purpose and function of the system without trying
the description to any specific physical implementation.
The Physical System Description is a material depiction of the system, and the central concern
is building the system.
Sub Optimization – An occurrence that occurs when the objective of one element (subsystem)
conflicts which the objective of the overall system.
System Analysis and Design

Is a complex challenging and stimulating organizational process that a team of business and
systems professional uses to develop and maintain computer based information system.
An important result of systems analysis and design is application software, i.e. software designed
to support a specific organizational function of process, such as inventory management, etc.
In addition to application software, the total information system includes the hardware and
system’s software on which the application software runs, documentation and training materials,
the specific job roles associated with the overall system, controls and the people working with
the software. Central to software engineering are various methodologies, techniques and tools
that have been developed, tested, and widely used to assist people in SAD.

CHAPTER TWO
Methodologies
Definitions
A methodology is a standard process followed in an organization to conduct all the steps
necessary to analyze, design, and maintain information systems.
Techniques are particular processes that you, as an analyst, will follow to help ensure that your
work is well throughout, complete and comprehensive to others on your project team.
Techniques provide support for a wide range of tasks such as conducting thorough interviews,
planning and managing project activities.
Tools are typically computer programs that make it easy and benefit from the techniques and
follow the methodology.
The System Design Methodologies

i) Systems Development life cycle (SDLC)
ii) Structured Analysis and Structured Design (SASD)
iii) Object – Oriented Analysis and Design
iv) Jackson System Development.
i) The System Development Life Cycle (SDLC)

This is a common methodology for systems development in many organizations, featuring
several phases that mark the progress of the system analysis and design.
The life cycle is not a sequentially ordered set, but the steps and their sequence are meant to be
adopted as required for a project consistent with management approaches. The project can return
to an earlier phase if necessary. It is also possible to complete some activities in one phase in
parallel with some activities of another phase. Sometimes the life cycle is durative i.e phases are
repeated until an acceptable system is found. The completion of one phase leads to the initiation
of the next.
Management approval is needed before the beginning of each new phase. There are requirements
for project management and system documentation throughout each phase. Communication
between the information system personnel, the users, and management should be ongoing. This
approach of development is sometimes described as the waterfall method (see fig. 1) because of
the way in which what is produce at each stage leads to the next stage.

Figure 1: Waterfall model
Project Identification and Selection

In this phase, someone identifies the need for a new or enhanced system. The user initiates the
life cycle through communication of a need or a problem.
Project Initiation and Planning

The two major activities in this phase are the formally yet still preliminary investigation of the
system problem as opportunity at hand and the presentation of reasons why the system should or
should not be developed by the organization.
Critical step at this point is determining the scope of the proposed system. The goal of
investigation is to understand how data is currently handled within the system, which leads to an
evaluation of the shortcoming of this data handling, project documentation is compiled from the
beginning of the project. For this phase, the project documentation encompasses the initial
statement of the need, a list of required activities and expected results, copies of correspondence,
and project planning aids. The final results of the phase are summarized in the preliminary
investigation report persecuted for management approval.

Detailed Analysis
During this phase, the analyst thoroughly studies the organizations current procedures and the
IS’s used to perform the organization task. It has several sub-phases.:-
• Requirement determination - The analyst and the team work with users to determine what
the users want from the proposal system.
• Next, the requirements are studied and structured according to their interrelationships and
eliminate any redundancies.
• Third, the initial design alternatives are generated to match the requirements.
• Then you compare these alternatives to determine which best meets the requirements
within the cost, labor and technical levels.
• The phase culminates with a feasibility study report, presented to management for
approval prior to initiation of the next stage.
Design
The description of the recommended solution is converted into logical and then physical system
specifications. Logical design is the part of the design phase that is independent of any specific
h/ware or s/ware plat form. Theoretically, the system could be implemented on any hardware or
system software.
Physical design is the part of the design phase of the SDLC in which the logical specifications of
the system from logical design are transformed into system and also logical design are
transformed into technology – specific details from which all programming and system
construction can be accomplished. This can be done in many ways, from creating a working
model of the system to be implemented, to writing detailed specifications describing all the
different parts of the system and how they should be built.
During the physical design, the analyst team must determine many of the physical details
necessary to build the final system, from the programming language, to the database system that
will store the data, to the hardware platform on which the system will run. Upon review of the
new system specifications, management approval initiates the next phase of system development.
Implementation
The system specification is turned into a system that is tested and then put into use.
It includes:-
• Coding – Writing programs that make up the system. Sometimes the code is generated by
the same system used to build the detailed model of the system.
• Testing – Programmers and analyst test individual and entire system in order to find and
correct errors.
• Installation
• Evaluation
• Initial user support such as finalization of documentation training programs, and ongoing
user assistance.
Maintenance
Programmers make the changes that users ask for and modify the system to reflect the changing
business conditions. These changes are necessary to sense, maintenance is not a separate phase

but a repetition of the other life cycle phases required to study and implement the needed
changes.
Traditional SDLC Critism

Although the phases can overlap, traditionally one phase ended and another began once a
milestone had been reached (deliverable output). It would be difficult to go back while the new
phase began.
There were no CASE tools, no code generators, and no fourth generation languages when SDLC
was popularized in 1960’s
It tends to focus too little time on good analysis and design. This resulted in a system that does
not match user’s needs and one that requires extensive maintenance - unnecessarily increasing
the costs.
ii) Structured Analysis and Structured Design. (SASD)
This was developed by Ed Yourdon, etal in the early 1970’s to address some of the problems
with the traditional SDLC. They made analysis and design through the use of tools such as data
flow diagrams (DFD).
SASD makes it easier to go back to earlier phases in the life cycle when necessary e.g when
requirements change.
There is also portioning the problem into smaller manageable units and making clear distinction
between the physical and logical design.
iii) Object Oriented Analysis and Design. (00AD)
Most recent approach to system development and is getting more and more popular. OOAD is
often the process - oriented and data - oriented approaches. The object oriented approach
combines data and process (methods) into single entities called objects, the techniques that
system analysis uses form object oriented analytics - use of object oriented analysis and design
and their associated notations that are incorporated in a standard object oriented language called
unified modeling languages (UML).
iv) Jackson System Development (JSD)
Jackson System Development (JSD) is a linear software development methodology developed

by Michael A. Jackson and John Cameron in the 1980s. Three basic principles of operation of
JSD is that:
• Development must start with describing and modelling the real world, rather than
specifying or structuring the function performed by the system. A system made using
JSD method performs the simulation of the real world before any direct attention is
paid to function or purpose of the system.
• An adequate model of a time-ordered world must itself be time-ordered. Main aim is
to map progress in the real world on progress in the system that models it.

• The way of implementing the system is based on transformation of specification into
efficient set of processes. These processes should be designed in such a manner that it
would be possible to run them on available software and hardware.
When it was originally presented by Jackson in 1983, the method consisted of six steps.
• Entity/Action Step
• Initial Model Step
• Interactive Function Step
• Information Function Step
• System Timing Step
• System Implementation Step
Later, some steps were combined to create a method with only three steps.
• Modelling Stage (Analysis): with the Entity/Action Step and Entity Structures Step.
• Network Stage (Design) : with the Initial Model Step, Function Step, and System
Timing Step.
• Implementation Stage (Realisation) : The implementation Step.
Different Approaches to Improving System Development
1. Prototyping.
This is designing and building a scaled down but functional version of a desired system. You can
build a prototype with any computer languages or Development tool, but special prototyping
tools have been developed to simplify the process. A prototype can be developed to simplify the
process. A prototype can be developed with some 4G, with the query and screen and report
design tools of a DBMS, and with CASE tools.
Using prototyping as a developing technique, requirements are converted to working system that
is continually revised through close work between an analyst and user. This interactive process
continues until the users are relatively with what they have seen. There are three main activities
which are described as prototyping.
a) mock-up
A “mock-up” of a proposed system or subsystem is produced for demonstration purposes
at the early stages of a project so as to aid the users and usually the prototype has the
appearance of the final system but lacks any real processing or storage capability.
b) Trial Prototyping
A simplified working model of a proposed system or subsystem that has capabilities
(some) of the real system. It might be used to design an appropriate user interface for the
new system.
c) Rapid Prototyping.
This is one method of achieving rapid applications development (RAD). The fundamental
principle of any RAD methodology is to delay producing a detailed system design
document until after user requirements are clear. RAD methodologies emphasize on
gaining user acceptance of the human system interface and developing core capabilities

as quickly as possible, sacrificing computer efficiency for gains on human efficiency in
rapidly building and rebuilding a working system. The main method is the short term
gain of having a working system early.
2. Joint Application Design (JAD)

This is a structured process in which users, managers, and analyst work together for several days
in a series of intensive meetings to specify or review system requirements.
It was developed in the late 1970’s by the systems development personnel at IBM. However,
JAD methodologies can overlook important software engineering principles, the result of which
are inconsistencies between system modules, non-compliance components, hence can tend to be
costly and difficult to maintain.
The People in a System Development process
Management
Management concerns within the system development process focus on seeing that end results
meet the company’s needs and insuring that the project is completed on schedule and within the
budget allowed.
Users
Users represent the hand-on, everyday aspect of a system. These are the people for whom
systems are developed. They already know how to complete the functions of procedures
manually. The system should increase their efficiency and productivity.
Users concerns include ease of use and the reliability of the system. Users can aid in system
development through their ideas and understanding of the business procedures involved.
The Systems Analyst

Systems analysis is the key individuals in the systems development project.
Roles:
• Helping the user determine information needs.
• System analysis – Gathering facts about existing systems and analyzing them to
determine the effectiveness of current processing methods and procedures
• Systems Design – Designing new systems, recommend change to existing systems, and
being involved in implementing these changes.
• Systems Specification – Specify the system in details i.e. its input, the files, processing,
output, hardware, cost accuracy, response times e.t.c
• System testing and maintenance
The analyst requires four main skills: Analytical, Technical, Managerial, Communication and
Interpersonal.
a) Analytical Skills
i) Organization Knowledge - Since the analyst will work with the organization, whether
internal or external, (s)he must understand how the organizations work:

• Must understand the functions and procedures of the particular organization
(procedures) you work for.
• Since most systems serve a particular department, you must understand how that
department operates, its purposes, its relationship with other departments.
ii) Problem Identification: - Pounds (1969), defines a problem as the difference
between an existing situation and a desired situation. In order to identify
problems that need solving, you must be able to compare the current situation
in an organization to the desired situation.
iii) Problem Analyzing and Solving:- Analysis entails finding out more about the
problem. The analyst should know how to get needed information from other
people, from organization files and documents and to formulate alternative
solutions to the problems. The problem analysis and solving approach has four
phases as described by Herbert, etal (1960).
• Intelligence – Collecting relevant information.
• Design – Formulate alternatives
• Choice – Choosing the best alternative solution
• Implementation – Putting the solution into practice.
b) Technical Skills
Many aspects of the systems analysts job are technically oriented.
In general, you should be as familiar as possible with such families of technologies
such as:-
• Microcomputers, workstations, minicomputers and mainframe computers.
• Programming languages
• Operating systems for both single machines and networks
• Database and file managements systems.
• Data communication standards and software for LAN and WAN.
• Systems development tools and environments (such as form and report generators an
graphical…)
• Web development languages and tools eg. HTML Microsoft, FrontPage.
• Decision support system generators and data analysis tools.
• Modern methods and techniques, for describing modeling and building systems.
The following activities will help you stay versatile and up-to-date.
• Read trade publications eg. Computer world or PC world
• Join professional computer societies
• Attend classes or teach at a local college. Teaching is a way of forcing oneself to stay
current and to learn from others.
• Attending courses, training sessions offered by your organization and other professional
conferences, seminars, tradeshows, etc.
• Regularly browse websites that focus on ICT industry news, such as CNET, many trade
publication also have websites.

c) Management Skills
Systems analysts are members of project teams and are frequently asked to lead teams.
Management skills are very useful for anyone in a leadership role. These includes:-
i) Resource Management
You must know how to get the most out of a wide range of resources: System
documentation, IT and money. The most important resource is people. A team leader
must learn how to best utilize the particular talent of other team members by delegating
responsibilities.
Resource Management includes:-
• Predicting resource usage (budgeting).
• Tracking and accounting for resource consumption
• Learning how to use resources effectively and efficiently
• Evaluating the quality of the resources used.
ii) Project Management

The goal of project management is to prevent projects from coming in late and going
over budget. It also helps managers to keep track of the projects progress.
iii) Risk Management

The ability to anticipate what might go wrong in a project.
The analyst as the leader, should identify any risks, find a way to minimize the likelihood
that the risk may occur or try to minimize the damage that might occur.
iv) Change Management

The analyst should know how to get people to make a smooth transition from one
information system to another, giving up their old ways of doing things and accepting
new ones. This also includes:- the ability to deal with issues related to change.
d) Interpersonal Skills
Although the systems analyst will be working in the technical area of designing and building
computer based information systems (s)he will also work extensively with all kind of people.
e) Communication Skills
This is the ability to communicate clearly and effectively with others - users, information
system professionals and management. Communication takes many forms, from written (memos,
reports) to verbal (phone calls, face to face conversations) to visual (presentation slides,
diagrams), oral communication and listening skills are considered by many as most important
communication skill. This skills includes:- Interviewing and listening, the use of questionnaires
and written and oral communication.
i) Interviewing, Listening and Questionnaires

One of the primary ways analysts gather information about an information system
project.

ii) Written and Oral Presentations
As many points during the system’s development project, you must document the
progress of the project also provide history for the project, to convey information clearly,
and to provide details needed by those who will maintain the system.
This communication takes the following terms:-
• Meeting Agenda
• Meeting Minutes
• Interview summaries
• Project schedules and descriptions
• Memoranda requesting information, an interview, participation in a project
activity, or the status of the project.
• Request of proposal from contractors and vendors.
Working Alone and with a Team

As a systems analyst, you must often work alone on certain aspects of any system development
project. You must be able to organize and manage your own schedule, commitment and
deadlines. Also, you must work with a team to achieve the project’s goals.
Characteristics of a High Performance Team

1. Shared, elevated vision or goal – This allows every team member to have a clear
understanding of the project’s objectives. This helps to keep the priorities straight. The
vision also needs to present a challenge to team members.
2. Sense of Team Identity – This emerges as team members work together closely and
begin to share a common language and sense of humor.
3. Result (Driven Structure) – One that depends on clear roles, effective communication
system, means of monitoring individual performance, and decision making based on facts
other than emotions.
4. Competent team members
5. Commitment to the team
6. Mutual trust among the team
7. Interdependence among team members
8. Effective communication means
9. Sense of autonomy- Gives each team members the autonomy to do whatever he/she
believes is best for the team and for the project.
10. Sense of empowerment – Empower each team member
11. Small team size – No larger than 8 – 10 people
12. High level of enjoyment.
Automated Tools For Systems Development

Computer Aided Software Engineering (CASE) refers to automated software tools used by the
system analysts to develop information systems.

Objectives of CASE in Organization
• To improve the quality of the system’s development
• To increase the speed with which systems are designed and developed
• To ease and improve the testing process through the use of automated checking
• To improve the integration of development activities via common methodologies
• To improve the quality and completeness of documentation
• To help standardize the development process
• To improve the management of the project
• To simplify program maintenance
• To promote reusability of modules and documentation
• To improve software portability across environments
• Shorter development time.
Reasons why organizations reject CASE

• High cost of purchasing CASE
• High cost of training personnel
• Long duration of planning – analysis and design. Although CASE significantly shortens
the overall process, the big benefits of CASE come in the late stages of development,
construction, testing, implementation and maintenance
• Some CASE tools cannot easily share information between tools
• It is not easy to provide a complete set of tools for all aspects of the SDLC
• Lack of methodology standards within organization, an organization that uses a
methodology not competitive with CASE tools will find it difficult to use CASE as a
match, CASE is simply another graphical, drawing or word processing package.
• Viewing CASE as a threat to job security
• Lack of confidence in CASE products.
Components of CASE
CASE tools support a variety of SDLCs
Upper CASE: CASE tools designed to support the information, planning and the project
identification and selection, project initiation and planning, analysis, and design phases of the
systems development.
Lower CASE: CASE tools designed to support activities that occur across multiple phases of the
SDLC eg. Tools used to assist in…. on going activities such as managing the project, developing
time estimates for activities and creating documentation.
Over the years, the vendors of these CASE products have opened up their systems through the
use of standard databases and data conversion utilities to more easily shared information across
products and tools. An integrated and standard database called a repository is the common
method for providing product and tool integration.

The general types of case tools are:-
1. Diagramming Tools
These enable the representation of the system process, data, and control structures
visually/graphically, e.g Data flow diagram (DFD) which is used to model business process as
information flows through an organization, entity relationship Diagram (ER).
2. Case Form and Report Generation Tools

These are the CASE tools that support the creation of computer display forms and reports in
order to prototype how the system will look and feel to users.
3. Case analysis Tools

These are CASE tools that enable automatic checking for incomplete, inconsistent or
incorrect specifications in diagrams, forms and reports. The type of analysis depending upon
the organization’s development methodology and the features of the CASE environment in
use.
4. Case Repository
Substantial benefits when using CASE can only be achieved though the integration of
various CASE tools and their data integrated CASE tools rely on common terminology,
notations and method for systems development across all tools. All L-CASE tools have a
common user interface. Hence, central to L-CASE is the idea of using a common repository
for all tools so that this information can be easily shared between tool and SDLC activities.
Repository is a centralized database that contains all diagrams forms and report definition,
process flows and logic and definitions of other organizational and system components. It
provides a set of mechanisms and structure to achieve seamless data - to - tool and data - to-
data integration. Within a repository there are two primary segments. Information’s business
combines information about an organization’s business information and its application
portfolio and provides automated tools to manage and control access to the repository.
Application portfolio consists of the application programs used to manage business
information repository. It provides facilities for recording, storing and processing
descriptions of an organization’s significant data and data processing resources. They are
valuable for a system analyst when cross referencing data items.
Cross referencing is a feature performed by a data dictionary that enables one description of a
data item to be stored and accessed by all individuals so that a single definition for a data
item is established and used. Such a description helped to avoid data duplication, and makes
systems development and maintenance more efficient. E.g. If one data element is changed,
the data dictionary can produce a report identifying all programs affected by this change.
Within all L-CASE environment, all diagrams forms, reports and programs can be
automatically updated by the single change to the data dictionary definition.
Case Repository and the SDLC

During the project initiation and planning phase the repository is used to store all information
both textual and graphical, related to the problem being solved. As the project evolves, the
repository becomes the basis for the integrations of the various SDLC activities and phases.

During the analysis and design phases of the SDLC the CASE repository is used to store
graphical diagrams and prototype forms and reports.
The data stored in repository is used to store graphical diagrams and prototype forms and
reports.
The data stored in repository are also used as the foundation for the generation of code
and documentation
Advantages of CASE Repository
• Integration mechanism on all cross life cycle tools and activities.

• Provide information to the project manager and allows him / her to exert amount
of control on the project by restricting members access to only the aspects of the
system they require.
• Software reusability – If all organization systems were created using CASE
technology with a common repository. It is possible to reuse significant portions
of prior systems in the development of the new one.
5. CASE Documentation (Operator tools)

These are modules that can creates technical and user documentation in standard formats for
each phase of SDLC, based upon the contents of the repository.
6. CASE code Generation Tools

These are automated systems that produce high level program source code from diagram
and forms used to represent the system.
Common Impacts of CASE on Individual within Organization
1) Systems Analysts
CASE automates many routine tasks of the analyst making the common skills (rather than
analytical skills) of the analyst most critical.
2) Programmers
Programmers will piece together objects created by code generators and 4th Generation
Languages. Their role will includes more of maintaining designs using diagramming tools
rather than source code.
3) Users
Will be much more active in the systems development process through the use of upper
CASE tools.
4) Top Managers
Will play an active role by using CASE – based planning and through user-oriented
systems development methods.

Categories of CASE products referred to as reverse engineering and reengineering tools are
breathing new life into existing systems by allowing old programs to be more easily modified to
run on new hardware configurations.
Reverse engineering is the process of creating design specifications for a system or program
module from program code and data definitions.
For example, CASE tools that support reverse engineering read program source code as in put,
perform an analysis and extract information such as program control structure, data logic and
data flows.
Reengineering tools are similar to reverse engineering tools but include analysis features that
can automatically, or interactively with a systems analyst, alter on existing system in an effort to
improve its quality or performance.
Visual and Emerging Development Tools

• O O Dev. Tools – Objects oriented development tools.
• Visual Dev. Tools - Visual studio, power builder, Delphi.

CHAPTER THREE
Project Identification And Selection

A system project begins with the recognition of a need of problem. Once a problem is brought to
light, the analyst must begin planning the steps required to reach a solution to the problem.
Project identification and selection consists of three principle activities.
a. Identifying potential development projects
b. Classifying and ranking projects
c. Selecting projects for development
1.) Identifying Potential Development Project:- Request for Service

The first communication of a problem or need to the information system staff is the request for
services. This can be performed by:-
• A key member of top management. These projects must have a strategic organizational
focus.
• A steering committee composed of a cross section of managers with an interest in the
systems. They more often reflect the diversity of the committee and therefore have a
cross-functional focus. The top management and steering committees are likely to have a
broader understanding of overall business objectives and constraints and therefore
projects identified by them reflect broader needs of the organization. They are referred to
as coming from top-down source.
• User departments, in which either the head of the department decides which project to
submit. Most often they have a narrow, tactical focus and are developed faster. Have a
characteristics of ease in integration with existing systems focus, e.g. hardware. There are
fewer development delays and less concern or cost benefit analyst.
The last two categories are generally referred to as coming from a bottom-up source. These
are the types of projects in which the analyst will have the earliest role in the life cycle as
part of the on-going support for users.
2.) Classifying and Ranking the IS Development Projects

This involves assessing the relative merit of potential projects and removing those deemed to be
inconsistent with overall organizational objectives, redundant in functionality to some existing
system or unnecessary. The same people involved in project identification can also do classifying
and ranking.
Possible evaluation criteria when classifying and ranking.

• Value Chain Analysis – Extent to which activities add value and costs when developing
products and/or services. Usually also includes a comparison with the activities, added
value, and costs of other organization for the purpose of making improvement in the
organization’s operation and performance.
• Strategic Alignment: Extent to which the project viewed as helping the organization
achieves its strategic objectives and long-term goals.
• Potential Benefits:- Extent to which the project is viewed as improving profits, customer
services, etc and the duration of these benefits.

• Resource Availability:- Amount and type of resources the project requires and their
availability.
• Project Size/ Duration:- Number of individuals and the length of time needed to complete
the project.
• Technical Difficulty/Risk:- Level of technical difficulty to successful complete the
project within given time and resource constraints.
3.) Selecting IS Development Projects.

This is the process of considering both short and long term projects and selecting those likely to
achieve business objectives. Numerous factors must be considered when making project
selection decision ie perceived needs of the organization, existing systems and on-going projects,
resource availability, evaluation criteria, and current business conditions.
Outcomes can occur from this decision, including; accept project, or reject. Accepting the project
implies that funding for the next phases of SDLC have been approved. There may also be
conditional acceptance or requests asked to modify and resubmit their requests making suggested
changes and modifications.
A selected project does not necessarily result in a working system due to the principle of
incremental commitment, where the project is reviewed after each phase and continuation of the
project is rejustified in each of these review since business conditions can change.

CHAPTER FOUR
Project Initiation and Planning (pip)

This is stage is aimed at transforming a vague system request document into a tangible project
description. A key consideration when conducting PIP is deciding when PIP ends and when
analysis begins.
The major activities that occur during this phase:-
• Project initiation
• Project planning
Project Initiation
Focuses on activities designed to assist in organizing a team to conduct project planning, some of
the activities carried out during this stage are as follows; however some may be unnecessary
depending upon the size, scope and complexity of the system.
• Establishing the project initiation team
Selecting those people within the organization who will become part of the analysis and
design team - requires matching people and skills to problems and circumstances. The
effective analyst should know the staff, their past work experience, and individual
personality traits as well as their technical strengths and weaknesses.
• Establishing a relationship with the customers
One or more analysts are assigned to work with a customer, i.e. a member of the business
group that requested or will be impacted by the project, to establish work standards and
communication procedures.
• Establishing the project initiation plan
• Establishing management procedure
Project Planning
Is the process of defining clear, discrete activities and the work needed to complete each activity
within a single project. The activities carried out may include the following; however these
depend on the size, scope and complexity of the project.
• Describing the project scope, alternatives and feasibility
• Dividing the project into manageable tasks
• Estimating resources and creating resource plan. Numerous assumptions about resource
and potential problems are made. The analysis justification for an information system
presented in terms of the tangible and intangible economic benefits and costs, and the
technical and organization feasibility of the proposed system.
• Developing a preliminary schedule – the time should be limited.
• Developing a communication plan
• Determining project standards and procedures
• Identifying and assessing risk
• Creating a preliminary budget
• Developing a Statement of Work (SoW)
• Setting a Baseline Project Plan (BPP).

The major deliverables and outcomes from this phase are the Baseline Project Plan (BPP) and
the Statement of Work (SoW).
The BPP contains all information collected and analyzed during project initiation and planning.
The plan reflects the best estimate of the project’s scope, benefits, costs, risks, resources
required, etc.
The BPP specifies detailed project activities for the next life cycle phase analysis. It is used by
project selection committee to help decide whether project should be accepted, redirected or
cancelled. If selected the BPP becomes the foundation documents for all subsequent SDLC
activities.
The Statement of Work (SoW) is a short document prepared for the customer that describes what
the project will deliver and outlines all work required to complete the project. SoW assures that
both you and your customers gain a common understanding of the project and is a very useful
communication tools.
Statement of Work
A sample SOW may include:-
• Title/Name of organization and Data of SOW
• Project Name
• Project Manager
• Customer
• Project sponsor
• Project Start/End (projected)
• Staff / Development estimates – Names and number of months.
Project Description Sample

This project will ………………………………………………………………………………………….
The purpose of this system is to automate the …………………………………………………….
save employees time, reduce errors ………………………………………………………………….
Objectives.
1.)……………………………………………………………………………………………….
2.)……………………………………………………………………………………………….
3.)……………………………………………………………………………………………….
Phases of work
The following tasks and deliverables reflect the current understanding of the project.
1.)……………………………………………………………………………………………….
2.)……………………………………………………………………………………………….
3.)……………………………………………………………………………………………….
In the Analysis…………………………………………………………………………………………….
……………………………………………………………………….....................................................
…………………………………………………………………………………..…………………………
…………………………………………………………………………..…………………………………
………………………………………………………………..………...................................................

The BPP is supposed to evolve as the project evolves i.e. new information learned during
subsequent SDLC phases will help in updating the BPP.
The Baseline Project Plan

This is a document where all the information collected during project initiation and planning are
collected and summarized into:
Contents:-
a) Introduction
Provides a brief overview of the entire document and outlines a recommended course of action
for the project.
Overview - Executive summary that specifies the projects scope, feasibility, justification,
resource requirements and schedules.
A brief statement of the problem - environment in which system is to be implemented, and
constraints that affect the project are provided.
Recommendation – Provides summary of important findings form the planning process and
recommendations for subsequent activities.
Scope
Name of Company………………………. Prepared by ………………………….
Statement of Project Scope Date:… ……………………………….

…………………………………………………………………………………………………………………
……………………………………………………………………………………………………………….
General Project Information

Project Name: …………………………………….
Sponsor………………………………
Project Manager …………………….
Problem/Opportunity Statement
1.)……………………………………………………………………………………………….
2.)……………………………………………………………………………………………….
3.)……………………………………………………………………………………………….
Project Objectives
1.)……………………………………………………………………………………………….
2.)……………………………………………………………………………………………….
3.)……………………………………………………………………………………………….
Project Description
Describe what the new IS will do………………………………………………………………………….
Business Benefits
1.)……………………………………………………………………………………………….
2.)……………………………………………………………………………………………….
3.)……………………………………………………………………………………………….

Project Deliverables
1.)……………………………………………………………………………………………….
2.)……………………………………………………………………………………………….
3.)……………………………………………………………………………………………….
Estimate Project Duration

…………………………………………………………………………………………………………………
…………………………………………………………………………………………………………………
………………………………………….
b) System Description
• Alternatives – provides a brief presentation of alternative system configurations.
eg. - Mainframe with central database
- Distributed with decentralized database
- Batch data input with online retrieval
- Purchasing of prewritten package.
At this stage, your objective is only to identify the most obvious alternative solution.
More details are covered during analysis stage.
• System Description – provides a description of the selected configuration and a narrative
of input information, tasks performed, and resultant function.
c) Feasibility Assessment
Provide a discussion, justification or analysis of all the feasibilities (feasibility study).
d) Management Issues
• Team configuration and management – provides a description of the team member roles
and reporting relationships.
• Communication Plan for managers, team members and customers
• Project standards and procedures – evaluation and acceptance of deliverables to the
customers.
Reviewing the Baseline Project Plan

Before the next phase of the SDLC can begin, the user, management, and development groups
must review the baseline project plan to assure that the proposed system conforms to
organizational standards and to make sure that all relevant parties understand and agree with the
information contained in the BPP.
This is done before presentation to any approval body. A common method of performing this
review (as well as review during subsequent life-cycle phases) is called a structured
walkthrough.
Walkthrough are peer group reviews of any product created during the systems development
process. Most walkthroughs are not rigidly-formal or exceeding long in duration. It is important
to have the following individuals playing specific roles:-
• Coordinator – Plans the meeting and coordinates a smooth meeting process. Maybe the
project leader.

• Presenter – Describes the work product to the group usually an analyst who has done
some or all of the work being presented.
• User - person/group that makes sure the work product meets the need of the project’s
customer. Someone not in the project team.
• Secretary – takes notes, records, decisions and recommendations
• Standards Bearer – Ensures that the work product address to organizational technical
standards.
• Maintenance oracle - Reviews the work product in terms of future maintenance activities.
The feasibility study

All projects are feasible given unlimited resources and infinite time but this is not the case with
most projects.
The purpose of the FS is to investigate the project in sufficient depth to be able to provide
information that either justifies the development of the new system or show why the project
should not continue. The findings of the IS are presented to the management in form of a report.
Most feasibility factors are represented by the following categories.
• Economic factors
• Technical factors
• Operational factors
• Schedule factors
• Legal and contractual factors
• Political factors
• Social factors.
Economic feasibility
This is a process of identifying the financial benefits and cost associated with development
project. It is often referred to as the cost-benefit analysis.
Determining Project Benefits

The IS can provide many benefits to an organization. They may be tangible or intangible.
Tangible benefits refer to the items that can be measured (cost) and with certainty eg.
• Reduced personal expenses such as automating monotonous jobs, or better inventory
management.
• Error reduction – time spent correcting data entry errors.
• Increased flexibility – reduction in the time normally taken to manually reorganize data
for different purpose.
• Improvement in management planning and control.
Intangible benefits refer to items that cannot be easily measured (cost) and with certainty, but
may have direct organizational benefits such as improvement of employee morale or societal
implications such as the reduction of waste creation.
Determining Project Costs.

These include both tangible and intangible costs.

Tangible costs are associated with an IS that can be measured in currencies and with certainty
such as h/ware costs, labour costs, operational costs, such as employee training and building
renovations.
Intangible costs include loss of customer goodwill, employee morale, operational inefficiencies.
Besides tangible and intangible costs, one can distinguish IS related development costs as either
one-time costs or recurring costs.
One-time costs refer to those associated with project initiation and development and start-up of
the system, eg. system development, new h/ware and s/ware purchases, user training, site
preparation data or system conversion.
Recurring costs refer to those resulting from the on-going evolution and use of the system, eg.
application s/ware maintenance, incremental data storage expense, incremental communications,
new s/ware and h/ware, equipment and service leases, and other expenses.
Technical feasibility
This is meant to gain an understanding of the organization ability to construct the proposed
system.
This analysis should include an assessment of the development groups understanding of the
possible target h/ware and operating environments to be used as well as system size/complexity
and the groups experience with familiar systems.
It also involves understanding the sources and types of technical risks of the project and how to
manage them.
The amount of technical risk associated with a given project depends on the following four
factors.
a) Project size - Number of members on the project team
- Project duration time
- Number of organization departments involved in project
- Size or programming effort
Large projects are riskier than small projects.
b) Project structure:-
New system or renovation of existing system(s) - organizational, procedural, structural,
or personnel changes resulting from the system. User perceptions and willingness to
participate in, with the effort of the management commitment of the system. A system in
which the requirement are easily obtained and highly structured, eg Payroll system, will
be less risky than the one in which requirements are messy, ill defined or subjected to
judgment by judgment of an individual eg. Executive Support System.
c) Development Group
Familiarity with target hardware, software development, environment, tools and
operating systems. Familiarity with building similar systems of similar size. The
development of a system employing commonly used or standard technology will be less
risky than one employing novel or non-standard technology.
d) User Groups
Familiarity with IS development process. Familiarity with IS proposed application area
Familiarity with IS using similar systems. A project is less risky when the user group is
familiar with the system’s development, process and application areas than if unfamiliar.
This enhances active involvement and cooperation between. The user and the
development groups

Operational Feasibility
This is the process of assessing the degrees to which the potential time frame and completion
dates for all major activities within a project meets organizational deadlines and constraints for
affecting change. Detailed activities may only be feasible if resources are available when called
for in the schedule.
Legal and Contractual Feasibility

The process of assessing potential legal and contractual reunifications due to constructions of a
system, possible considerations might include:-
• Copyright or non disclosure infringements, labor laws, antitrust legislation (which might
limit the creation of systems to share data with other organizations).
• Foreign trade regulations – Some countries limit access to employee data by foreign
corporations.
• Contractual obligations may include.
- Ownership of software for use of hardware or software.
- Typically legal and contractual feasibility, a great consideration if your organization
has historically used an outside organization for specific systems or services that you
now are considering handling yourself. In this case, ownership of program source
code by another party may make it difficult to extent an existing system.
Political Feasibility
Is the process of evaluation on how key stakeholders within the organization view the proposed
system. This is not supporting the project, it may take steps to block, disrupt, or change the
intended focus of the system.

CHAPTER FIVE
Analysis
The purpose of this phase is to fully understand the existing system and to determine the basic
information requirements needed to support the selected objectives and functions of the
organization. Analysis involves a substantial amount of effort and cost, and is therefore
undertaken after a full management approval.
The analysis process can be divided into 3 main activities to make the whole process easy to
understand.
1. Requirement Determination:- Fact finding activity.
2. Requirement structuring:- Creates a thorough and clear description of current business
operations and new information processing services. The results of the requirements
determination can be structured according to three essential views of the current and
replacement IS.
• Process – the sequence of data movement and handling operations within the
current system.
• Logic and Timing – The rules by which data are transformed and manipulated and
an indication of what triggers data transformation.
• Data – Shows the rules that govern the structures and integrity of data and
concentrates on what data, about business entities, and relationship among these
entities must be accessed within the system.
3. Alternative Generation and Selection:– Results in a choice among alternative strategies
for subsequent system design.
The three activities should be viewed as parallel and iterative.
1. Determining System Requirements

This is where we develop the user requirements. The information is gathered on what the system
should do, from as many sources as possible, i.e from users of the current system, from
observing users and from reports, forms and procedures.
Derivable and Outcome

1. Information collected from conversion with or observation of users, interview transcripts,
questionnaire responses, notes from observations.
2. Existing written information: business mission and strategy statements, procedure

manuals, job descriptions.
3. Computer-based information CASE repository contents and reports of existing systems,

displays and reports from system prototypes.
In addition to these deliverables, you need to understand the following components of the
organization.
1. Business objectives that drive what and how work is done.

• Determine the objectives of individual departments and establish whether they are
consistent with the objectives and plans of the whole organization.
• Determine whether the objectives are realistic and achievable.
• Establish whether there are relevant matters in deciding whether it would be
possible to improve the objectives of individual departments.
2. The information people need to do their job i.e how data (definition, volume, size, etc) is
handled.
3. Policies, Systems, procedures

• How has the department established its current policies and are they written
down.
• Determine whether the department policies are consistent with its objectives.
• Determine whether the policies are understood by staff or communicated to staff.
• Determine how the management ensures that the policies are adhered to.
4. Organization Structure
• Establish organization charts for the departments
• Establish whether responsibilities are clearly defined or relegated
• Establish whether the workload is efficiently shared among staff
• Establish whether the organization structure can be improved.
5. Operations and Controls

• Rules governing how data are handled and processed
• Key events affecting data values and when these events occur
• Exceptional cases dealt with and how they’re dealt with.
• Determine whether the quality of work is adequate or whether it can be improved
• Determine whether the efficiency can be improved.
6. Personnel
• Staff recruitment procedures, working conditions
• Whether staff are used to full potential
• Systems and procedures for job specification, approvals
• Adequate system for staff training and development.
7. Equipment and the office

• General condition of office equipment
• File storage methods
• Office layout.
Traditional Methods of Determining Requirements

The traditional methods of gathering data include:-
a) Interview
b) Questionnaires

c) Record inspection – Inspecting business documents
d) Observation – Observes workers at different times and see how data are handled and what
information people need to do their job
e) Group interviews/user workshop.
Interviewing and Listening

This involves correspondents between the interviewer and the respondent / interviewee. There
are two types of interviews:-
i) Structural interviews – with a set of questions prepared in advance and answers are
recorded in a standardized format. The interviewer asks only the set questions.
ii) Unstructured interviews – a number of key points are used to build the interview. The
interviewer may even vary the line of questioning during the interview.
General Guidelines for Effective Interview

• Plan and prepare thoroughly before the interview, set up an appointment at a time
convenient to the interviewee and explain the general nature of the advance. This may
involve asking him/her to think of specific questions or to review certain documents.
• Prepare checklist/interview guide to know which sequence you want to follow to ask the
questions and the estimated time.
• Write down the possible questions about what you want to find out
• Listen carefully and take notes (tape record if allowed)
• Review notes within 48 hours of interview
• Be neutral – do not phrase a question in a way to seek adv.
• Seek diverse views.
Sample Interview Outline

Interviewer’s Name: Interviewee’s Name:
Location/Medium: Appointment Date:
Office, conference RM: Start Time:
Phone number: End Time:
Objectives: Reminders
What data collected Background/experience of
on what to gain agreement Interview, know opinions
(eg. Content for certain report) of interviewee).
Agenda Approximate Time:

Introduction
Background on project…………..
Overview of interview………….
Topics to be covered…………….
Permission to tape record………..
Topic questions…………………

Summary of major points………………
Questions from interviewee…………….
Closing:
General observations:
Eg. Interviewee seemed busy – probably needs to call in a few days to follow up of questions
- Gave only short answer
- PC was turned off
Unresolved Issues:
Things of interviewee needs to lookup
Choice of Interview Questions

a) Open-ended questions – questions in interviews and questionnaires that have no pre-specified
answers. Used to probe for information for which you cannot anticipate all possible responses,
e.g. What would you say is the best thing about the IS you currently use?
Advantages
- Previously unknown information can surface – which can be explored to reveal more
information.
- Put the interviewees at ease since they are able to respond in their own words using
their own structure.
- Give interviewees a sense of involvement and control in the interview.
Disadvantages
- Time consuming
- Response summary is difficult
a) Closed-ended questions – Questions in interviews and questionnaires that ask those

responding to choose from among a set of specified responses such as:-
- True or false
- Multiple choice
- Rating a response – from bad to good
- Ranking items in order of importance
Advantages
- Takes less time
- More topics can be covered
- Work well when major answers to questions are known
- Unlike collecting the info-via questionnaire, you can see body language and voice
tone as an aid to interpreting the interviewee’s response
- You can include an “other” option to encourage interviewee to add unanticipated
responses.
Disadvantages
- Useful information that does not quite fit into the defined answer may be overlooked
- Interviews are a very effective way of communicating with people and obtaining
important information. However, interviews are very expensive and time consuming
to conduct.

Questionnaires
Structured interview forms with questions designed so that they can be answered without a face-
to-face encounter. They’re passive and often yield less depth of understanding than interviews.
Advantages
- Not very expensive to administer per respondent
- Information can be gathered from many people in a short time
- Less biased in interpretation of results
Choosing Questionnaire Respondents

You can achieve a representative sample by any one or any combination of these four factors.
• Those convenient to sample - willing or most motivated to respond
• A random group of current users if the list is known.
• A purposeful sample – Specify people to satisfy certain criteria.
• A stratified sample – Choose a random set from each category.
Designing Questionnaires
Ways of administering questionnaires are:-
• Self-administered questionnaires
• In person resembling a structured interview
• Over the phone, and websites etc
To create a good questionnaire.

• The questions must be extremely clear in meaning & logical in sequences.
• Ambiguity should be avoided in both the wording of the question & answer choices.
• It is wise to protect questions for both interview and questionnaire and use the feedback
to make them less ambiguous.
Group Interviews/ User Workshops

One drawback to using interviews and questionnaires to collect system requirements is the need
for the analyst to reconcile apparent contradictions on the information collected concerning the
current system or its replacement. Such a process requires several follow up (phone calls and
additional interviews) which may prove to be very expensive.
Another available option is the group interview several key people at once. This may be
conducted by more than one analyst.
Advantages
• Much more effective use of your time
• Interviewing several people together allows them hear the opinions of other key people
and give them an opportunity to agree or disagree.
• Synergies also often occur – comments of one person may add more idea to another
person.
Disadvantages
• Difficult in scheduling it by finding a convenient time and place for everyone techniques
of improving process of working with a group.

Observation.
This requires that the analyst observes the work process this helps to obtain more firsthand and
objective measures of employee interaction with IS. In some cases, behavioural measures will be
a more accurate reflection of reality of what employees themselves believe. In other cases, it will
substantiate what the employees themselves have told you. It is not always possible in a real
organizational setting. The method is not totally unbiased since observation can cause people to
change their normal operation behaviour.
Other disadvantages.
• Time consuming
• Only a limited number of people at a limited number of sites can be observed
• Yields only a small segment of data from a variety of data sources.
• Cannot be continuous hence you only find a snapshot image of the person or task you
observe which may not include important events of activities
Record (Document/ Procedure) Inspection & Analysis

The other method of determining system requirements can be enhanced by examining system
and organizational documentation to discover more details about current systems and the
organization that support of these systems. The documents may include organizational mission
statement, business plans, internal & external correspondence, reports from prior organizational
studies
In documents, you can find information about:-
• Problems with existing systems e.g missing information or redundant steps.
• Opportunities to meet new needs if only certain information or information processing
were available
• Reasons why current systems are designed as they are, i.e. which can suggest fractures
left out of current software, which may now be more feasible and more desirable.
• Data, rules for processing and principle by which Organization operates that must be
enforced by the IS.
• Files and names of key individuals
Modern Methods for Determining System Requirement

a. Nominal Group Techniques (NGT)
At the beginning of the process, group members work to generate ideas which are then pooled
under the guidance of a trained facilitator by asking each members of the ideas presented. As the
person reads the idea, someone else writes. After all ideas have been introduced, the facilitator
asks the group to openly discuss each idea
b. Using JAD during Requirement Determination

The traditional methods are still very much used by analysts to collect important information.
Joint Application Design (JAD), similar to a group interview however it follows particular
structure of roles and agenda that is quite different from a group interview. JAD sessions are
usually conducted in a location other than the place where the people involved normally work to
keep participants away from many distractions. It may last from 4hrs to a week and may consist
of several sessions.

Typical Participants
• JAD session leader - Trained individual who plans and leads the JAD sessions (s)he is
trained in group management and facilitation as well as in system analysis.
Roles:
Sets agenda and sees that it is in course
Remains neutral in systems analysis
Resolves conflicts and disagreement
Solicit ideas.
• Users – have a close understanding of what it means to use the system in a daily basis.
• Manager – Provide insight into new organizational directions, motivations for and
organization impacts of system and support for requirements determined during the JAD.
• Sponsor: can attend to learn from user and managers, not to run or dominate the process.
• Secretary – takes notes i.e. using laptops or p.c.
• IS staff e.g programmer, database analysts and data center personnel, may attend or lean
from the discussion and contribute possibly on this session.
The session should be in a room where participants sit around a horseshoe – shaped table,
equipped with white boards (possibly electronic), with a perimeter to make copies of what is
written on the board other audio/visual tools may be used. The end result of a JAD is a set of
documents that detail the workings of the current system related to the study of the replacement
system. CASE tools during JAD, the upper CASE tools may be useful to analysis during JAD eg.
diagramming tools and prototyping tools (computer form and report generation). The same tools
are useful for requirement structuring.
Problems with JAD

• No time for everyone to speak in a large group
• Some people dominate the meeting while others speak absolutely nothing.
• Some people are afraid to speak not for fear key will be criticized.
• Most people are not willing to criticize or challenge their bosses in meeting.
Supporting JAD with GSS (Group Support System)

GSS have been designed specifically to help aculeate some of the problems with group meetings.
Group members type their comments into computers rather than speak them. The GSS is set up
so that all members of the group can see what other members have been typing.
Benefits of using GSS in JAD.

• JAD leader is more likely to obtain contribution from everyone.
• Anonymity helps those who fear criticism because only the comment and not the person,
can be criticized
• Important ideas are less likely to be missed similarly poor ideas are more likely to be
criticized.

c. Using prototyping during requirements determination
Using prototyping during requirements determination, prototyping will allow you to quickly
convert basic requirements into a working, though limited, version of the desired I.S. This will
then be viewed and tested by users. This will enable the users to modify existing requirement and
generate new ones. The analyst then redesign the prototype to operate the suggested changes.
This becomes an iterative process.
Prototyping is most useful for requirements determination when:

• User requirements are not clear or well understood, which is the case for totally new
systems or systems that support decision making.
• One or a few users and other stakeholders are involved with the system.
• Possible designs are complex and require concrete form to fully evaluate.
• Communication problems have existed in the past between user and analysts and they
want to be sure the requirements are specific.
• Tools and data are readily available to rapidly build working systems.
Drawbacks of prototyping as a tool for requirements determination:-

• A tendency to avoid creating formal documentation of system requirements.
• Prototypes may not be easy to visualize for initial users and difficult to adapt to other
users.
• Prototypes are often build as a stand-alone systems, thus ignoring issues like sharing data
and interacting with other existing systems.
• Cracks in the SDLC are by passed so that some system requirements might be forgotten
(e.g. security)
2. Structuring system: (Requirements structuring process modeling)

The analysis team enters requirements structuring with and abundance of information gathered
during requirements determination. During requirements structuring, the information is
organized into meaningful representation of the IS that exists and of the requirements desired in
a replacement system.
This includes three models

• Process modeling
• Model of processing logic and trimming of events in the system.
• Data models – structure of data of the system
Process modeling
Involves graphically representing the function or processes, which capture, manipulate, store,
and distribute data between a system and its environments; between a system and its
environments are between components within a system.
A common form of a process model is a data flow diagram (DFD) which is one of the structure
analysis techniques. DFD is graphical tool that allows analysts to depict (model) the flow of data
in an information system, the relationship among the data flows, and how data can be stored at
specific locations.

Deliverables and outcomes
In structured analysis the primary deliverables from process modeling are a set of coherent,
interrelated data flow diagrams. This includes.
• Context DFD which shows the scope of the system indicators which element are inside
and which are outside the system.
• DFDs of current physical system specify which people and technologies are used in
which processes to move and transform data, accepting inputs and producing outputs.
• DFDs of current logical system (technology independents) show how data process
functions are performed by the current IS.
• Data movement (flow), structure, and functional requirements of the DFD is represented
in a logical DFD.
• Through descriptions of each DFD components and their entry into a project infirmary or
CASE depicturing
These deliverables are simply staring what has been learnt from the acquirements determination.
Advantages of DFD over the flowcharts

• They are easier to use than flow charts as they involve only four different symbols.
• They represent both physical and logical I.S although they are not as good as flowcharts
the details of physical system. Flowcharts the details of physical systems. Flowcharts are
not very useful for depicturing purely logical information flow since it is too physically
oriented.
• Flow chats have a problem of premature physical design unlike the DFD which do not
rely on any symbol to represent specific physical computing equipment.

Definitions and symbols.
There are two different standard sets of DFD symbols, but each set consists of four symbols, that
represent same things, data flow, data stores, processes and sources/sinks(external entries).
The sets of symbols were devised by Gane and Sarson (1979) and DeMacro and Yourdon(1970).
DeMarco and Yourdon Gane and Sarson
Process
Data Store
Source/Sink
Data Flow
A dataflow is the data in motion, moving from me place of the system to another eg. data on a
customer order from or a payroll check. A dataflow could represent the result of query to a
database, the contents of a printed report, or data on a data entry computer display form.
A datastore is data at rest, which may take the form of many different physical locations for data
as a file folder, computer based about customers, students customer orders, or supplier invoices.
A process is the work or admits performed on data so that they are transformed, stored, or
distributed.
A source/ sink is the origin/destinations of the data.
X-tics of source and sink which are of interest to us.
• Interactions that occur between sources and sinks
• What a source/sink does with information or how it operates
• How to control/redesign a source/sink
• How to provide sources and sinks direct access to stored data
• A dataflow is depicted as an arrow in both the conventions. The arrow is labeled with a
meaningful name whichrepresent the aggregation of all the undivided elements of data
moving as part of one packet.
• A square is used in both conventions for sources/sinks and has a name that states what
the external agent is eg, customer, teller, inventory control system.

For Gane & Serson symbol for process, the upper portion is used to indicate the number of the
process. Inside the lower portion is a name for the process, such as generate a pay check, educate
the overtime pay.
Gane & Serson symbol for datastore is an rectangle that is missing i.e right vertical side at the
left and is a small box used to number the data store and inside the main part of the rectangle is a
meaningful label for the datastore eg. student file, transcripts. The DeMarco data store symbol
consists of a square with smooth edges, which may be depicted horizontally or vertically.
A source/sink may consist of

• Another organization or organization unit that sends data to as receiver information from
the system you’re analyzing eg a supplier.
• A person inside/ outside the business unit supervised by the system you’re analyzing and
who interacts with the system, e.g customer.
• Another I.S with which the system you’re analyzing exchange information.
Example
Suppose you want to automate the operations of a busy restaurant. The physical subsystems are
Kitchen, dinning room, counter, storage and office. The subsystems interact and work together.
The environment consists of customers, food distributors, banks and neighborhood competition.
There is one interface i.e the counter where customers place order and another at the back door
where food and supplier are delivered. Another interface is the telephone that the managers use
regularly to talk with bankers and food distributors.
The highest-level view of the system is shown in a context diagram as follows
Customer Kitchen
Customer order 1.0

Food order
Food Ordering System
Receipt
Management Report
Restaurant
Manger

The context diagram contain only one process, labeled “0” and represented and represents the
entire system. Also included are the external entities (source/sink) that interact with the system
and are major information flows between the entities and the system.
The next step is to draw the level – 1 diagram, a data flow diagram that represents a systems
major process, data flows, and data stores at a high level of detail.
Customer Kitchen
1.0
Customer order
Receive and transform Food order
Receipt customer food order
Inventory
2.0 data 3.0
Goods
Update goods sold Update inventory
Sold
file file
Format goods sold Format inventory data
D2 Goods sold file Inventory File

D1
A/C
Daily goods sold

amount
4.0 Daily inventory

depletion amounts
Produce
management report Management Report Restaurant
Manger

Rules Governing DFDs
1. Process – Has a verb phrase label
2. Datastore – Data must be moved by a process from one datastore to another
• Data cannot move directly from an outside source to a datastore but via a process
• Data cannot move directly to an outside sink from a data store but must be moved by
process.
• Has a verb phrase label.
3. Source/sink
• Has a noun phrase label
• Data cannot move directly from a source/sink.
4. Date flow
• Has a verb phrase label
• Has only one direction of flow between symbols
• A fork in data flow indicates different locations.
• A joint means that exactly the same data comes form only of two or more different
processors/datastores/source /sinks to a common location.
• Cannot go directly to the same process it leaves.
• A data flow from a datastore means return or use
• A data flow to a datastore means updated (delete or change).

Functional decomposition of DFDs
FD is a directive process of breaking the description of a system down into firm and detail,
which accents a set of hierarchically related chart in which one on a given chart is explained in
greater detail on another chart.
The lowest level of DFDS is called a primitive DFD. Example decomposing process 1.0 into sub
processes.
1.1 1.3
Customer
Customer Receive Customer Order Transform Order
Order Order Forward
Cost Order
1.4
Customer Order Generate Goods Sold

Increments
1.2 1.5
Generate Customer Generate Inventory Inventory Data

Receipt Decrement
This is called level-2 diagram
In general, a level-1 diagram is a DFD that is generated form nested decompositions from a
level-0 diagram.

EX: Draw a level –2 diagram showing the decomposition of process 4.0 from the
level - 1
4.1 4.2
Daily goods Accessory goods sold Aggregate goods sold

Inventory
inventory and inventory data
sold amount data
Goods sold
data
4.0
Prepare management Management
report report
The DFD must be balanced.

Balancing is the conservation of inputs and outputs to a data flow diagram process when the
process is decomposed to a lower level.
Types of DFDs
a) Current Physical DFDs
- The process labels include the names of people as their positions or names of computer
systems that might provide some of the overall systems processing.
- Data flows and data stores are often labeled with the names of the actual physical media on
which data flow or in which data are stored.
b) Current Logical model

The physical aspects of the system are removed as much as possible so that the current
system is reduced to data and the processes that transform them, regardless of actual physical
form.
c) New Logical model

- Same as the current logical model but having additional functions, obsolete functions
removed, and inefficient flow reorganized.
d) New physical DFD

Represents the new physical implementation of the new system.

Guidelines for drawing DFDs
a) Completeness
The extent to which all necessary component of a DFD have been included and fully
described
b) Consistency
The extent to which information contained on are level of a set of nested DFDs are also
included on other levels eg. a level diagram with no level – 0 diagram is inconsistent.
c) Timing
The DFD do not represent timing very well
d) Iterative Development
The first DFD you draw will already capture perfectly the system you’re modeling. You
should draw the same diagram over and over again, in an iterative fashion.
Primitive DFDs
Are the lowest level of decomposition for a DFD.
Rules for when to stop decomposing
• When you have reduced each process to a single decision or calculation or a single data
process operation, such as retrieve update.
• When the system user does not care to see any more detail
• When every data-flow does not need to be split in different ways.
• When you believe there is a separate process for each choice of all lowest level more
options for the system.
Logic Modeling
This involves representing the internal structure and functionally of the processes represented in
the DFDs deliverables and outcomes.
Structure description and diagrams that outline the logic contained within each DFD process as
well as diagrams that show the temporal dimension of system (events and states).
The diagrams are used to serve as unambiguous and through explanation of the system’s
specification, which are used to explain the system requirement to developer’s (people or tools)
code generation.
Ways to model logic

Each process on the primitive DFDs will be represented with one or more of the following.
• Structure English
• Decision table
• Decision text
• State transition diagram
• Sequence diagram
• Activity diagram.

Structured English
A modified form of English that is used to specify the contents of process boxes in DFDs. It uses
a subset of English vocabulary to express information system process procedure.
This includes such verbs as read, write, permit, sort, move, merge, add, subtract, divide,
multiply.
It is aimed at representing the process in a shorthand manner that is relatively easier for users and
programmers to understand.
It is intended to be used as a communication technique for analysts and users. Analysts and
programmers communicate via pseudo-code, English dialect varies with analyst, but it must
represent sequent, conditional statements and repetitions in the I.S process.
Invoice
Supplier Stock at
hand
Counts
1.0 2.0
Pay Invoice Update inventory Update inventory

added Used
Amount added
4.0
Amount
Generate payments D1 Inventory used
Inventory
Order 3.0
level
Generate order
Minimum order
quantities
Process 1.0: Update inventory added

DO
READ next invoice item record
FIND MATCHING monitory record
ADD QUARTETS added from invoice item record is to quantity in stock on inventory record.
UNTIL End of file

Process 2.0: Update inventory used
DO
READ next stock item record
FIND matching inventory record
SUBTRACT Quantity used on stock item record from quantity in stock on inventory file
UNTIL End of file.
Process 3.0: Generate orders

DO
READ next inventory record
BEGIN IF
If quantity in stock is less than minimum order quantity
THEN generate order
END IF
UNTIL Ending of file
Process 4.0: Generate payments

READ Today’s date
DO
SORT invoice records by date
READ next invoice record
BEGIN IF
If DATE is 30 days or generate than today’s date
END IF
UNTIL end of file
Decision Tables
A matrix representation of the logic of a decision which specifies the possible conditions for the
decision and the resulting actions.
It has three parts
• Condition stub - list the conditions relevant the decision
• Action stub – That part of the decision table that list the actions that result for a given set
of conditions.
• Rules – Specify which actions are to be followed for a given set of conditions.
• Indifferent conditions - a condition whose value does not affect which actions taken for
two or more roles.

Example
The Decision Table showing a generic payroll systems
Conditions AND Rules

Course of action 1 2 3 4 5 6
Condition Employee type Salaried Hourly Salaried Hourly Salaried Hourly
Stub Hours worked <40Hrs <40Hrs 40Hrs 40Hrs >40Hrs >40Hrs
Pay Basic Salary ☺ ☺ ☺
Calculate Hourly ☺ ☺ ☺
Action Stub
CalculateOvertime ☺
Absence Report ☺ ☺
Basic procedures in constructing the decision table

1. Name the conditions and the values that each condition can assume, determine all the
conditions that are relevant to your problem. The conditions may be of limited entry
(Yes/No) or extended answers.
2. Name all possible actions that can occur
3. List all possible rules
4. Define the actions for each rule
5. Simplify the decision table.
Decision Trees
A graphical representation of a decision or choice situation as a connected series of nodes and
branches.
They have two main components
• Decision point represented by nodes
• Action represented by ovals
Each node is numbered starting from the root node. Each number corresponds to a choice, the
choices are spelled out in a legend for the diagram.

Example
Absence Report
True
1
False Basic Salary
True
2
False Calculate Over-time
True
3
False
Legend
Calculate Hourly Wage
1 Hours worked < 40
2 Hours worked = 40
3 Hours worked > 40
Criteria for deciding between decision table and decision trees
Criteria Decision Table Decision Trees

Portraying complex logic Best Worst
Portraying simple problem Worst Best
Making decision Worst Best
More compact Best Worst
Easier to manipulate Best Worst

CHAPTER SIX
Design
This is the first phase of the System Development Life Cycle in which the analyst and the users
develop a concrete understanding of how the system will operate.
The design of a new system can be divided into the following elements.
(a) User interfaces and Dialogues
(b) Inputs and Output – involves designs of forms and reports, visual display, printed
documents and other kind of media for presenting data. It is necessary to consider what is
required from the system before deciding how to produce it.
(c) File or database & components
(d) Procedures and programs
(e) Finding design specifications
(f) Processing and integrity are not necessarily sequential – for example the design of data,
system input and output, and interface interact to identify flaws and missing element.
Output
The bottom line reason for any system is, its output represents the information that results from
processing the raw data.
The specification of what output the user wants from a system, dictates both requirements for
input and files in the system. Output design will cover three separately identifiable types of
results.
• External output – is produced by system for use outside the company e.g invoices
purchase orders, withdrawal receipts in banks e.t.c
• User Output – Serves for clerical or auditing functions e.g management reports, error
reports and audit listing.
• Internal Output – information relating to the operation of the system itself, such as file
usage or performance reports, a system operating statistics and control totals reports
Most of the outputs are given inform of forms and report.

Form :– A business document that contains some predefined data and may include some areas
where additional data are to be filled, in most forms have a stylized format and are usually not in
a simple row and column format. Examples are product order forms, employment applications
and class registration sheets. In general, forms are used to present and are to collect information
on a single item such as a customer, product or event i.e they are used for both input and output.
Report :- Business document containing only predefined data; it is a passive document used for
reading or viewing. A report typically contains data from many unrelated records or transactions
often a report has rows and columns of data, but a report may consist of any format.
Input Design
The design of input is important because in most computer systems, data is first of all collected
in human – sensible form and must be converted into computer input.

There are four basis input design considerations
(i) Reduce input volume to its minimum by:
• Entering only variable business data
• Keeping most data on files or database
• Using programs to generate data.
(ii) Analyze output result to determine input content
(iii)Design source document to reduce data volumes
(iv) Control actability of input data.
Once the output of the system is defines, it is analyzed to determine the input data requirements.
Deliverables and outcomes of the input/ output design

The design specifications are the major deliverables and are inputs to the system implementation
phase. A system specification is a detailed documentation of the proposed new system. It serves
two main purposes:
(i) Communication- It serves as a means of communicating all that is required to be known to all
interested parties such as the management, programmers, IS operating staff (to provide them
with detailed operating procedures) and users.
(ii) Record: It serves as a permanent record of the system in detail. This is useful; for evaluating
and multiplication training purposes.
Design Specification has three sections

(i) Narrative overview – contains a general overview of the characteristics of the target users,
task system, and environmental factors in which the form or report will be used, The
purposes is to explain to those who will actually develop the final form, why this form exists
and how it will be used so that they can make the appropriate implementation decisions.
A Sample narrative overview is shown below:

Form : Customer Account Status
User : Customer Account information, address, account Balance, year to
date purchase and payments, credit limit, discount percentages
and account status.
System : Novel network, Microsoft windows
Environment : Standard Office environment
(ii) Sample Design

A Sample design of the forms may be hand – drawn or development using CASE or standard
development tools.
(iii)Testing and usability assessment.

This gives all the information on the testing and usability assessment
A sample testing and usability assessment is shown below:
a.) Use rated perception (coverage 14 users)
Consistency I = consistent to 7 = inconsisent : 1:52
Sufficiency 1 = sufficient to 7 = insuffient : 1 :43
Accuracy 1 = accurate to 7 = inaccurate : 1: 67
….

b.) Assessing Usability:
These are many factors to consider when you design forms and reports. The objective for
designing forms, reports, and all human – computer interactions is usability.
Usability is an overall evaluation of how a system performs in supporting a, particular user

for a particular task. It include the following characteristics
• Speed
• Accuracy
• Satisfaction.
General design guidelines for usability of forms and reports

• Consistency: Consistent use of terminology, abbreviations, formatting, and
narration within and across output
• Efficiency
• Ease – Outputs should be self explanatory, labels should be extensively used.
• Format – Information format should be consistent between entry and display.
• Flexibility - Information should be viewed and retrieved in a manner most
convenient to user, file and / or database design. After defining what the system
will produce effort terms to the type of data storage to be used.
Definitions:
File – a named collection of related data it can contain; program instructions, text and data,
numerical data and graphics
Database - a shared collection of logically related data, stored with minimum duplication and
designed to meet the information needs of multiple users in an organization
Database Management system (DBMS) - A suit of programs that help to manage the database by
facilitating shared access to data, maintain reliability, security and integrity of the data.
Database design
1. Structure the data in stable structures called normalized table, that are not likely to
change over time and that are not likely to change overtime and that have minimum
redundancy
2. Develop a logical database design that reflects the actual data requirement that exist in
the forms and reports of and information system.
3. Develop a logical of an information system - we can do physical database design.
4. Translate a relational database model into a technical and database design that balance
several performance factors
5. Choose data storage technologies
Files and database design occur into steps.

1. Developing a logical database model, which describes data using a notation that
corresponds to a data organization used by DBMS such as Oracle, MsAccess, or SQL
server. The common style for a logical database model is the external database model.

2. Physical database design is used to prescribe the technical specification for computer files
and database in which to store the data.
These two steps are carried out in parallel.
Relational database Model –

Many database modes are in use:
• Inter-graphical model
• Network Model
• Relational model (most commonly used)
• Object oriented database model (new technology)
The relational database model represents data in the form of related table or relations.
A relation is a named two-dimensional table of data each relation consists of a set of named
columns and an arbitrary numbers unnamed rows, each column of a relation corresponds to an
attribute of that relation, each row of a relation correspondents to a record that contains data
values for an entity.
For example, a relation named EMPLOYEE can have attribute such as empID, name, dept, and
salary you can express the structure of a relation by a short hand notation in which the name of
the relation is followed in parenthesis by names of the attributes in the relation. The identifier
attribute (Primary key) is underlined as shown below.
EMPLOYEE (empID, name, debt, salary);
Not all tables are relations. Relations have several properties that distinguish them from non
relational tables
• Entries in cell are simple- having a single value
• Entries in a given column are from the same set of values.
• Each row is unique
• The sequences of columns can be interchanged without changing the measurers or
use of the relation
• The rows may be interchanged or store in any sequence.
Well Structured Relations

These are relations that contain minimum amount of redundancy, allow users to insert, modify,
and delete the rows without errors or in consistencies.
Normalization:
This is a process for converting complex data structures into simple, stable data structures. It
helps in designing a well structure relation. Normalization is based on the analysis of functional
dependence.
A functional dependency, for a given relation, attribute B is functionally dependent on attributed
A represented by A-B, if for every valid value of A, uniquely determines the value of B for
example, EmpID – Name functional dependence does not imply mathematical – that the value of
one attribute may be corrupted from the value of another attributes, rather A – B means that these
can only be one value of B for each value of A.

An attribute may be functionally dependent on two or more attributes. For Example, consider the
following relation.
EMPOYEER ( EmpID , Name , Dept, Salary, Course, Date completed)
This relation is not well structured since it contains data about two entries, Employee and
Course, an employee can teach several courses.
We can have EmpID, Course, and Date completed as the instance or sample data. In a relation,
do not prove that a functional dependency exists. Only knowledge of the problem domain,
obtained from a thorough requirements analysis, is a method for identifying a functional
dependency. However, you can use a sample data to demonstrate that a functional dependency
does not exist between two attributes.
Example
A B
X Z
Y X
Z Y
Y Z
The sample data in this relation proves that B is not functionally dependent on attribute A
because A does not have a uniquely determination.
Rules of Normalization
Normalization is based on a well accepted principle and rules besides the five properties of
relations outlined above, these are two other frequently used rules.
1. Second Normal Form (2NF)

A relation is in 2NF if every non primary key attribute is functionally dependent on the whole
Primary Key. 2NF is satisfied if anyone of the following conditions apply
• The primary key consist of only one attribute e.g empID in relation EMPLOYEE
• No non primary key attributes exist in the relation
• Every primary Key attribute is functionally dependent on the full set of primary
attribute.
The EMPLOYEE relation in the above example is not in 2NF. The functional dependencies in
this as follows:
EmpID, Name , Dept, Salary

EmpID, Course, Date Competed.
The non- primary key attribute name, dept and salary are functionally dependent only on EmpID
but not on course. Therefore EMPLOYEE has redundancy which results in problems when the
table is updated.
To convert a relation to 2NF, you decompose the relation into new relations using the attributes
called Determinant, that determine other attributes; these are the primary keys of these relations
EMPLOYEE2 is decomposed into the following two relations:

(i) EMPLOYEE (EmpID , Name, Dept, Salary)
(ii) EmpCourse (EmpID , Course, Date completed)
2. Third Normal Form (3NF)

A relation is in 3NF if it is in 2NF and there are no functional dependency between two or more
non primary key attributes (a dependency called a transitive dependency)
Example: Consider the following relation
SALES ( customerID , customer_name, sales_person, region)
This relation is in 2NF, the primary key consists of a single attributes (customerID)
The following functional dependencies exist in the sales relations.
• SALES (customerId, customer_name, sales_person, region)
• SALES1(sales_person, region) //each sales person is assigned to a unique region//
Since these exist transitive dependencies in the relation, there may be data maintenance problems
• If a single customer number is deleted from the table, we lose the information that
the salesperson associated with the customer is assigned to a specific region.
• If a single salesperson is assigned to another region, several rows must be
changed to reflect that fact.
These problems can be avoided by decomposing SALES into two relations based on the two
determinants persons (sales_person, region)
Note the salesperson is the primary key in person and is also a foreign key in SALES1
A foreign key is an attribute that appears as non primary key attribute in one relation and as a
primary key attribute in another relation. A foreign key must satisfy referential integrity, which
specifies that the value of an attribute in one relation depends on the value of the same attribute
in another relation.
Transforming Entity-Relation diagrams into relations an Functional-Relation diagrams is
transformed into normalized relations by following well – defined principles for example, each
entity becomes a relation and each many relationships or associative entity also becomes a
relation.
Separate sets of normalized relations are merged

A process known as View Integration - is to create a consolidated logical database design. The
different sets of relations come from the conceptual E.R diagram for the application, known
human system interfaces (explore, screens forms) and known or anticipated quarters for data
which meet certain qualifications. The result of merging is a comprehensive, normalized set of
relations process. A system analyst must address issues of synonyms (two different names used
for the same attributes), homonyms (single attribute name used for two or more difference
attribute) and functional dependencies between non key attributes during view integration
Physical File and Database Design

Designing physical files and databases requires certain information that should have been
collected and produced during prior SDLC phase. This information includes:-
• Normalized relations, including volume estimates, number of rows in each table.

• Definition of each attribute
• Description of where and when data are used, entered, retrieved, deleted and updated
including frequencies.
• Expectations or requirements for response time and data integrity
• Descriptions of the technologies used for implementing the files and database so that the
range of required decisions and choices for each is known.
• Expectations or requirements for response time data integrity
• Descriptions of the technologies used for implementing the files and database to that the
range of required decision and choices for each are known.
You must also know the type of files to develop in general, there are seven types of files. Each
one is useful to different data classifications.
• Masterfiles: Dynamic or changing files - These hold most of the permanent or variable
data within the system.
• Transaction files: Temporary files that record the occurrences of the business later posted
or updated into the masterfile.
• History files: Static files, copies of old master or transaction files
• Reference files: Abbreviated files used to aid processing of data
• Work files: Temporary files created for the use of a program e.g sort files
• Report files: Print files - store an image of the output and may either be deleted or stored
on other media for archival purposes.
• Restart files: Temporary files that are created by long running programs.
The Design Consideration include:-

1. Designing Fields
A field is the smallest unit of application data recognized by DBMS. An attribute from a logical
database model may be represented by several fields eg. A student name attribute may be
represented as 3 fields, last name, surname, Christian name. The basic decision you must make
in specifying each field concern the type of data (or storage type) and the data integrity control
for the field
2. Designing Physical Tables

A physical table is a named set of rows and columns that specifies the fields in each row of task.
It may or may not correspond to one relation.
Reason for designing physical tables
• Efficient use of secondary storage and data processing speed.
Denormalization is the process of splitting (partitioning or combining) normalized relations into

physical table based on affinity of rows and fields
Example:
Normalized product relation
Product (Product-ID, Description, Drawing, Number, weight, colour, unit-cost, Burden-rate,
price, product-manager).

Demoralization Functional Area Product relations for tables:
Engineering:Engineering_product( Product - ID, Description Drawing Number, Weight, Colour).
Accounting: A_Product (Product-ID, unit cost, Burden rate)
Marketing: M_Product (Product-ID, Description, colour, price, product manager).
The result of demoralization is the definition or one or more physical files.
A physical file is a named set of table rows stored in a contiguous section of secondary memory.
The way in which the operation system arranges table rows (records) in a file with a view to the
retrieval of data/information is called file organization.
Types of File Organization

1) Sequential file Organization
The rows in the file are stored in sequence according to a primary key value eg. in an
alphabetical order or in a numerical order. To locate a particular row, a program must normally
scan the file from the beginning until the desired row is located.
Advantages
- No wastage of storage space
- Very fast sequential retrieval of primary key
Disadvantages
- Impractical random retrieval on primary key
- Multiple key retrieval is possible but requires scanning whole file.
- Deleting rows can cause wasted space or the need to compress the file.
- Updating a row may also require rewriting the file, unless the file organization
supports rewriting over the updated row only.
- Only one sequence can be maintained without duplication the rows.
2) Indexed File Organization

The rows are stored either sequentially or non-sequentially, and an index is created that allows
software to locate individual rows.
An index can point to a unique row or to potentially more than one row. An index that allows
each entry to point to more than one record is called a secondary index. A secondary key is one
or a combination of fields for which more than one row may have the same combination of
values.
Features
• No wastage of storage space but extra space for index.
• Moderately fast sequential retrieval
• Very fast multiple key retrieval
• Deleting rows is possible if space can be dynamically allocated but requires maintenance
of indexes. The same applies to adding rows.
• Updating rows is easy but requires maintenance of index.
3) Hashed File Organization

The address for each row is determined using an algorithm that converts a primary key value into
a row address. In most cases the rows are located non-sequentially.

Features:
• Very fast random retrieval.
• Very easy to delete, add or updates rows
• Extra storage space may be needed to allow for addition and deletion of records
• Sequential retrieval is impractical.
Designing Interfaces and Dialogues

Interface design focuses on how information is provided to and captured from users; dialogue
design focuses on the sequencing of interface displays.
Dialogues are analogous to conversations between two peoples.
Deliverables and Outcomes

The deliverables and outcomes of the design is the same as the ones for designing forms and
reports except that one section is added in the specification:-
i) Narrative overview
ii) Sample design
iii) Testing and usability assessment
iv) Dialogue sequence – the ways a user can move from one display to another.
Interaction Methods and Devices

Interface is a method by which users interact with information systems. The following are the
methods of interacting:-
1) Command language Interaction

This is a human computer interaction (HCI) method where users enter explicit statements into a
system to invoke operations.
It puts burden on users to remember names, syntax and operations. However, it is good for
experienced users, for systems with a limited command set and for rapid interaction with the
system.
2) Menu Interaction
This is a human computer interaction method where a list of system options is provided and a
where a list of system options is provided and a specific command is invoked by user selection
of a menu option. A menu is simply a list of related options that invoke a command. There are
two common methods of positioning menus:-
Pop-up Menu: Places a menu near a current cursor position. They show a list of
commands related to the current cursor position.
Drop-down Menu: Places the access point of the menu near the top line of the display;
when accessed, menus open by dropping down onto the display.
3) Form Interaction
This is a highly intuitive human computer interaction method whereby data fields are formatted
in a manner similar to paper based forms. It allows users to fill in the blanks when working with
the system. It is effective for both the input and presentation of information. An effectively
designed form includes a self-explanatory little and field headings, has fields organized into

logical groups with distinctive boundaries, provides default values when practical and minimizes
the need to scroll windows.
4) Object Based Interaction

Is a method where symbols (icon) are used to represent commands or functions. The advantage is
that icons take less screen space and can be quickly understood by most users.
5) Natural Language Interaction

The inputs to and outputs from a computer – based application are in a conventional speaking
language such as English eg. in database queries. Current implementations can be tedious,
frustrating and time consuming for the user and are often built to accept input in narrowly
constrained domains.
Hardware Option for Interaction

The selection of hardware devices users will use for interaction must be made during logical
design since different interfaces require different devices. These devices include keyboard,
mouse, joystick, trackball, touch screen, light pen, graphic tablet and voice input.
Designing Layouts
To ease user training and data recording, you should use standard formats for computer based
forms and reports similar to paper based forms and reports for recording and reporting
information.
Structuring Data Entry Fields

Several rules should be considered when structuring data entry fields on a form.
• Never require data that are already online or that can be computed e.g. do not enter
customer data on an order form if that data can be retrieved from the database, and do not
enter extended prices which can be computed from quantity sold and unit prices.
• Always provide default values when appropriate eg. current dates, standards product
prices unless overridden.
• Make clear the type of data units requested for entry eg. indicate the quantity in dozen,
Kgs, etc.
• Use character replacement when appropriate eg. allow the user to look up the value in a
table enters enough significant character.
• Always put captions adjacent to fields.
• Provide formatting examples when appropriate eg. decimal points, currency symbols.
• Automatically justify data entries.
• Provide context – sensitive help when appropriate.
Designing Dialogues
This is the process of designing the overall sequence that users follow to interact with an
information system. A dialogue is to sequence in which information is displayed to and obtained
from a user. As a designer, you should select, the most appropriate interaction method and
devices and to define the conditions under which information is displayed and obtained from
users. There are three major steps:-
1) Designing dialogue sequence

2) Building a prototype for complex systems
3) Assessing usability.
Security and Integrity Requirements

Data security is the prevention of data from accidental or deliberate threats which might cause
unauthorized modification, disclosure or destruction of data.
There are three types of data security

- Those concerned with prevention of loss of data
- Those concerned with prevention of misuse or unwanted modification of data eg. due
to access by unauthorized persons.
- Those concerned with prevention of disclosure of data to unauthorized persons.
Causes of Data Insecurity

a) Theft, Fraud, Espionage
Tapes and disks can be stolen information may be disclosed to unauthorized persons.
b) Technical
Faults within the hardware, software may damage or destroy the information in files
c) Environmental
Tapes and disks may be destroyed if exposed to harsh environmental conditions.
d) Processing
Entering of incorrect data
e) Viruses – May modify or destroy data or cause malfunction of hardware
Control measures
Physical Security
These control computer fraud, embezzlements, and unauthorized access. The measurers include.
• System development and maintenance control. This ensures development of effective and
adequately controlled system eg. defining accounting polices o\and record-keeping
procedures prescribed by taxing and regulatory agencies.
• Segregation and rotation of duties – This means that duties are defined and segregated to
specific user areas for providing checks and balances. Personnel should be rotated
periodically.
• Authorization of software installation and use of foreign storage media.
• Enforcement of physical security such as burglar proofing, and security guards.
• Enforcing safety measures such as extinguishers. Fire detectors, fireproof cabinets.
• User of computers with lockable keyboards.
• Use of power stabilizers or UPSs.
System Security
System security emphasizes the need to maintain the integrity of the system software, programs,
and data when the system is in use. The analyst must give attention to the protection of the
system long before it is in production.

Forms of system security measures
a) Passwords
These control the access to the system. They can also be used for specific programs requiring
protection such as order writing and billing systems.
b) System Backups
Any good system has a predefined schedule for system backup. The backup, whether on tape or
removable disk or CD, because one may loss valuable data if the system crashes, or if data is
inadvertently lost. Scheduling system backups depends on the nature of data contained in the
system
c) Audit Trails
This is a documentary evidence of the activity within the system. It can be an activity reports of
file updates, a data file dump of pre-processing contents or control reports. These documents
system monitoring.
d) Use of Antiviruses
Finalizing Design Specification

Before the task of detailed system construction can be pursed on the programmers, many more
aspects of the system have to be specified. The results of all this detailed work is the design
specification document, also known as software requirements specification.
The specification document is one of the major deliverables from the design phase of the systems
development life cycle (SDLC).
The design specifications include functional descriptions for each part of the system, as well as
information about input received and output generated for each program and its component parts.

CHAPTER SEVEN
System Implementation
The purpose of implementation is to build a properly working system by turning the physical
specifications into working computer code, testing the code, installing the system, finalize
system and user documentation, train users and prepare support system to assist users.
Implementation phase of the SDLC, is only second to maintenance in cost and time
consumption.
System implementation is made up of many activities
• Coding
• Testing
• Installation
• Documentation
• Training
• Support
Coding
The process whereby the physical design specifications created by the analysis team are turned
into working computer code by the programming team.
Testing
Once coding has begun, the testing process can begin and proceed in parallel. As each individual
module is produced, it can be tested individually, then as part of other larger system.
Testing S/ware begins earlier in the SDLC even though many of the actual testing activities are
carried out during implementation. During analysts you develop a master test plan which
specifies what each person’s role will be during testing. The test plan also servers as a checklist
to determines whether all of the master test has been completed.
Since at least some of the system testing will be done by people who have not been involved in
the system development, there should be an introduction in the test plan to provide general
information about the system and the needs for testing.
Types of Tests
1) Inspections:- This is a testing technique in which participants manually examine code for
occurrences of well-known errors. The code is compared to a checklist of well-known
errors of the language.
2) Desk checking:- This is an informal process where the programmer or someone else who
understands the logic of the program works through the code manually
3) Unit Testing/Module Testing:- Each module is tested alone in an attempt to discover any
errors in its code.
4) Integration Testing:- The process of bringing together all of the modules that a program
comprises for testing purposes. Modules are typically integrated in a top-down
incremental fashion.

5) System Testing:- The bringing together of all the programs that a system comprises for
testing purposed.
6) Stub Testing:- A techniques used in testing modules, especially where modules are
written and tested in a top-down, where a few lines of code are used to substitute for
subordinate modules. Stubs are two or three lines of code written by a programmer to
stand in for the missing module.
Acceptance Testing By Users

This is the process whereby actual users test a completed information system in the environment
where it will eventually be used, the end results of which is the user’s acceptance testing is for
users to determine whether the system meets their requirements. The most complete acceptance
testing will include:-
i) Alpha Testing:- Where simulated but typical data are used for system testing
ii) Beta Testing:- In which live data are used in the user’s real working environment.
The types of tests performed during alpha testing include the following:-
• Security testing:- Verifies that protection machines built into the system will
protect it from improper penetration
• Stress Testing:- Tries to break the system eg. what happens when a record is
written to the database with incomplete information.
• Performs testing:- Determines how the system performs on the range of possible
environments in which it may be used. E.g. different h/ware configurations,
networks, operating systems, etc.
In beta testing, a subset of the intended users run the system in their own environment using their
own data. The intent of the beta test if to determine whether the s/ware, documentation, technical
support, and training activities work as intended. In essence, beta testing can be viewed as a
rehearsal of the installation phase.
Installation
This is the process of changing over from the current information system to new one.
Approaches to Installation/Change over Procedures

1) Direct Installation
This is changing over from the old information system to a new one by forming off the old
system when the new one is formed on. This method is handy when.
• The new system bears no resemblance to the old i.e the direct change over is inevitable.
• There s complete confidence in the new system’s reliability and accuracy.
Under direct installation, users are at the mercy of the new system. If the new system tools,
considerable delay may occur until the old system can be reinstated and transactions re-entered
to make the database up-to-date.
Disadvantages:-
• Can be very risky.
• Requires a complete installation of the whole system for a large system, this may mean a
long time until the new system can be installed , thus delaying system benefits

Advantages
• Least expensive and it creates considerable interest in making the installation a success.
2) Parallel Installation
This is where the old and the new systems are running concurrently using the same inputs until
the management decides the old system can be turned off.
Outputs are compared to help determine whether the new system is performing as well as the
old.
Advantage
• Gives the management – time to fully test the new system while still retaining the
existing one. Errors discovered in the new system do not cost organization much.
Disadvantages
• Costly because of the amounts of duplication involved running two systems implies
employing new staff or overtime working for existing staff to operate and maintain both
systems.
• Is only possible where the outputs from the old and new systems are easy to reconcile.
• Can be confusing to users since they must deal with both systems.
• There can be a considerable delay until the new system is considerably ready for
installation.
A parallel approach may not be feasible, especially if the users of the system (such as customers)
cannot tolerate redundant effort or the size of the system is large.
3) Single location Installation/Pilot Installation

In this method, rather than converting all of the organization at once, the new system is tried in
only one place or in a series of separate sites over time. The single location may be a branch
office a single factory or one department, and the approach used for installation in that location
may be any of the other approaches.
Advantages
• It limits potential damage and potential cost by limiting the effect to a single site. The
new system is deployed in the rest of the organization only if the management has
determined that installation has been successful at the pilot site
• Problem with the system (the actual s/ware as well as documentation, training and
support) can be resolved before deployment to other sites.
Disadvantages
• It still places a large burden on IS staff to support two versions of the system.
• If different locations require sharing of data, extra programs will need to be written to
synchronize the current and new system.

4) Phased Installation/Staged Installation
This is an incremental approach, where the new system is brought on line in functional
components starting with one or a few functional components and then gradually extending the
installation to cover the whole new system. Different parts of the old and new systems are used
in co-operation until the whole new system is installed.
Advantages
• By converting gradually, the organization risks is spread out over time and place.
• It allows for some benefits from the new system before the whole system is ready
• Each phase of change is smaller and more manageable for all involved.
Disadvantages
• The new and replaced systems must be able to co-exist and probably share data. Thus,
bridge programs connecting old and new databases and programs often must be built.
• It is not feasible if the old and the new systems are incompatible.
• The approach is akin to bringing out a sequence of releases of the system, and a long
period of change which may be frustrating and confusing to users.
Planning Installation
Each installation strategy involves converting not only software but also data and hardware,
documentation, work methods, job descriptions, officer and other facilities, training materials,
business forms and other aspects of the system(of special interest in the installation is the
conversion). The existing master file will need to be converted into the new form or will need to
be converted into a database.
The current data must be made error-free, unloaded from current files, combined with new data,
and loaded into new files, Also to be doe may include:-
• Reformatting data to be consistent with more advanced databases supported by the new
system.
• Entering new data fields in large quantities
• Manual tasks, such as taking a physical inventory to validate the data before being
transferred.
The shutting down of the current system should be done typically at office hours. The installation
schedule should be announced to users well in advance to lot them plan their work schedules.
Successful installation steps should also be announced, and special procedures put in during
installation. You should also plan for emergency staff to be available in case of system failure.
Documenting the System

We can divide documentation into two basic types:-
• System documentation:- Records a detailed information about a system’s design
specifications, its internal workings, and its functionality. It can further be dived
Internal Documentation- Part of the program source code or is generated at compile

time.

External Documentation - - Includes the outcome of structured diagramming
techniques such as data flow and entity relationship diagrams.
• User Documentation:- Consists of written or other visual information about an

application system, how it works and how to use it
Most user documentations are now delivered on-line in hypertext format instead of bulky
paper manuals.
Training
Computing infrastructure is made up of all the resources and practices required to help people
adequately use computer systems to de their primary work. It includes user training and support
may include the following.
o Use of the system
o General computer concept
o Information system concepts eg. batch processing
o Organization concepts eg. FIFO inventory accounting
o System management.
o System installation eg. how to reconcile current and new system during phase
installation.
The common methods for computer training include:-

1) Tutorial – One person taught at a time
2) Course – several people taught at a time
3) Computer Aided Instructions
4) Interactive training manuals – combination of tutorials and computer aided instruction
5) Videos, interactive TV for remote training, multimedia training, online tutorials.
Electronic Performance Support Systems (EPSS) which are online help systems that go beyond
simply providing help but embed training and educational information into software package. An
EPSS can take several forms such as a tutorial, an expert system shell, and hypertext jumps to
reference material. These may be delivered via videotapes, CD-ROMs, company intranets and
the internet.
User Support
This involves providing on-going educational and problem solving assistance to information
system users.
In an attempt to cut the costs of providing support and to catch up with the demand for additional
support service, vendors have automated much of their support offering. The methods of
automation include on-line support forums, bulletin board systems, on demand fax and voice
response systems.

CHAPTER EIGHT
Maintenance
These are changes made to a system to improve of fix its functionality. Maintenance is done to
evolve system functionality in order to overcome internal.
Processing errors or to better support changing business needs. Maintaining a system is a life
process for most systems and so it is very costly. Four major activities occur within maintenance:
1) Obtaining Maintenance Request

A formal process should be developed whereby users can submit system change request.
2) Transforming request into changer conducted to gain an understanding of the cope of the
request. It must be determined how the request will affect the current system and the duration of
such a project. The size of the maintenance request can be analyzed for risk and feasibility.
3) Designing Changes
A change request is transformed into a formal design change, which can then be fed into the
maintenance implementation phase
4) Implementing changes
Types of maintenance
1) Corrective maintenance – Involves changes made to a system to repair flaws in its design
coding, or implementation.
2) Adaptive maintenance – changes made to a system to evolve its functionality to changing
business needs or technologies.
3) Perfective maintenance - changes made to a system to add new features or to improve
performance.
4) Preventive maintenance – changes made to a system to avoid possible future problems.
Factors Affecting The cost of Maintenance
Maintainability is the case with which software can be understood, corrected, adapted and
enhanced.
The following factors can affect maintainability especially the cost element.
1) Number of latent defects (unknown) when it is installed. If there are no errors in the system
after it is installed, then maintenance cost will be relatively low.
2) Number of Customers for a given system that a maintenance group must support. The greater
the number of customers, the grater the maintenance cost. For a system with thousands of users,
change requests may be contradictory or incompatible and error reports may come from many
places, and modification problems, customer support, and system signification problem.
3) Quality of system documentation - Without quality technical system documentation,

maintenance effort can increase exponentially.

4) The quality of the maintenance personnel highly skilled programmers are needed because the
maintenance programmer is typically not the original programmer and must quickly understand
and carefully change the software.
5) Availability of software development tools can lower the cost of maintenance.
6) Software structure - well structured programs make it much easier to understand and fix
program

System Analysis and Design

Uploaded by

Copyright:

Available Formats

System Analysis and Design

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

System Analysis and Design

Uploaded by

Copyright:

Available Formats

KENYA METHODIST UNIVERSITY

DEPARTMENT OF COMPUTER INFORMATION SYSTEMS

DISTANCE LEARNING MODULE

COURSE CODE: CISY 222

COURSE TITLE: SYSTEM ANALYSIS AND DESIGN

Complied by: Mwenda Muriira, Department of CIS 1

Complied by: Mwenda Muriira, Department of CIS 2

Computer Based system

Complied by: Mwenda Muriira, Department of CIS 3

(a) Systems and their Environment

Difference between Open Systems and Closed Systems

Open System Closed System

Complied by: Mwenda Muriira, Department of CIS 4

Deterministic Systems (Mechanistic Systems)

Probabilistic Systems (Stochastic Systems)

Cybernetic system (Self Organizing/ Adaptive)

(C) Control of the system

Open – Loop System.

Closed – Loop System

Human Machine Systems

Complied by: Mwenda Muriira, Department of CIS 5

Information Systems (IS)

Types of Information Systems

1. Transaction Processing Systems (TPS)

2. Management Information System (MIS)

3. Decision Support Systems (DSS)

Complied by: Mwenda Muriira, Department of CIS 6

4. Expert Systems (ES)

Complied by: Mwenda Muriira, Department of CIS 7

System Analysis and Design

Complied by: Mwenda Muriira, Department of CIS 8

The System Design Methodologies

i) The System Development Life Cycle (SDLC)

Complied by: Mwenda Muriira, Department of CIS 9

Project Identification and Selection

Project Initiation and Planning

Complied by: Mwenda Muriira, Department of CIS 10

Complied by: Mwenda Muriira, Department of CIS 11

Traditional SDLC Critism

ii) Structured Analysis and Structured Design. (SASD)

iii) Object Oriented Analysis and Design. (00AD)

iv) Jackson System Development (JSD)

Jackson System Development (JSD) is a linear software development methodology developed

Complied by: Mwenda Muriira, Department of CIS 12

Different Approaches to Improving System Development

Complied by: Mwenda Muriira, Department of CIS 13

2. Joint Application Design (JAD)

The People in a System Development process

The Systems Analyst

Complied by: Mwenda Muriira, Department of CIS 14

Complied by: Mwenda Muriira, Department of CIS 15

ii) Project Management

iii) Risk Management

iv) Change Management

i) Interviewing, Listening and Questionnaires

Complied by: Mwenda Muriira, Department of CIS 16

Working Alone and with a Team

Characteristics of a High Performance Team