1.2 Where Do Requirements Fit in the Grand Scheme?

I have no data yet. It is a capital mistake to theorize before one has data. Insensibly, one begins to twist facts to suit theories, instead of theories to suit facts.
-Sherlock Holmes: A Scandal in Bohemia,
Arthur Conan Doyle

Bringing a new system into being involves a number of stages. Exactly how many stages, what each one entails, and who performs them might vary somewhat, according to your organization's culture, who's available, personal taste, and the methodology you're using (and this book leaves that for you to decide). Still, we do need to differentiate the main activities in building a new system. There are endless ways to break them down and represent them. Figure 1-1 shows a simple version that suits our purposes.

image from book
Figure 1-1: Development life cycle phases

This doesn't assume that you perform the whole of one activity before moving on to the next, so it applies regardless of the methodology that you use. Nor does it mean that you must document every activity: you might just picture a requirement in your mind before designing it, or merely think of a design before coding it. Viewed in this way, methodologies differ mainly in the size of each morsel to which this whole process is applied-from the whole system (the traditional approach) at one end of the spectrum to a convenient unit of coding (extreme programming) at the other. In a compromise third approach (which we'll call incremental), we specify a chunk of requirements before moving on to design, then perform a chunk of design before starting development; we do more design and specify more requirements as and when they're needed. Both of the last two fit in with an agile outlook. For the key activities, the differences between the approaches look conceptually something like Figure 1-2.

image from book
Figure 1-2: Morsel sizes for different development approaches

The second half of this chapter discusses each of these three approaches in turn. Every approach also involves a degree of rework-an iterative element-as errors are discovered in the development, the design, and the requirements.