Information systems analysis and design will occur in stages. Even the smallest projects adhere to some sort of recognizable, albeit informal, structure that is broken into phases, each one progressing naturally from the previous. A simple example of this concept is, computer code wouldn’t be written for a new system until a clear understanding of the original business problem and the expectations of the new system had been developed, to name only two initial concerns.

Several structured methodologies exist for the development of information systems. In general, such an effort will adhere to the phases described in the table below. Smaller projects may combine or accelerate some of these phases. Nevertheless, experience and best practices suggest that some sense of this structure should be followed, even if a phase can be completed informally in a short period of time:

Development Stage and IssuesOutcome
Preliminary Investigation This phase will result in a clear decision on whether the project should be pursued. Key stakeholders will have an idea of scope, timeframe, and costs. It can be expected that a more complex project will likely have only a “guestimate” for the budget and timeframe, amounts that can be refined only as additional information in the subsequent phases is discovered. Yet a firmer budget and timeframe should be expected for smaller, less complex projects.
Is the project worth doing? What is the scope? How much will it cost? How long will it take?
Problem Analysis Involving the careful study of the business problem domain, this phase results in a thorough understanding of the business problem, objective, or opportunity behind the project. This phase should be conducted without a bias for technology or methodology.
What is the problem facing the business? What is causing this problem? What is the effect of this problem?
Requirements Analysis Sometimes combined with the Problem Analysis phase, this phase should produce a complete understanding of the activities and services the information system must provide. As with problem analysis, this phase should be conducted without bias for a particular type or brand of technology or development methodology.
What must the system do?
Decision/Feasibility Analysis Suitable competing technological and methodological approaches will be analyzed in light of these questions. Key stakeholders will commit to a particular type or brand of technology as well as (if applicable) a development methodology. For larger projects, the project budget and scope may be updated in light of this new information and the project may need to be resubmitted to executive sponsors for final approval.
What kinds of solutions are available to achieve our objectives? What are the pros and cons of each candidate solution? What are the technical strengths and limitations of the solution? How well does the specific solution address the original problem? Will users accept this solution? How much does it cost?
Design This marks the point at which the technical or physical design is addressed. Logical models such as the data model, the context data flow diagram, the decomposition diagram, and the system data flow diagram produced during the problem / requirements analysis phases, answered the question “What?”, and now the design phase will address the question “How?” In other words, the physical designs of the database, the processes, and the interfaces are produced.
Specifically how will the system accomplish the stated objectives?
Construction As suggested by the name, this phase results in the building and testing of networks, databases, individual programs, and system interfaces. Key stakeholders from the user community can provide excellent feedback during the construction phase. If a commercial “off-the-shelf” product is chosen during the decision analysis phase, then this construction phase will be abbreviated or eliminated altogether.
Implementation All parts of the new system are tested together to ensure that the overall product operates accurately and efficiently, as well as meets expectations. Some type of testing is expected to occur even if the product is purchased as a complete system from a technology vendor. Moreover, “out-of-the-box” solutions almost always require configuration and integration with existing business systems. Regardless of whether the system was custom-built or purchased from a vendor, the new system will need to be placed into operation, an effort that can be gradual or abrupt. Additionally, users of the new system will need to be trained, whether this training be a brief, informal set of instructions for simpler systems, or a more involved classroom-style training initiative for more complex systems.
Operation and Support This phase is ongoing once the system is implemented. The Operation and Support phase of an information system can itself spawn other information systems analysis and design projects when, for example, new opportunities for system enhancement are discovered.
How is the system maintained? How is the system recovered during failure? How is technical support handled? How are enhancements to the system made?

The table above indicates the phases of developing an information system. The issues associated with each development phase will be confronted on some level regardless of the project size.