One of the primary objectives of the systems analyst is to assess the job under investigation by obtaining answer to the following questions: What is being done? Why is it being done? Who is doing it? How is it being done? What are the major problems involved in doing it?
This paper will discuss concerning with traditional collecting and analyzing data which will enable the analyst to find satisfactory answer to those questions. Even though, there are several modern information gathering techniques for analysis such as JAD, CASE tools, and prototyping, to successfully analyze the current system, systems analyst still have to use traditional methods to collect documentation and interact with people involved with the system. During data collection and analysis the analyst is dependent upon the effective use of system tools such as interviews, questionnaires, standard flowcharts, HIPO diagrams, data flow diagrams, N-S charts, as well as decision tables which will be discussed in this paper.
Data collection takes place constantly throughout the systems development process. The selection committee gathers facts on which to base its decision regarding whether or not to pursue suggestions further. The feasibility team gathers data in determining a workable solution to a business problem. The system analyst needs data to design the system outlined in the feasibility study. Data associated with system studies usually are obtained in answer to these questions: What is the problem? What is the company currently doing about it? What tools are available to help solve the problem? What other areas in the company are affected by the problem? What opinions is available concerning a solution to the problem?
A purpose of the interview is to find out what is in the person's mind that may not have been written down. The higher the person is in the organization, the more important this activity becomes because we get more into philosophy and policy.
The interviews are good tools for collecting rich, detailed information and allow exploration and follow-up. On the other hand interviews are time-intensive and expensive. Therefore, the analyst should carefully plan the interview in order to meet the most cost effective outcomes. Moreover, by interacting directly face-to-face, it is possible to have disagreement between the interviewee and the interviewer. The interviewer, then, should handle this situation properly.
The interviewer must never directly contradict or interrupt the respondent, even if he or she strongly disagrees with what is being said. When the respondent has expressed his or her views, the interviewer should try to turn the disagreement into a useful exchange of ideas by one of these methods:
Proper humility:
admit that you are not an expert in the user organization and its work. Importantly, admit that you are not as expert in the respondent's job as the respondent himself, and that you are not trying to tell the respondent how to do his or her job.
Postponement:
say that you will take the matter up later in the interview, or at a subsequent interview, and drop the matter completely for the present. If such a course is adopted, then, on resumption, the respondent must be allowed to have his or her fully say.
Appreciation of the other's opinion:
if you cannot drop the matter for some reasons, then this rule should be followed: "Each person can speak up for himself only after he has first restated the ideas and feelings of the previous speaker accurately and to that speaker's satisfaction."
Stimulation of questions:
try to stimulate the respondent into asking questions, and ask questions in turn. When two persons disagree with one another, they have already broken off communication; if the interviewer can initiate the asking of questions, this will tend to restored communications.
Definition of the cause:
if the disagreement can be defined, it will be half solved. Is the disagreement a difference over:
- Fact? Then the obvious solution is to offer to refer to some authority - either a book or a person;
- Opinion? Be sure that each participant clearly understands the other's opinion. If there is still no agreement, then both opinions should be included in the report, with reason to support each.
Termination:
if there is a clash of personalities, the interview should be quickly and courteously terminated. If there is an important reason for continuing the interview, it must be rescheduled for another time.
There are a number of alternative methods available for systems analyst. Those include observation, work measurement, sampling, and questionnaires.
The most reliable data a systems analyst may obtain are gathered through observation. They are free of most of the biases that may color data acquired through other sources. Information received through interviews requires verification. People may not lie deliberately, but very often they misrepresent facts. Information received through observation may be accomplished in several ways. A systems analyst should gather a sampling of completed forms from the existing system. Blank forms may deceive a systems analyst because they indicate only the way the forms designer anticipated the data would be received. A cross section of completed forms more completely indicates how the forms are actually being used.
It is often helpful for a systems analyst to spend some time in the user area, either watching the operation of the current system or actually participating in it. This serves two purposes (1) the system analyst gets to know the users and perhaps will be better able to satisfy their needs; and (2) the systems analyst obtains a more realistic view of the actual data in the system.
With the systems walk-through technique, the observer assumes the role of each document in the system and follows its course from beginning to end, observing how each document is prepared and distributed through out the organization. This provides an opportunity to meet with the systems users, observe attitudes, evaluate performances, and see how each part of a system relates to other parts. More importantly, the systems analyst can meet the users in their own environment and learn their thoughts and attitudes, their needs, and what will inspire them to cooperate in making the system work.
The systems analyst must know the volume of transactions and the time and cost to complete specific tasks. Many organizations have established administrative work measurement programs to provide corporate management with data to evaluate performance. These programs can be a prime source of data for the systems analyst.
When a work measurement system does not exist, a systems analyst may, with the cooperation of the supervisor in the user area, set one up temporarily. The objective of this program is to determine precisely the volume of data moving through a user area and precisely how long it takes to process these data. The systems analyst also can determine the bottlenecks in the existing systems and should become more aware of the exceptions to normal processing and how they are handled.
Work measurement programs, when not handled properly, produce problems. People are sensitive about having their productivity measured, especially in a white-collar environment, where it is not often done. Such a program should be instituted only when the data anticipated from the program are vital to the systems study.
A critical decision for the systems analyst is how much data is enough. To review every transaction in a given system for a year is obviously too costly and may confuse more than clarify. On the other hand, analyzing three or four transactions from a system that processes thousands in a year may be economical, but will probably lead to disaster. The analyst must evaluate the cost in data collection against the benefits to be derived from the data. The two basic methods of sampling are random and systematic. In a random sample there is no plan for selection and thus no biases, because each item in a group has an equal opportunity to be selected. Statisticians provide the basic technique for collection random samples. An example of systematic sampling is transmittal to a systems analyst of a copy of every hundredth transaction from every tenth desk. Both methods are used widely in system studies, but the systems analyst must determine the size of the sampling in terms of the knowledge expected to be gained from it.
Questionnaires are efficient when the systems analyst seeks a small amount of data from a large group of people. The questionnaire must be worded carefully so the meaning of each question is clear to most of the readers. Questionnaires lack the personal touch so vital for a free exchange of ideas. The person completing the questionnaire cannot have questions clarified not volunteer as much information as in a normal interview. Questionnaires are difficult to compose. The same question may have different meanings to different people. Too often, poorly-worded questions lead the responder into the answer expected rather than an honest response.
An effective questionnaire is brief, clear, and well-tested. These questions must be analyzed carefully since the people filling out the questionnaire will not have the opportunity to ask questions. One advantage of questionnaire in systems analysis is that they enable a large group of people to feel they are participating in the development of the company's future systems.
Data analysis naturally follows data collection in a system development. In most systems studies, more data are gathered than can be handled conveniently. Moreover, the systems analyst usually is under time pressure to complete the data analysis phase of system development and begin designing the new system. This type of pressure must be resisted. Defining problems precisely requires patience. Analyzing what is wrong and determining the best solution is a unique skill which requires coordinated effort. When analysis is done properly, the actual detailed systems design follows easily.
Data analysis begins with a review of the facts gathered concerning a project. It is important not to look for solutions until all the facts have been gathered and the problems accurately defined. Data analysis also consists of asking questions until the problem is understood, then developing alternative solutions until the best one is obvious. Typical analysis questions are: How important is this system? What must it really accomplish? What type of people does it require? How does it relate to other systems in the organization? What are the system's goals?
Systems analysts have a variety of techniques available for data analysis. These techniques, however, are no substitute for an analytical mind that can see through symptoms and address significant problems.
It is difficult for systems analysts people to develop creative solutions to problems, in many environments, because companies place many restrictions on what systems analysts can do. The people with whom systems analysts work often inhibit creative thought, and systems analysts frequently narrow their own thinking with self-imposed constraints. Systems analyst are often on the track of a truly creative solution to a problem only to be set back with a statement like "It has never been tried before," "Management will not like it," or "What we are doing now is good enough." It is difficult of deal with these types of thinking.
Brainstorming is one technique for increasing creativity in problem solving. Brainstorming is a free exchange of ideas among people. In a brainstorming session, people offer solutions to problems as if there were no restrictions. Ideas are presented as they come to mind. This allows a person's imagination to develop ideas often suggest other ideas. One person builds on the other's suggestion and may come upon a solution that otherwise would not have surfaced.
After the session is completed, the proposed solutions must be evaluated realistically. Frequently, a solution that never would have been proposed in routine analytical sessions meets the real world tests and provides a feasible solution to a problem.
One area in which systems people are often restricted in their thinking is in determining a starting point for analyzing a problem. Most systems analysts examine the existing system trying to determine what is wrong and what can be done to improve matters. This immediately imposes constraints, as the systems analyst is strongly influenced by the way things were done previously.
One way to free a systems analyst's thinking is to begin analyzing a problem by totally disregarding what is currently being done, and concentrating on the objectives for the proposed system. The analyst's thoughts are centered on what the organization needs, and what is the best way it can be accomplished. The analyst brainstorms on ways to meet the objectives, temporarily disregarding all the reasons why the ideas will not work. Only when the best alternatives to meet the systems objectives have been formulated will the systems analyst start to consider the limitations of the working environment. With more clear thinking and planning, the best proposed plan will survive the test.
One of the most significant advances in systems analysis during the last decade has been the introduction and growing use of so-called structured top-down approaches to analyzing and designing information systems. Although, these approaches were initially introduced as computer program design and coding aids, they have increasingly been adapted for use in systems analysis and design. These approaches are based on the ideology of:
The top-down, that is, from the general to the specific approaches, has improved the orderliness and quality of systems development. These approaches have also improved the quality of documentation and thus facilitated communications among project team members and communications with others. Finally, as result of a module can be added, deleted, or changed without disturbing the rest of the program, these approached have been an effective means for dividing or modularizing very large systems into smaller, more manageable subsystems without sacrificing future opportunities for integrating subsystem components into a single, comprehensive entity.
However, what structured analysis does best is to allow people to see problems more easily. This not only aids the analytical process, but leads to clearer communication among analyst, users, and management.
Several new charting techniques have been developed specifically to support the goals of the structured approach: the HIPO techniques, data flow diagrams, N-S charts, flowcharts, and decision tables
The hierarchy plus input-process-output (HIPO) technique is a structured tool with broad applicability throughout the systems development life cycle. This technique uses two different types of charts. The first type, called a VTOC diagrams, is used to develop a top-down hierarchical structure through which systems functions and their relationships can be observed, discussed, and better understood. The second type is frequently called an IPO diagram, because it describes the input, output, and process components for a given function.
The VTOC diagram can be of major utility of the analyst. First, it is extremely easy to draw and thus can be used experimentally and accurately. Second, the diagram lends itself to group construction and thus is a valuable aid when several people must participate as a team.
Third, the diagram is also important in structuring and documenting that participation. Even when the "group" is composed of only the analyst and one other person, the analyst may want to use the diagram to structure the interview. Fourth, the diagram is potentially useful for making presentations at various levels of detail, depending on the intended audience because it can clearly illustrate the hierarchical relationships among various functions and subfunctions. Finally, the VTOC diagram can provide a basis for continuous and evolving documentation and contribute greatly to overall project control.
The advantage of IPO is that it permits a more extended description of processes in ordinary English than a VTOC diagram does. Thus, the processing steps may be briefly described in the process box and more fully explained in the extended description notes at the bottom of the HIPO form. The symbols that describe inputs and outputs resemble standard flowcharting symbols. There are, however, potential disadvantages in this reliance on verbal description and flowchart-like drawings; in particular, the documentation time required to describe all the functions may be very high. This drawback has led some analysts to employ a mix of diagramming techniques together with the VTOC aspect of HIPO. These analysts use IPO diagramming only when its extended-description advantages are judged to be worth the added documentation effort.
The data flow diagram is also an alternative of structured technique. Data flow diagrams are easy to draw and require the knowledge of only a few symbols. However, care must be taken to avoid making them overly detailed. Because data flow diagrams are not linear (straight line), analysts must take care not to describe too much detail on a single diagram, or it may become overly difficult to follow. Beginning with an overview and working to individual, more detailed levels of data flow is strongly recommended.
The N-S charts have been primarily used to design structured programs. However, they should prove helpful to the analyst in clearly describing complex problems in systems logic. Although N-S charts are not extensively used in all aspects of systems analysis today, expanded uses will probably be found for them in the future - particularly when the analyst is looking for a better way of clearly describing to others some of the more complex logical problems involved in analysis and design.
Systems flowcharts provide a concise diagram of a complete system or process. Thus, they can be useful in problem organization, problem solving, problem presentation, and problem review. There are two major kinds of standard flowcharts; the system flowchart and the program flowchart. In most instances the real difference between them is the level of detail being illustrated. However, both kinds of flowcharts are systems tools. It is simply a question of determining which level of detail is required and for which audience. To construct a lengthily and detailed program flowchart for presentation to corporate top management would probably obscure rather than clarify the problem for them. On the other hand, a general systems flowchart, by itself, does not contain the level of detail required for computer programming.
Decision tables represent human or machine decision alternatives in tabular form. They are most effective when the problem is a complex decision with many different conditions and possible results. In a sense, decision tables are most effective when the problem is one of selecting a single decision alternative or set of alternatives out of many possibilities.
As a systems analysis tool, decision tables work best in those instances which are both specific and detailed. Similarity, the systems analyst can provide decision tables to computer programmers as a basis from which coded routines can be developed. Such an approach eliminates much of the guess work from programming and can particularly assist the less accomplished programmer to do better programming work. Moreover, decision tables are also a beneficial to systems documentation. By including decision tables in the formal documentation, the analyst can quickly review some of the complex decision making processes without wading through computer program listings or lengthy, written statements and procedures.
