Now let's take a look at the map we've built. In Figure 2-1, you can see that we have made a subtle yet important transition in our thinking in this process. We have moved from the problem domain, represented by the cloud and the
Figure 2-1. Overview of the problem domain and the solution domain
Chapter 3. Requirements and the Software Lifecycle
Traditional Software Process Models
Effective requirements management can occur only within the context of a reasonably
Your team's software development process defines who (which member of the team) is doing what (which activity is being performed), when (the timing in relation to other activities), and how (the details and steps in the activity) in order for your team to reach its goal. Software processes have been shown to have a significant effect on your team's ability to develop software on time and on budget. In this chapter, we look at a few different software processes and attempt to understand the time-dependent phases and major types of activities in those phases. We then go on to describe a specific, recommended model: the iterative model. Within the context of the iterative model we can begin to understand the key role that requirements play throughout the software lifecycle. Most of the techniques described in this book apply to a variety of software processes, but it is through using an iterative approach that you are likely to achieve the maximum benefits.
The Waterfall Model
Boehm  points out that as early as the 1950s the software industry, recognizing the cost of discovering software defects late in the cycle, adopted a logical, stepwise process model that progressed from a requirement phase to a design phase to a coding phase and so on. This was a major improvement over the earlier, two-phase "code and fix" model, whereby programmers first wrote the code and then fixed it until it couldn't be fixed any more.
In the 1970s, Royce , working at TRW, defined what became known as the "waterfall model" of software development. The waterfall model improved on the
In the waterfall model (Figure 3-1), software activities proceed logically through a sequence of steps. Each step bases its work on the activities of the previous step. Design logically follows requirements, coding
Figure 3-1. Waterfall model of software development
Note that, as commonly applied, Figure 3-1 does not reference the prototyping activity that Royce prescribed. This is an unfortunate mistake in history that we'll return to shortly.
The waterfall model has been somewhat successful in
In this case, over time, the team may become completely disengaged from the real world on which the project was originally based. Disaster invariably results.
As we'll see later, the waterfall model comes under additional pressure when it is aligned to the scope management challenge. Specifically, if the waterfall model is applied to a project that is initiated with too large a scope, the results can be woefully short of the initial expectations. At deadline time, nothing really works, unit test and system integration are forced or
Primarily for these reasons, the waterfall model has
The Spiral Model
Boehm's pivotal study  recommended a different framework for guiding the software development process. His "spiral model" of software development serves as a role model for those who believe that success follows a more
Figure 3-2. The spiral model of development
In the spiral model, development is initially driven by a series of risk-driven
When you look at the spiral model more