ELEMENTS OF THE SYSTEMS ANALYSIS PHASE OF THE SDLC (STUDY OBJECTIVE 4)

Exhibit 6-4 illustrates typical steps within the systems analysis phase of the SDLC: a preliminary investigation, a survey of the current system, a determination of user information needs, analysis, and business process reengineering. At the end of this phase, the project team will prepare and deliver a systems analysis report.

PRELIMINARY INVESTIGATION

The preliminary investigation occurs within a short period ranging from a few hours to a few days and should not exceed two to three days. The purpose of the preliminary investigation is to determine whether the problem or deficiency in the current system really exists. The project team may reexamine some of the feasibility aspects of the project. At this point, the purpose is to make a “go” or “no-go” decision. The end result is a decision to proceed further or to abandon the project.

Exhibit 6-4 Systems Analysis Process Map

SYSTEM SURVEY: THE STUDY OF THE CURRENT SYSTEM

In most cases, it is easier to improve something only when you have a good understanding of it. For example, it would be difficult for you to improve on the fuel efficiency of a car if you did not know details about how gas is used in the car, what quantities of gas the car uses, and which characteristics of the car affect fuel efficiency. Likewise, we cannot improve the efficiency and effectiveness of the IT system in use without first knowing such details about the system as transaction volumes, processes within the system, and controls within the system. All of these factors and others affect the throughput of an accounting system. Throughput is a measure of transactions per period. The systems survey is a detailed study of the current system to identify weaknesses to improve upon and strengths to be maintained. A systems survey requires collecting data about the current system, including the following:

• Inputs—sources of data
• Outputs—the uses of information from processing and outputs such as checks, reports, or forms
• Processes—the individual steps undertaken to process transactions, including both manual and computerized processes
• Controls—the internal controls within the processing system
• Data storage—how and where the data are stored, and the size of the data storage
• Transaction volumes—number of transactions per day or per hour
• Errors—number of transaction processing errors

The exact data collected in a systems survey may vary from project to project or company to company, and the foregoing list shows the usual data collected. As noted in this list, different kinds of data must be collected from several different sources. Some data collection may involve asking employees or managers questions, while other data collection may require examining documents such as operating manuals or flowcharts. The data collection in a systems survey requires several different methods of collecting data from different sources. Data collection involves observation, documentation review, interviews, and questionnaires. A project team would use each of these methods to collect the necessary data. The first two methods are described in this section, and the final two are described in the section that follows.

Observation is watching the steps that employees take as they process transactions in the system. The purpose of the observation is to enable the project team to gain an understanding of the processing steps within the system. Documentation review is the detailed examination of documentation that exists about the system to gain an understanding of the system under study. The project team would examine any relevant documentation about the system, such as flowcharts, run manuals, operating manuals, input forms, reports, and outputs.

DETERMINATION OF USER REQUIREMENTS

While observation and documentation review are important methods of data collection, neither method actually seeks the views or thoughts of users of the system. By these methods, the project team members capture only those strengths and weaknesses within the system that they notice. To gain a complete understanding of the system under study, the project team should not only observe and review documentation, but also seek the opinions and thoughts of those who use the system.

Interviews and questionnaires are data collection methods that solicit feedback from users of the system. These are critical parts of the data collection, because it is of utmost importance that users have input into the development of a new or revised system. Since users are the people who input data or use output reports on a daily basis, the system must satisfy the needs of these users. The user perspective and perception about the current system are an important part of the information that the project team needs to collect in order to benefit from a system survey. Interviews are a data collection method that help the project team in determining user needs.

Interviews are the face-to-face, verbal questioning of users to determine facts or beliefs about the system. The questions asked can be structured, unstructured, or some mixture of the two. A structured question is designed such that the format and range of the answer is known ahead of time. An unstructured question is completely open-ended, and the respondent is free to answer in any way that he feels addresses the question. The difference between structured and unstructured questions is similar to the difference between multiple choice and essay questions. The multiple choice question has predetermined answers in a certain format, whereas the format and content of an essay answer are much more flexible for the person answering the question. Both types of questions can be used in interviews to solicit feedback from users about how they use the system and about strengths and weaknesses in the current system. The face-to-face nature of interviews provides advantages. The interviewer can clarify any misunderstandings about the question and can follow up with more questions, depending on the response of the interviewee. Both the interviewer and interviewee are more certain that they understand each other when communication is verbal and face to face.

Questionnaires are also used to solicit feedback from users. However, questionnaires are a written, rather than an oral, form of questioning users to determine facts or beliefs about the system. Questionnaires can also include both structured and unstructured questions. There are advantages to the use of questionnaires. Questionnaires can be answered anonymously, which allows the respondent to be more truthful without fear of negative consequences. Similar to the anonymous instructor-evaluation forms used in college classes—wherein the student can be completely frank in his or her evaluation of a professor, since responses are anonymous—a respondent to a systems questionnaire can answer the questionnaire fully and truthfully. The other advantage to questionnaires is efficiency; that is, it is much easier and less time-consuming to process 100 questionnaires than it is to personally interview 100 users.

ANALYSIS OF THE SYSTEM SURVEY

The analysis phase is the critical-thinking stage of the systems analysis. The purpose is to question the current approaches used in the system and to think about better ways to carry out the steps and processes in the system. The project team studies the information collected in the system survey phase and attempts to create improvements to the system.

In many cases, the analysis phase and the attempt to create improvements may lead to business process reengineering (BPR). BPR has been defined as “fundamental rethinking and radical redesign of business processes to bring about dramatic improvements” in performance.⁷ Business processes are the many sets of activities within the organization performed to accomplish the functions necessary to continue the daily operations. For example, every organization has a process to collect and record the revenue earned. In a smaller company, the revenue collection process may simply be a single person who mails out bills, receives customer checks in the mail, totals the checks, records them in the accounting records, and deposits the funds. Through rethinking and redesigning this process, the company may be able to improve the process and thereby speed up the collection of revenue. This rethinking and redesign is especially aided by the use of IT. When technology or computers are introduced, the processes can be radically redesigned to take advantage of the speed and efficiency of computers to improve processing efficiency. IT and BPR have a mutually enhancing relationship. IT capabilities should support the business processes, and any business process should be designed to match the capabilities that the IT system can provide. BPR should leverage the capabilities of IT to improve the efficiency of processes. As discussed earlier, Anheuser Busch uses extensive IT systems to improve the forecasting of customer buying patterns. This IT system and the processes that match it enable Anheuser Busch to keep customer store shelves stocked with the right amount of its various beer brands.

BPR will probably begin at this stage of the SDLC, but it may continue through several phases of the SDLC. As the project proceeds through the phases of the SDLC and the team begins to design and implement improvements to the system, more BPR may be necessary to match the processes to the system.

SYSTEMS ANALYSIS REPORT

The last step in the systems analysis phase is to prepare a systems analysis report for delivery to the IT governance committee, which will inform the IT governance committee of the results of the systems survey, user needs determination, and BPR. The report will make recommendations to the IT governance committee regarding the continuation of the project.