Methodology for System Analysis

This phase stars 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 the system requirements. The best way to understand 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:

Methodology for system analysis

  • Data gathering and
  • Data analysis.

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

Methodology for system analysis

Methodology for system analysis

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 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 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, judgement is required, or the analyst will spend hours reading outdated report 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 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. Analyst will find that some respondents yield more information in an interview than they would if they had to commit themselves in writing.

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 include only question that have been planned and written out in advance. the interview sticks to the those question and asks no other.  A structured interview is useful when it is desirable or required by law to ask 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 few of the users.

However owing ot the 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 questionnaires that is quick and simple.

Analysts also prefer simple questionnaires because their results are easier to tabulate. The analyst should probably save 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 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 activates of the group. This practice is not especially popular but can be useful in studying a complicated organization.

Sampling

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 clear 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. 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 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 analyst and the users during the analysis phase.

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.

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

System analysis

A data flow diagram shows how data moves through the existing system.

There are 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 data-a 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 the 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.

Decision Table

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

Decision tables are useful in cases that involve a series of interrelated decisions; and helps 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 examples):

1

2

3

4

Purchaser is a member

T

T

F

F

Purchase exceeds Tk. 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 Tk. 1000. The decision table illustrating he discount policy is shown in figure.

1

2

3

4

Conditions purchaser is a member Purchases exceeds Tk. 1000
Actions

15% discount

 

 

 

10% discount

 

 

 

5% discount

 

 

 

No discount

 

 

 

Figure: Example of a purchase decision table

You may like also:

Leave a Reply

Your email address will not be published. Required fields are marked *