PHASE 2: SYSTEMS ANALYSIS

System Requirements
Steps in the Analysis Phase
Requirements Definition
Requirements Analysis Techniques
Requirements Gathering Techniques

Steps in the Analysis Phase

System analysis is the second phase of the systems development life cycle (SDLC).
In the systems planning phase, we have discussed the process of preliminary
investigation to determine the feasibility of the project through a feasibility report.
If the report was accepted by the steering committee, a project plan was performed, and
on that basis, the systems analysis phase is started.
In the analysis phase, our objective is to:

Determine and document how the current system works

Determine how the system could work better
Develop a logical or business model of the new system
Make recommendations to management

We will go through three major steps to address the above objectives:

Determine Systems Requirements

Analyze Systems Requirements
Evaluate Alternative Solutions

The major output of the systems analysis phase is a Systems Proposal that describes
the findings of the analysis.
In this section, we discuss the process of determining requirements. Requirement
analysis will be discussed in several sections, through the discussion of data-flow
diagrams, data dictionary, entity-relationship diagrams, and process description.
Finally, evaluation of alternative solutions will be discussed in another section.

Requirements Gathering Techniques

The feasibility report in the systems planning phase did not contain details of the
systems requirement. Thus a full-blown study for the requirement of the system is
necessary to understand the detail operations of the business.
To determine system requirements, the analyst sought information of the current system
and the opportunities for improvements in the following areas:

System Objectives:
Identify the objectives of the current system
Evaluate these objectives

System Inputs and Outputs:

(Provide Examples)
Identify the inputs and outputs of the current system
The origin of the inputs and the destinations of the outputs

System Functions:
(Provide Examples)
Define the functions of the current system
Identify the components of the systems: manual procedures, user
interfaces, computer programs, files and databases
Identify timings of input, output and processing
Identify controls on data entry, security, and processing

(Provide Examples)

In order to gather this information, the analyst uses various information-gathering

techniques. Some of the techniques are:

Interviews
Questionnaires
Observation
Work and Product Sampling
Joint Application Design (JAD)
Prototyping

The systems analyst uses more than one technique to collect required information.

Interviews

The interview is the most common method of information-gathering techniques. There

are several basic steps to the interview process:
Preparation for the Interview
Design of Interview Questions
Conduct the Interview
Document the Interview
Perform a Follow-Up Interview.
Preparation for the Interview
To plan for the interview, the systems analyst first reviews the documents available on
the company, existing system, and users. He or she examines
Companys goals and objectives
Forms, reports, and business models of the current system
Organization chart and user roles.
By consulting the organization chart and in discussion with the sponsoring agent of the
organization, the analyst prepares a list of interviewees who will provide various levels
of information for the current system and future needs of the system.
Higher levels of management normally provide an overview of the current system and
its future needs. The lower-level users provide the details operation of the system.
Thus, the top management is interviewed first, then the department heads, followed by
the next level of employees in the hierarchy, up to the lowest levels of the users.
Once a list of prospective interviewees is generated, the analyst schedules interview
with the personnel.
Designing Interview Questions: There are three types of interview questions

Closed-ended questions: Closed-ended questions enable analysts to control the

interview and obtain information they need. Answers to the questions require only a
short answer of one or two words (true/false, multiple choice, rating on a scale, or
ranking).

Open-ended questions: Open-ended questions are those that leave rooms for
further elaboration by the interviewee. These questions provide additional
information or problems that a user normally does not like to talk about.

Probes: These are follow-up questions in response to one of the above questions,
when the analyst is unclear about the answer.

Conduct the Interview

There are certain guidelines for a successful interview. Some of them are:

Listen very carefully to the interviewee and give opportunity to answer.

Take careful notes. Take a second person, if needed to take notes.

If permitted by the organization, record the interview.

Ask questions, even if they sound dumb. Not asking questions may result wrong
conclusion causing further potential problems.

Give the interviewee opportunity to ask questions.

Separate facts from individual user opinions. Facts are important but opinions are
not.

Do not make any premature promise on any part of the delivery of the system.

Thank the interviewee at the end and mention that a follow-up interview may occur
to further clarify questions that may arise.

Document the Interview

After the interview, the analyst should organize and type interview notes within 48 hours
(i.e., before fading away from memory) in the form of a report.
Write down any unclear or additional questions that may arise during this process and
make a list of questions for follow-up interview.
The report is sent to the interviewee with a request to read, make comments, and his or
her approval.
Follow-Up Interview
Follow-up interview arises due to the questions that may arise in writing the interview
report and obtaining a response of the report.
Depending on the number and type of questions, the follow-up interview can be
performed in person or over telephone or any other suitable mechanism (mail, fax, and
e-mail).

Questionnaire

A project that requires input from a large number of people, the questionnaire can be a
valuable tool to determine system requirements.
A questionnaire is a document containing a number of standard questions that can be
sent to many individuals.
Questionnaires can be used to obtain information about workloads, reports received,
volumes of transactions handled, types of job duties, difficulties, and opinions of how
the job could be performed.
Choosing Respondents to Questionnaire
It is important to select the right group of people to send the questionnaire. The group
should be a representative sample of all users of the system.
In general, the following methods can be used to obtain a representative sample:

Random Sample: Select randomly any number of persons to interview, or from a list
of documents select any number of documents to review. For example, out of 100
users, select any 20 persons to interview.

Systematic Sample: Select every nth person to interview or every nth document to
review. For example, out of 100 users, select every 10th person.

Stratified Sample: In this case, select a representative from a category of users.

For example, select users from sales, accounting, inventory departments, and so on.
(Select people form different zip codes.)

Purposeful Sample: Select only those people who satisfy certain criteria. For
example, select users who worked with the system for more than two years.

Convenient Sample: These are the people who are willing to be surveyed, or those
most motivated to respond.

Designing Questionnaire
When designing a questionnaire, the most important rule is to make sure that the
questions collect the right data that can be used to further fact-finding information for the
system.
Some guidelines for designing questionnaire are:

Brief and user-friendly

Clear instructions

Ask questions related to the

requirement

Questions in logical order

Simple wording to avoid

misunderstanding

Avoid leading questions

Open-ending questions are

difficult to tabulate

Limit questions raising

concern/negative issues

Section for general comments

Test the questionnaire in

advance

Advantages and Disadvantages of Interview and Questionnaire

Interview

Interview is a good tool to collect detailed information.

It allows exploration and follow-up questions.

Interviews build rapport between the users and the systems analyst.

Interviews are time-extensive and expensive.

Interviews cannot be performed with many people in a short time.

Questionnaire

Questionnaires are most useful when used for specific purposes rather than for
more general information gathering.

Questionnaires can be given to many people at a time, whereas interviews can be

performed on a single person at a time.

They are most useful for closed-end questions, although some open-ended
questions can be included for information gathering.

Questionnaires are less expensive and less time-consuming.

Questionnaires can be performed on paper, over the telephone and electronically.

Questionnaires are a rigidly structured means to obtain answers to pre-selected

inquiries.

Observation

The observation of current operating procedures of the system is another fact-finding

technique.

A system can be understood better and faster through observation than other
techniques.

It also allows opportunities to verify statements and answers gathered through

interviews and questionnaires.

It also allows opportunities to build relationships with the users.

A successful observation should be planned. In preparing a checklist for

observation, consider the following:
Ask questions to obtain a good understanding of the system operation
procedure.
Observe all steps in the processing cycle and note the output from each
procedural step.
Examine each form, record, and report. Determine the purpose of each item
on the documents.
Consider observing each person working with the system to complete a
process.
Talk to people who receive current reports to see whether the reports are
complete, timely, accurate, and in a useful form.
Consider the Hawthorne Effect: During the observation day, people may work
more efficiently than the normal day. Operations may also run less smoothly
because people might be nervous during observation.

10

Work and Product Sampling

Sampling refers to the collection of examples of actual documents or products of the

system. The samples might include:

Data-entry forms and screens

Program codes (if any)
Transaction records
Work requests
Reports (qualitative and quantitative)
Web site
Operational Procedures and manuals
Error logs
Complaint summaries
Memos

The main objective of any sampling is to ensure that it represents the overall population
accurately. For example, while sampling inventory transactions, select a sample of
transactions that are typical of actual inventory operations.

11

Joint Application Design (JAD)

Developed by IBM, Joint Application Design (JAD) represents an alternative to

interviewing users.
Instead of separate interviews, a work session consisting of a task force of users,
managers, and IT professionals is conducted to gather information, discuss business
needs, and define the new system requirements.
This group usually meets over a period of several hours to few days in a meeting room
outside the work area.
Because of the wide range of user input, JAD produces the best possible requirements
of a new system than a single analyst can provide.
The Organization of the JAD Session
All participants attending a JAD session plays a role according to following:

Session Leader: The session leader organizes and runs the JAD. This person
guides the team to keep on agenda, aids participants in openly expressing ideas,
and resolving conflicts and disagreements between participants.

Active Participants: The users and managers who know the necessary facts and
details regarding both the current system and the objectives of the future system.

Observers: These are IT staff such as analysts, programmers, operators, or any

other technical person who can learn by participation. They may also provide some
technical assistance when needed. Expert in some functional areas of business
(accounting, billing, etc.) may also participate to provide assistance.

Recorders: These are IT personnel who document the discussions and conclusions
of the session. This record is formally published and distributed to the participants
after the session.

12

13

Prototyping

The prototyping is an iterative process involving analysts and users whereby a

rudimentary version of an information system is built and rebuilt according to user
feedback.
Prototyping methodology covers three phases of the SDLC: analysis, design, and
implementation, concurrently and repeatedly in a cycle until the system is completed.
In order to develop a prototype during the requirement analysis, the analyst performs
some interviews and collects necessary documents.
With the basic requirements from the users, a quick analysis and design of the system
is performed, and a prototype of the system containing main features of the
requirements, are developed.
The prototype is then handed to the users for testing and to provide comments; which
are then reanalyzed and redesigned, and a second prototype is developed.
The process continues in a cycle until the users and developers agree to a final systems
requirement.

14

Advantaging and Disadvantaging of Prototyping

Advantages of Prototyping

Prototyping is most useful when user requirements are not clear or well understood.

One or a few users are involved with the system.

Possible designs are complex and require concrete form to evaluate.

Tools (such as form and report generators) and data are readily available to rapidly
build working systems.

Disadvantages of Prototyping

A tendency to avoid creating formal documents of system requirements, which can

then make the system more difficult to develop into a fully working system.

Prototyping can become very idiosyncratic to the initial user and difficult to diffuse or
adapt to other users.

Prototypes are often built as stand-alone systems, thus ignoring issues of sharing
data and interactions with other systems.

Prototyping might miss some very important system requirements such as security,
data entry controls, or standardization of data across systems.

Selecting the Appropriate Techniques

15