Managing the Systems Development Life Cycle:Project Initiation and Systems Analysis.

Project Initiation

Project initiation involves obtaining a detailed understanding of the user problem and proposing multiple alternative solutions. Each of these proposals is assessed in terms of its feasibility and cost-benefit characteristics. The option selected at this step then proceeds to the construct phase of the SDLC. Depending upon the nature of the project and the needs of the organization, a system will require in-house development, a commercial package, or both. These approaches are examined in Chapter 14.

Systems Analysis

The systems analyst must fully understand a business problem before he or she can formulate a solution. An incomplete or defective analysis will lead to an incomplete or defective solution. Therefore, systems analysis is the foundation for the rest of the SDLC. Systems analysis is actually a two-step process involving an initial survey of the current system and then an analysis of the user’s needs.

THE SURVEY STEP

Most systems are not developed from scratch. Usually, some form of information system and related procedures are currently in place. The analyst often begins the analysis by determining what elements, if any, of the current system should be preserved as part of the new system. This involves a rather detailed system survey. Facts pertaining to preliminary questions about the system are gathered and analyzed. As the analyst obtains a greater depth of understanding of the problem, he or she develops more specific questions for which more facts must be gathered. This process may go on through several iterations. When all the relevant facts have been gathered and analyzed, the analyst arrives at an assessment of the current system. Surveying the current system has both disadvantages and advantages.

Disadvantages of Surveying the Current System

Perhaps the most compelling argument against a current system survey centers on a phenomenon known as the current physical tar pit.2 This is the tendency on the part of the analyst to be sucked in and then bogged down by the task of surveying the current dinosaur system.

Some argue that current system surveys stifle new ideas. By studying and modeling the old system, the analyst may develop a constrained notion about how the new system should function. The result is an improved old system rather than a radically new approach. An example is the implementation of an ERP system. The task of reviewing current organizational procedures may serve no purpose because the successful implementation of an ERP depends on reengineering these processes to employ the best business practices of the industry.

Advantages of Surveying the Current System

There are three advantages to studying the current system. First, it is a way to identify what aspects of the old system should be kept. Some elements of the system may be functionally sound and can provide the foundation for the new system. By fully understanding the current system, the analyst can identify those aspects worth preserving or modifying for use in the new system.

Second, when the new system is implemented, the users must go through a conversion process whereby they formally break away from the old system and move to the new one. The analyst must determine what tasks, procedures, and data will be phased out with the old system and which will continue. To specify these conversion procedures, the analyst must know not only what is to be done by the new system but also what was done by the old one. This requires a thorough understanding of the current system.

Finally, by surveying the current system, the analyst may determine conclusively the cause of the reported problem symptoms. Perhaps the root problem is not the information system at all; it may be a management or employee problem that can be resolved without redesigning the information system. We may not be able to identify the root cause of the problem if we discard the existing system without any investigation into the symptoms.

Gathering Facts

The survey of the current system is essentially a fact-gathering activity. The facts the analyst gathers are pieces of data that describe key features, situations, and relationships of the system. System facts fall into the following broad classes:

DATA SOURCES. These include external entities, such as customers or vendors, as well as internal sources from other departments.

USERS. These include both managers and operations users.

DATA STORES. Data stores are the files, databases, accounts, and source documents used in the system.

PROCESSES. Processing tasks are manual or computer operations that represent a decision or an action that information triggers.

DATA FLOWS. The movement of documents and reports between data sources, data stores, processing tasks, and users represent data flows.

CONTROLS. These include both accounting and operational controls and may be manual procedures or computer controls.

TRANSACTION VOLUMES. The analyst must obtain a measure of the transaction volumes for a specified period of time. Many systems are replaced because they have reached their capacity. Under- standing the characteristics of a system’s transaction volume and its rate of growth are important elements in assessing capacity requirements for the new system.

ERROR RATES. Transaction errors are closely related to transaction volume. As a system reaches capacity, error rates increase to an intolerable level. Although no system is perfect, the analyst must deter- mine the acceptable error tolerances for the new system.

RESOURCE COSTS. The resources the current system uses include the costs of labor, computer time, materials (for example, invoices), and direct overhead. Any resource costs that disappear when the current system is eliminated are called escapable costs. Later, when we perform a cost-benefit analysis, escapable costs will be treated as benefits of the new system.

BOTTLENECKS AND REDUNDANT OPERATIONS. The analyst should note points where data flows come together to form a bottleneck. At peak-load periods, these can result in delays and promote processing errors. Likewise, delays may be caused by redundant operations, such as unnecessary approvals or sign-offs. By identifying these problem areas during the survey phase, the analyst can avoid making the same mistakes in the design of the new system.

Fact-Gathering Techniques

Systems analysts use several techniques to gather the previously cited facts. These include observation, task participation, personal interviews, and reviewing key documents.

OBSERVATION. Observation involves passively watching the physical procedures of the system. This allows the analyst to determine what gets done, who performs the task, when they do it, how they do it, why they do it, and how long it takes.

TASK PARTICIPATION. Participation is an extension of observation, whereby the analyst takes an active role in performing the user’s work. This allows the analyst to experience firsthand the problems involved in the operation of the current system. For example, the analyst may work on the sales desk taking orders from customers and preparing sales orders. The analyst can determine that documents are improperly designed, that insufficient time exists to perform the required procedures, or that peak-load problems cause bottlenecks and processing errors. With hands-on experience, the analyst can often envision better ways to perform the task.

PERSONAL INTERVIEWS. Interviewing is a method of extracting facts about the current system and user perceptions about the requirements for the new system. The instruments used to gather these facts may be open-ended questions or formal questionnaires.

Open-ended questions allow users to elaborate on the problem as they see it and offer suggestions and recommendations. Answers to these questions tend to be difficult to analyze, but they give the analyst a feel for the scope of the problem. The analyst in this type of interview must be a good listener and able to focus on the important facts. Examples of open-ended questions are: ‘‘What do you think is the main problem with our sales order system?’’ and ‘‘How could the system be improved?’’

Questionnaires are used to ask more specific, detailed questions and to restrict the user’s responses. This is a good technique for gathering objective facts about the nature of specific procedures, volumes of transactions processed, sources of data, users of reports, and control issues.

REVIEWING KEY DOCUMENTS. The organization’s documents are another source of facts about the system being surveyed. Examples of these include:

• Organizational charts

• Job descriptions

• Accounting records

• Charts of accounts

• Policy statements

• Descriptions of procedures

• Financial statements

• Performance reports

• System flowcharts

• Source documents

• Transaction listings

• Budgets

• Forecasts

• Mission statements

Following the fact-gathering phase, the analyst formally documents his or her impressions and understanding about the system. This will take the form of notes, system flowcharts, and various levels of data flow diagrams.

THE ANALYSIS STEP

Systems analysis is an intellectual process that is commingled with fact gathering. The analyst is simultaneously analyzing as he or she gathers facts. The mere recognition of a problem presumes some under- standing of the norm or desired state. It is therefore difficult to identify where the survey ends and the analysis begins.

System Analysis Report

The event that marks the conclusion of the systems analysis phase is the preparation of a formal systems analysis report. This report presents management or the steering committee with the survey findings, the problems identified with the current system, the user’s needs, and the requirements of the new system. Figure 13-5 contains a possible format for this report.

The primary purpose for conducting systems analysis is to identify user needs and specify requirements for the new system. The report should set out in detail what the system must do rather than how to do it.

The requirements statement within the report establishes an understanding between systems professionals, management, users, and other stakeholders. This document constitutes a formal contract that specifies the objectives and goals of the system. The systems analysis report should establish in clear terms the data sources, users, data files, general processes, data flows, controls, and transaction volume capacity.

The systems analysis report does not specify the detailed design of the proposed system. For example, it does not specify processing methods, storage media, record structures, and other details needed to design the physical system. Rather, the report remains at the objectives level to avoid placing artificial constraints on the conceptual design phase. Several possible designs may serve the user’s needs, and the development process must be free to explore all of these.