You are here

Definition and Goals

19 January, 2016 - 12:35

Review Question

What are the differences among the systems survey, systems analysis, and the structured systems analysis steps in systems development?


Before we begin this section, let’s define and clarify a few terms. First, systems analysisis the methodical investigation of a problem and the identification and ranking of alternative solutions to the problem. Systems analysis is often called structured systemsanalysis 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.

The systems survey assists management in determining the existence of a problem and in choosing a course of action (i.e., to continue systems development or to cancel it). 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. Compare the architect’s role for the industrial park to the analyst’s role for systems development. In the preliminary stages of the industrial park project, the architect learns the general purpose of the industrial park (light manufacturing, warehousing, etc.). The architect also learns the approximate number of buildings and the size of each. From that information, the architect “sketches” a proposed park. From that sketch, the accompanying general specifications, and the estimated costs and estimated schedule, the developer decides whether or not to proceed with the proposed project at this time. This process is similar to that followed in the systems survey, with the systems analyst assuming the architect’s role and the organization’s management (or the IT steering committee) replacing the developer.

If the developer approves the continuation of the project, the architect must conduct a detailed study to determine each building’s specific use, required room sizes, electrical and plumbing requirements, floor load weights, private versus public areas, number of personnel who will occupy the completed buildings, technical requirements, and so on. During this detailed study, the architect develops a functional model of the proposed project. The detailed study by the architect is similar to systems analysis, and the logical specification (one of the outputs of the analysis step) is the model for the new system.

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.

Review Question

What are the goals of structured systems analysis?


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 (i.e., reengineering) 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.

Figure 6.3 Occurrence of Errors during the SDLC 

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 (e.g., customer, business partners).

Figure 6.4 Cost to Fix an Error or Make a Change during the SDLC