9 Methodology for System Analysis (Step by Step Procedure)

This article is about the methodology for system analysis. This phase starts when the management has decided to continue. It is to be noted that the purpose of system analysis is to understand the existing system.

A related goal is to establish system requirements. The best way to understand the methodology for system analysis is to gather data about it; data must then be organized and analyzed.

During the analysis phase the analyst will be concerned with:

Table of Contents

Methodology for system analysis

There are mainly 2 methodology for system analysis and these are:

Data gathering and
Data analysis.

It is to be noted that the system being analyzed may or may not already be a computerized system.

Data Gathering

Three is no standard procedure for gathering data because each system is unique. Data gathering is expensive and requires a lot of work and time. But there are certain sources that are commonly used:

Documentation
Interviews
Questionnaires
Observations
Sampling

Something analysis requires all these sources, but in most cases, it will be appropriate to use some and not others. All references to data-gathering techniques assume that the analyst has the proper authority and the cooperation of the client organization before proceeding.

Documentation

the documentation includes procedures, manuals, reports, forms, and any other kind of material on the problem that the analyst finds in the organization. The analyst may find very few documents and no trials to follow. Sometimes the opposite is true: the analyst finds so many documents that it is difficult to access them.

Thus, judgment is required, or the analyst will spend hours reading outdated reports or manuals that no one follows. However, it is better to take time to get a copy of each form used by the organization.

Interviews

This method of data gathering has advantages and disadvantages. A key advantage is that interviews are flexible; as the interviewer can change the direction of the question for a productive area of investigation.

Another bonus is that the analyst can probe with open-ended questions that people would balk at answering on paper. The analyst will find that some respondents yield more information in an interview than they would if they had to commit themselves to write.

The analyst can also observe the respondent’s voice inflection and body motions, which many tell him more than words alone. Finally, of course. There is the bonus of getting to know clients better and establishing a rapport with them an important factor in promoting user involvement in the system from the beginning. Interviews have certain drawbacks.

They are unquestionably time-consuming and therefore expensive. There are two types of interviews:

Structured and
Unstructured

A structured interview includes the only question that has been planned and written out in advance. the interview sticks to those questions and asks no other. A structured interview is useful when it is desirable or required by law to ask an identical question.

However, the unstructured interview is often more productive an unstructured interview includes prepared questions but the interviewer is willing to vary from the line of questioning and pursue other subjects if they seem appropriate.

Questionnaires

Questionnaires can be used to get information from large groups questionnaires allow people to respond anonymously the respondents just complete forms and presumably, they respond more truthfully questionnaires may be used to verify information gathered from interviewing a few of the users.

However, owing to a large number of respondents sometimes a trend or problem pattern emerges that would not be evident from a small number of interviews.

Questionnaires do have disadvantages however some people will not return questionnaires because they are wary of putting anything on paper even anonymously.

The ballot box type (yes or no ) and the qualified response type (agreement or disagreement with the question on a scale from say 1 to 5 are two common examples of questionnaires in general people prefer a questionnaire that is quick and simple.

Analysts also prefer simple questionnaires because their results are easier to tabulate. The analyst should probably save the open-ended question for an interview.

Observation

As an analyst and observer, one can go into the organization and find who interrelates with whom. In particular, the analyst may observe how data flows. From desk to desk fax to fax or computer to computer and note how data come into and leave the organization.

Initially, an analyst can make arrangements with a group supervisor and make everyone aware of the purpose of the visit. It is essential to visit on more than one occasion so that the people under observation become used to his presence.

One form of observation is participant observation; in this form, the analyst temporarily joins the activities of the group. This practice is not especially popular but can be useful in studying a complicated organization.

Sampling

The analyst may need to collect data about quantities, costs, time periods, and other factors relevant to the system.

For example, the number of phone orders that can be taken by an order entry clears in an hour.

This type of question may be best answered through a procedure called sampling. Instead of observing all the clears filling orders for an hour, the analyst can pick a sample of 3 or 4 clerks.

Or, in a case involving a high volume of paper output, such as customer bills, the analyst could collect a random sample of a few dozen bills.

Data Analysis

There are a variety of tools charts and diagrams for analyzing data, but not all of them are appropriate for every system. The analyst should become familiar with the techniques, then use the tools that suit at the time. In general, there are two typical tools:

Data flow diagrams (DFD)
Decision table.

The reasons for data analysis are related to the basic functions of the system analysis phase: to show how the current system works and to determine the system requirements. In addition, data analysis materials will serve as the basis for documentation of the system.

Data Flow Diagram

A data flow diagram is a sort of road map that graphically shows the flow of data through a system. It is a valuable tool for depicting present procedures and data flow. Although data flow diagrams can be used in the design process, they are practically useful for facilitating communication between the analyst and the users during the analysis phase.

The analyst would probably make notes about what goes on where. But that is only the data-gathering function, now the analyst must somehow analyze the findings.

An analyst could come back on another day with pages of narrative for eh manager to review or, instead, show easy-to-follow pictures. Most users would prefer the picture.

There are a variety of notations for data flow diagrams. The notations used here have been chosen because they are easy to draw and read. The elements of a data flow diagram are processes, files, sources and sinks, and vectors.

Processes, represented by circles, are the actions taken on the data – comparing, checking, stamping, authorizing, filling, and so forth. A file is a repository of a data disk file, a set of papers in a file cabinet, or even mail an in-basket or blank envelopes in a supply bin. In a DED, a file is represented by an open-ended box.

A source is a data origin outside the system under study. An example is a payment sent to a department store by a customer; the customer is a source of data. A source is represented by a square.

A sink is a destination for data going outside the system; an example is a bank that receives money deposits from the accounts receivable organization. A sink is also represented by a square.

Vectors are simply arrows, lines with directional notations showing the flow of data. A vector must come from or go to a process circle, or bubble.

System analysis — Methodology for System Analysis

Decision Table

A decision table, also called a decision logic table, is a standard table of the logical decisions that are made regarding potential conditions in a given system.

Decision tables are useful in cases that involve a series of interrelated decisions and help to ensure that no alternatives are overlooked. Programmers can code portions of a program right from a decision table.

Heading	Rules
1	2	3	4	5
Condition stub (if….)
: :
ActionStub (then…)

Figure: The format of a decision table.

A condition can be true (T) or false (F). Thus for two conditions, there are four possible combinations (as an example):

	1	2	3	4
Purchaser is a member	T	T	F	F
Purchase exceeds $ 1000	T	F	T	F

The actions for this example could be:

–         15% discount
–         10% discount
–         5% discount
–         No discount.

As an explanation, in this case, rule 2 says that the purchaser is a member and the purchase does not exceed $ 1000. The decision table illustrating the discount policy is shown in the figure.