Instead of wikipedia and the original article from Boehm, I propose you a quote from an article about a NASA case study in using the spiral model of software development:
The spiral model of software development offers a flexible, risk-driven approach to developing software that can often match the reality of a project better than document-driven models such as the classic waterfall. Rather than prescribing a specific set of activities and development stages through which to progress, the spiral empowers a development team to select the most appropriate path given the current goals, constraints, and risks. Thus, a lifecycle based on the spiral will naturally support incremental development as well as other paradigms.
First of all, the spiral shows an iterative process, in which each cycle produces a new "prototype" that refines the knowledge about the requirements and the product design. This iterative process is not necessarily incremental. Originally, Boehm advocated the principle of "build twice" introduced by Royce in his paper about improving the waterfall model. In practice, a "prototype" could however lead to an increment rather than a throw-away prototype, especially in later iterations.
Risk-driven means that the goal is to reduce the biggest uncertainty early. The spiral has not a clear end, so the iterations continue until the product is mature and robust.
Each iteration goes through four stages:
- Determine objectives: what is to be done in the current iteration and in which timeframe. This is not so much different from a waterfall in which you would start with a SOW and a plan.
- Identify and resolve risks: here it is very different from waterfall because not necessarily about requirements, but about uncertainty. So you may of course start with some initial requirements, but in a subsequent iteration, it could be about the architecture's capability to support high volumes, or the way to check the completeness of the functionality to meet the expectations, or any other risk that is identified. Depending on the objectives, you'll conduct some studies, analyses or designs to address the risks.
- Development and test: obvious
- Plan the next iteration: first the results of the current iteration need to be evaluated: one should assess if it meets the objectives, and understand what needs to be done next.
The spiral model thus allows for progressive elaboration: you do not need to know in detail the product at the start, but you may progressively discover the needed details. It is not document oriented, and so very different from traditional "write requirement", "specify design", "implement design". And it allows for flexibility about what is to be developed and how.
The degree of flexibility explains why the spiral is called by Boehm a "process generator": the spiral is used to tailor the process to the needs of the project.