Systems analysis is the methodical investigation of a problem and the identification and ranking of alternative solutions to the problem. Systems analysis is often called structured systems analysis when certain “structured” tools and techniques, such as DFDs, are used in conducting the analysis. To simplify our discussions, we will refer to “structured” systems analysis as simply systems analysis.
As a result of decisions made in the systems survey, we know if and how to proceed with systems development. If we have decided to proceed, we perform the second step in systems development, structured systems analysis. We must perform the procedures in this step well to have any chance of achieving the first of our systems development objectives—to develop systems that meet user needs—because it is during systems analysis that we determine those needs. Without a well-understood and documented target (i.e., user requirements) we cannot hope to have a successful development process.
Management bases the decision about whether and how to proceed on information gathered in the systems survey and on other information. Management might decide to reduce the suggested analysis scope in order to reduce short-term development costs. Or management might cancel, postpone, or modify future systems work because a major modification is preferred to the maintenance approach being suggested. In the case of reengineering and enterprise systems, management faces some challenging decisions.
For example, an organization might decide early in the development process that the installation of an enterprise system would solve its Information Systems problems. To ensure a successful installation of an enterprise system, organizations must reengineer their business processes to make them compatible with the enterprise system. Management must decide how much analysis to undertake before and after purchasing the system and how much to change their business practices
The development options in Figure 6.2 summarize the typical choices from which organizations may choose. In the systems survey we begin the get some sense of these alternatives and which one looks best at the time. In the analysis step of systems development, we must examine each alternative and gather enough information to make a choice to proceed with development along one of the alternative paths. Structured systems analysis is a set of procedures conducted to generate the specifications for a new (or modified) Information System or subsystem.
The systems survey assists management in determining the existence of a problem and in choosing a course of action. Systems analysis provides more information than was gathered in the systems survey. The additional information describes and explains the problem fully. Solutions are developed and evaluated so that management can decide whether to proceed with development and, if so, which potential solution should be developed.
To understand systems analysis, we’ll return to the analogy presented earlier in the chapter, in which we compared systems development to building an industrial park.
Systems analysis goals are as follows:
Define the problem precisely. In systems analysis, we want to know and understand the problem in enough detail to solve it.
Devise alternative designs (solutions). There is always more than one way to solve a problem or to design a system, and we want to develop several solutions from which to choose.
Choose and justify one of these alternative design solutions. One solution must be chosen, and the choice should be justified using cost/effectiveness analysis or some other criterion, such as political or legal considerations (e.g., government reporting requirements).
Develop logical specifications for the selected design. These detailed specifications are used to design the new system.
Develop the physical requirements for the selected design. For example, we want to define such requirements as data storage, functional layouts for computer inquiry screens and reports, and processing response times, which lead to equipment requirements.
Develop the budget for the next two systems development phases (systems design and systems implementation). These budgets are critical in determining development costs and controlling later development activities.
The logical specifications and physical requirements become the criteria by which the user will accept the new or modified system. The better we perform systems analysis, the more likely that the system will meet user requirements and be accepted, implemented, and used effectively. There are two issues here. First, as we see in Figure 6.3, the opportunity for errors is much higher in earlier phases of systems development. A typical early error is failure to define user requirements completely.
Second, as we see in Figure 6.4, the later in the development process that an error or oversight is discovered, the more costly it is to fix. For example, if we fail to determine during analysis that the user needs a certain piece of data on an output screen, this data may not be easy to add to the database during the implementation phase. It is especially imperative to perform a top-quality analysis when we are introducing an enterprise system.
It is during the analysis step that we model the business processes and determine the process changes that will be required. Business process owners and system users must understand and accept these changes for successful implementation. Otherwise there may be strong resistance to the implementation that could lead to the failure of the new system. As mentioned earlier, business processes must be reengineered to fit the enterprise system’s processes.
Determination of user requirements in the analysis step can be more difficult in an e-business implementation. In such an implementation we must determine user requirements inside and outside the organization. We must consider the functional needs of customers and business partners, as well any requirements for infrastructure to connect our internal systems to the outside users