CHAPTER THREE

ANALYSIS PHASE
1.1. Introduction

The analysis phase answers the question of who will use the system, what the system
will do, and where and when it will be used. During this phase, the project teams first
create an analysis plan that describes how they will learn about the system. The team then
produces the summary, use case, process model and data model that describes the AS-IS
System. Next, the project team lists improvement opportunities and creates the system
concept, use cases, process model and data model for the To Be system. All of the
deliverables from analysis phase are combined in to a system proposal, which is
presented to the project sponsor and other key decision makers (e.g. members of the
steering committee).
Analyzing Business Systems introduces you to a method of studying the way an
organization functions, in order to improve work processes and increase efficiency and
effectiveness in all areas of an organization’s operations, including records and
Information management.

1.2. The Analysis Process

Analyzing information system is both a business task and an information technology task.
In the early days of computers, there was a presumption that the system analysts as
experts with computer systems were in the best position to define how a computer system
should operate. Gradually the presumption changed so that the users as business experts
were seen as being in the best position to define how a computer system should operate.
However, many systems fail to deliver performance benefit because users simply
automated an existing inefficient system and failed to incorporate the new opportunities
offered by computer technology. The SDLC is the process by which the organization
moves from the as-is system to the to-be system. The initiation phase developed some
general idea for the to-be system and defines the projects scope. The product of the
analysis phase is a system concept for the to-be system. This concept then refined in the
design phase in to a detailed design and then built and delivered in the implementation
phase. The analysis phase is divided in to three phases as:

 Understanding the as-is system- in most cases, the system under development
will replace an existing system. Thus the first step is to study this system and
understand its strength and weaknesses. This usually requires the project team to
apply the information gathering techniques that are presented in this chapter.

 Identifying improvement opportunities- once the project team understands the

current system, it then identifies ways to improve the system. Again, various
information gathering techniques are used; to understand what improvements
should be used. Identifying improvement opportunities requires technology skills
and significant business expertise in the functional area being examined.

 Developing concepts for the to-be system- once information about the systems
gathered, and improvements are identified, the analysts and users then develop the
components for the to-be system. Analysis ends with the system proposal for the
new system that presents an overview of one alternative (some times more
alternatives). The proposal presents a vision for the new system and outline its
basic design
 Fig. 3.1 Analysis processes

1.3. Information Gathering Techniques

1.3.1. Interview

An informational interview is a conversation with an expert or person knowledgeable in a

career field in which you want to learn more about. Different from a job interview, this
interview puts you in charge. It is very important, however, before targeting someone for
an interview to identify your career interests and to have an idea of what you want to do
for work. Once you have identified your career-related skills and developed your
interests, you need to become more familiar with the available jobs that closely match
your abilities. Here is when the informational interview comes in handy.
 1.3.2. Joint Application Design

JAD uses structured group discussion among customers, users and developers, followed
by consensus decision Making, to develop software requirements- By getting both sides
together for an extended session, JAD tries to Shorten the gathering sub phase and ensure
that the requirements are correct, unambiguous, and consistent.
Strengths, weaknesses, and limitations
The cost and time associated with data collection, analysis, and requirements definition
can be significantly reduced by using the JAD technique. The input from numerous
people provides different perspectives on the desired system and often generates creative
ideas. Because all interested parties are represented on the JAD team, conflicts and
discrepancies can be identified and resolved during the problem definition stage. Because
they are involved in system planning, the participants feel a sense of system ownership.
JAD is particularly suited to projects that face tight time and scheduling constraints and it
is an excellent choice for developing a system from scratch. Sometimes, so many ideas
are generated that additional sessions and meetings are needed to resolve the conflicts.
Strong or influential users can easily dominate a session, leading to a skewed sense of the
users’ needs. JAD is not a good technique for systems with relatively few inputs and
outputs or for highly computational, process-oriented systems.
Inputs and related ideas
JAD is used to determine the system requirements during the problem definition (or
information gathering) phase of the system development life cycle. Often, a preliminary
problem definition proceeds the JAD session. JAD can also be used to perform feasibility
analysis, cost/benefit analysis and risk analysis. Often, such design specifications as data
flow diagrams, entity relationship diagrams are generated during the JAD session.

Concepts
Joint application designs (JAD), also known as joint application development, is a
technique for quickly determining system requirements by obtaining input from a
representative cross section of interested parties. An ad hoc team composed of major
users, managers, and systems analysts (or information consultants) is assembled. The
team then meets in an intensive session to gather data, brainstorm, discuss ideas,
reconcile differences, identify and prioritize requirements, and generate desirable
alternative solutions.

Organize JAD Team

Develope JAD Workbook

Locate JAD Facilities

Conduct JAD Session

Finalize JAD Report

Fig. 3.2 JAD processes

Organize the JAD team

The members of a JAD team consist of end users from the relevant business functional
areas, managers from those same functional areas, systems analysts or information
consultants, and appropriate systems specialists. The moderator or session leader is
usually the senior systems analyst or information consultant. A scribe takes notes, records
all discussions, and organizes and compiles the necessary documents.

Develop the JAD workbook

The JAD workbook consists of a management definition guide, information relevant to
the project, any special criteria or constraints, any assumptions, an overview of existing
technology and standards, a statement of the system’s scope and objectives and
information about the existing system and/or relevant new technology. The purpose of
the workbook is to help the team members understand the proposed project. The design
of the workbook should facilitate note taking.

Locate the JAD facilities

As a minimum, a conference room large enough to accommodate all the team members
and equipped with whiteboards or chalkboards, an overhead projector, and a slide
projector must be available. With the emergence of the electronic meeting systems
(EMS), group decision support systems (GDSS), and computer aided software
engineering (CASE) tools, additional requirements might include computers for
conducting an electronic meeting, teleconferencing facilities, and a master station
equipped with CASE software.

Conduct the JAD session

A JAD session is an intensive (typically) two- or three-day meeting of the complete JAD
team. Team members are expected to give the JAD session their complete attention,
scheduling no other conflicting activities.

Preparation
Before the JAD session begins, the responsible systems analysts or information
consultants must:
 Define the system scope.
  Identify the problems, limitations, and constraints.
 Estimate the resource needs (time, budget, and personnel) for developing the
system.
 Identify preliminary costs, benefits, risks, and impacts of the project.
 Identify the nature and major attributes of the project, the project dependencies,
and the project interrelationships.
 Identify appropriate sub-projects. (The project is sometimes, decomposed into
several sub-projects owing to the timing and/or budgetary constraints.)
 Perform the background analysis necessary to define such key parameters as the
number of users, the size of the database, the required throughput, and the
minimum acceptable response times.
 Plan the JAD session.

The session
A JAD session begins with an overview of the material collected during the preparation
stage. Once the participants understand the problem, the process of identifying the
problem’s dimensions, possible causes, requirements, and alternative solutions begins.
During a JAD session, it is the moderator‘s responsibility to effectively manage session
time, to ensure that the team stays focused on the agenda items, to encourage all team
members to participate, and to resolve any conflicts generated during the session.
Because the team is composed largely of non-technical personnel, it is important that the
systems analysts or information consultants minimize the use of technical terms.

Brainstorming
The process of soliciting ideas often involves brainstorming. A specific question is
raised; for example, the moderator might ask the JAD team to suggest possible causes of
a specific problem or sub-problem. The participants are then invited to suggest ideas, and
as suggestions are made they are posted for all to see. Ideally, at some point in the
brainstorming session, a synergy begins to emerge, with one participant’s contribution
eliciting new and creative suggestions from other participants. The time allocated to a
brainstorming session is limited to (perhaps) half an hour, and the time limit is announced
to all participants before the session begins. The focus is on soliciting and listing ideas,
not on attacking, defending, or investigating those ideas. Often, targets are set; for
example, a brainstorming group might be challenged to list 25 possible (direct or
contributing) causes of the problem under study. Sometimes, the JAD team is divided
into several brainstorming sub-teams, and a friendly competition is launched to see which
sub-team can list the most ideas.
Investigation, consolidation, resolution, and tabulation
Following a brainstorming session, the JAD team divides into sub-groups to investigate
the ideas on the various lists. Vague or unclear ideas are refined and rephrased. Similar or
redundant ideas are categorized and consolidated, and the resulting meta-ideas are
reconciled.
Meanwhile, other sub-groups might conduct additional brainstorming and/or discussion
sessions to consider other sub-problems or identify and resolve conflicts within and
between the meta-ideas until, eventually, a consensus is reached. The consensus ideas are
then tabulated and distributed to the JAD team members for feedback. The session ends
with a presentation of the final results.
Finalize the JAD report
After the JAD session is concluded the responsible systems analysts or information
consultants update the necessary documents and prepare a final report that summarizes all
discussions, facts, findings, and conclusions. They then construct a plan for action and a
schedule for developing the system. If follow-up sessions are required, they collect the
required additional information. Tere is no standard format for a JAD report, although the
feasibility study report outline suggested is a good model.

1.3.3. Questionnaire

A questionnaire is a research instrument consisting of a series of questions and other

prompts for the purpose of gathering information from respondents. Although they are
often designed for statistical analysis of the responses, this is not always the case.
Questionnaires have advantages over some other types of surveys in that they are cheap,
do not require as much effort from the questioner as verbal or telephone surveys, and
often have standardized answers that make it simple to compile data. However, such
standardized answers may frustrate users. Questionnaires are also sharply limited by the
fact that respondents must be able to read the questions and respond to them. Thus, for
some demographic groups conducting a survey by questionnaire may not be practical. As
a type of survey, questionnaires also have many of the same problems relating to question
types.

Usually, a questionnaire consists of a number of questions that the respondent has to

answer in a set format. A distinction is made between open-ended and closed-ended
questions. An open-ended question asks the respondent to formulate his own answer,
whereas a closed-ended question has the respondent pick an answer from a given number
of options. The response options for a closed-ended question should be exhaustive and
mutually exclusive. Four types of response scales for closed-ended questions are
distinguished:

 Dichotomous, where the respondent has two options

 Nominal-polychromous, where the respondent has more than two unordered
options
 Ordinal-polychromous, where the respondent has more than two ordered options
 (Bounded)Continuous, where the respondent is presented with a continuous scale

A respondent's answer to an open-ended question is coded into a response scale

afterwards. An example of an open-ended question is a question where the test has to
complete a sentence (sentence completion item). Construction and wording that exist in
other types of opinion poll.
 Many research projects and senior essay what you will conduct in your graduation year
demand the collection of primary data from individuals. Questionnaires are often the best
way of gathering such information and views. However, a badly designed questionnaire
may get only unusable responses or none at all.

What do you want to know?

Before you even write the first question, it is important that you have a very clear idea
about what you want your questionnaire to achieve. Write down your goals, and think
about what information you need to elicit from respondents to meet those goals. Think
also about how you are going to analyze each question to get the results you need.
Remember there is a difference between things you need to know, and those it would be
nice to know. Eliminate unnecessary lines of questioning at the planning stage. Dear
learners you can refer many books about the types of questionnaires, participants, and
techniques of designing questionnaire questions and refresh the knowledge you captured
from research methods particularly from data collection tools.

Who should you ask?

It may not be possible to survey every person who could provide a useful response to
your questionnaire. In such cases, you will need to choose a sample from your population
to survey. When choosing your sample make sure it is representative of the population
you are studying. For example, does it cover all ages, socio-economic groups, genders,
e.t.c?

There are many different types of question you can use to get the information you need.
In the main, these fall into open and closed questions. An open question allows the
respondent to use their own words to answer, e.g., “what do you think are the main
causes of racism?” A closed question gives them pre-defined options, e.g., “which of the
Following do you think are the main causes of racism: a, b, c, d.
 1.3.4. Observation

What people say they believe and say that they do are often contradicted by their
behavior. A large body of scientific literature documenting this disparity exists, and we
can all likely summon examples from our own lives. Given the frequency of this very
human inconsistency, observation can be a powerful check against what people report
about themselves during interviews and focus groups.
 1.4. Process Modeling

1.4.1. Data Flow Diagrams

Data flow diagrams can be used to provide a clear representation of any business
function. The technique starts with an overall picture of the business and continues by
analyzing each of the functional areas of interest. This analysis can be carried out to
precisely the level of detail required. The technique exploits a method called top-down
expansion to conduct the analysis in a targeted way.

Fig. 3.3 JAD processes

The result is a series of diagrams that represent the business activities in a way that is clear and
easy to communicate. A business model comprises one or more data flow diagrams (also known
as business process diagrams). Initially a context diagram is drawn, which is a simple
representation of the entire system under investigation
Identifying the existing business processes, using a technique like data flow diagrams, is an
essential precursor to business process re-engineering, migration to new technology, or
refinement of an existing business process. However, the level of detail required will depend on
the type of change being considered.
There are only five symbols that are used in the drawing of business process diagrams (data flow
diagrams). These are now explained, together with the rules that apply to them

Fig. 3.4 DFD processes

This diagram represents a banking process, which maintains customer accounts. In this
example, customers can withdraw or deposit cash, request information about their
account or update their account details. The five different symbols used in this example
represent the full set of symbols required to draw any business process diagram
External Entity

Fig. 3.5 External Entity

An external entity is a source or destination of a data flow which is outside the area of
study. Only those entities which originate or receive data are represented on a business
process diagram. The symbol used is an oval containing a meaningful and unique
identifier
 Process

Fig. 3.6 DFD Processes

A process shows a transformation or manipulation of data flows within the system. The
symbol used is a rectangular box which contains 3 descriptive elements:
Firstly an identification number appears in the upper left hand corner. This is allocated
arbitrarily at the top level and serves as a unique reference. Secondly, a location appears
to the right of the identifier and describes where in the system the process takes place.
This may, for example, be a department or a piece of hardware. Finally, a descriptive title
is placed in the centre of the box. This should be a simple imperative sentence with a
specific verb, for example 'maintain customer records' or 'find driver'.
Data Flow

Fig. 3.7 Data flow

A data flow shows the flow of information from its source to its destination. A data flow
is represented by a line, with arrowheads showing the direction of flow. Information
always flows to or from a process and may be written, verbal or electronic. Each data
flow may be referenced by the processes or data stores at its head and tail, or by a
description of its contents
 Data Store

Fig. 3.8 Data Store

A data store is a holding place for information within the system:

It is represented by an open ended narrow rectangle. Data stores may be long-term files
such as sales ledgers, or may be short-term accumulations: for example batches of
documents that are waiting to be processed. Each data store should be given a reference
followed by an arbitrary number

Resource Flow

Fig. 3.9 Resource Flow

A resource flow shows the flow of any physical material from its source to its destination.
For this reason they are sometimes referred to as physical flows.
The physical material in question should be given a meaningful name. Resource flows are
usually restricted to early, high-level diagrams and are used when a description of the
physical flow of materials is considered to be important to help the analysis

1.5. Data Modelling

A data model describes the data that support the business process in the organization.
During the analysis phase, the data model presents the logical; organization of data
without indicating how the data are stored, created or manipulated so that analysis can
focus on the business without being destructed by technical detail. Later, during the
design phase, the data model is changed to reflect exactly how the data will be stored in
data base and files. This topic therefore describes entity relationship diagramming, one of
the most common data modelling techniques used in industry.

1.5.1. Entity Relationship Diagram

Entity relationship diagramming is a technique that is widely used in the world of

business and information technology to show how information is, or should be,
stored and used within a business system.
The success of any organization relies on the efficient flow and processing of
information. In the following example information flows around the various departments
within the organization are shown. This information can take many forms, for example it
could be written, oral or electronic. Here is an example of the sort of information flows th
at you might be analyzing:

The general manager regularly communicates with staff in the sales and marketing and
accounts departments by using e-mail. Orders received by sales and marketing are
forwarded to the production and accounts departments, for fulfilment and invoicing. The
accounts department forward regular written reports to the general
manager; they also raise invoices and send these to the customers.

Data modelling is a technique aimed at optimizing the way that information is stored and used
within an organization. It begins with the identification of the main data groups, for example the
invoice, and continues by defining the detailed content of each of these
groups. This results in structured definitions for all of the information that is stored and used wit
hin a given system.

The technique provides a solid foundation for systems design and a universal standard for system
documentation. Data modelling is an essential precursor to analysis & design, maintenance &
documentation and improving the performance of an existing system.