Often the first step in attempting to design a new piece of software, whether it is an addition to existing software, a new application, a new subsystem or a whole new system, is, what is generally referred to as "Domain Analysis". Assuming that the developers (including the analysts) are not sufficiently knowledgeable in the subject area of the new software, the first task is to investigate the so-called "domain" of the software. The more knowledgeable they are about the domain already, the less work required. Another objective of this work is to make the analysts, who will later try to elicit and gather the requirements from the area experts, speak with them in the domain's own terminology, facilitating a better understanding of what is being said by these experts. If the analyst does not use the proper terminology it is likely that they will not be taken seriously, thus this phase is an important prelude to extracting and gathering the requirements.

The starting point in establishing requirements is a careful analysis of the existing process which is to be automated. By examining the existing process, we can fit the design to the way your business actually operates. Of course, this examination also opens the possibility of modifying the business process to take advantage of the way computers handle information. For example, you would only need to enter data once, even though in a manual process it may need to be copied several times. The key here is to remain flexible, and look for opportunities to streamline certain tasks, without forcing you into any specific procedures.

In this phase, both consultant and client discuss the system to be developed. We determine the minimal set of features to be supported (the "needs"), as well as the ideal system desired (the "wants"). The reason it's important to establish these priorities is that many projects are constrained by time; the client has specific needs that must be met within a specific time frame. This is often one motivation for breaking a large project into multiple development cycles. High priority, mission-critical features can be implemented in earlier phases, while desired but less essential features can be added in a later phase. Consequently, once the requirements have been established and prioritized, an initial timetable is determined.

One of the most powerful tools used in establishing requirements, particularly user interface requirements, is prototyping. What that means is that the consultant will create a dummy application that looks like the final product, but without any of the business logic built in. This prototype is easy to build, and can usually be done in a few days, even for larger systems. Its purpose is to allow the user to see what the final product will actually look like, and get a sense of how much data will fit on one window, how that data is organized, what steps are required to perform specific tasks, and so on. What that means is that usability issues are addressed early in the development process, while they're still easy to correct.

One of the most important steps, even though it's frequently ignored. It actually consists of two steps.

The first is to establish a high-level design that specifies what the different parts of the system will be, and how they interrelate. During this phase, decisions are made regarding what hardware and operating systems are required, as well as what software tools will be used. User interface standards are established based on the prototype discussed above, so that every window has a consistent 'look-and-feel' in its presentation, and is consequently easier to use.

The second part is a detailed specification of each business module, window, and function within the system. A detailed database design, or schema, is also established at this point. As with prototyping, performing a detailed design allows changes to be made early, while it's still relatively easy. Done properly, this serves as the foundation for the technical documentation of the system. It also serves as a blueprint to guide the development phase. At this point, a firm timetable can usually be established.

Note the distinctions between requirements gathering, analysis and design. A requirement gathering refers to the task of identifying the business problem or need at hand. Analysis refers to the task of understanding the business problem at hand. Design, on the other hand, refers to the process of planning the solution to that problem.

This is the part of the process where software engineers actually program the code for the project. This phase usually comprises the majority of the project life cycle. Taking the design established in the previous phase, the application itself is then built. Often the system is built in multiple phases so that critical functionality can be deployed as early as possible.

Testing software is an integral and important part of the software development process. This part of the process ensures that bugs are recognized as early as possible. Even though it's listed as a separate phase, the bulk of the testing actually occurs during the development & implementation phase. This first part is commonly known as “unit testing”. Its goal is to make sure that the individual components of the system work well, both separately and in conjunction with other parts of the system. If done poorly, the user will later experience problems such as system crashes, or poor performance. Done well, the user may not even be aware of this form of testing at all.

The other type of testing is known as “system testing”. Its goal is to make sure that the original requirements have been met, that the business rules embodied in the system are correct, and to verify that the system works as a coherent whole. This stage of testing is done in close coordination with the eventual users of the system. This is another reason why it's important to have the participation of the end users in gathering requirements. Often, a new application will replace an existing one; in such a case, testing often includes running both systems in parallel for a defined period of time.

This is probably the most frequently forgotten step. Documenting the internal design of software for the purpose of future maintenance and enhancement is done throughout development. This may also include the authoring of an API, be it external or internal. Documentation serves two purposes.

While one of the goals of effective user interface design is to minimize the need for user documentation by making the system easy and intuitive to use, proper documentation is nonetheless important in training both current and new staff in the use of the system. User documentation is the guide to using the system, as well as making the most of its features. User documentation may come in different forms, from printed manuals to online help files.

Technical documentation, on the other hand, is used as a guide for future developers to make changes to a system months or even years later. Even the developer who designed and wrote most of a system would be hard-pressed to remember every detail of its implementation after a period of time.

This is where it all comes together. Hardware is installed, and the network configuration is established. Depending on the design of the system, database, application, and web servers are installed on dedicated server machines. Existing data, if any, is converted to the new system. The finished application is then installed, and final testing is done to make sure that all of the pieces of the system are working correctly in concert with one another.

A large percentage of software projects fail because the developers fail to realize that it doesn't matter how much time and planning a development team puts into creating software if nobody in an organization ends up using it. People are often resistant to change and avoid venturing into an unfamiliar area, so as a part of the deployment phase, it is very important to have training classes for new clients of your software.