Note 1: This post is extracted from Chapter 9 of my book, CHANGE: Planned and Unplanned.
Note 2: This book was written for project leaders in high-tech industries, but writers are also project leaders, and writing certainly requires great skill and precision. For writers, requirements may originate from publishers, agents, and for-hire customers—any of whom can cause unending grief by changing those requirements for a writer who has assumed they were fixed.
Until recently, the computing industry seems to have avoided the subject of requirements the way a debutante might avoid the subject of indigestion. We knew such things existed, but if we didn't think about them, perhaps they would simply take care of themselves.
Many of the classic early papers in software engineering were based on the position:
This is how we would design and build software (if we had unchanging requirements.)
[For writers: each of us has her/his own process for writing, but for many of us, that process is also based on having unchanging requirements. If someone changes our task, we may be thrown off our game, and into write-stopping turmoil.]
For instance, many of the early papers on structured programming were based on the Eight Queens Problem, a problem of fixed definition with no input whatsoever. Many papers on recursive programming were based on the Towers of Hanoi problem, another problem of fixed definition with no input whatsoever. The more recent Cleanroom methodology has the same basis: "The starting point for Cleanroom development is a document that states the user requirements." The following quotation from Parnas and Clemens shows how deeply this assumption runs, even in the most sophisticated process designers.
Usually, a requirements document is produced before coding starts and is never used again. However, that has not been the case for [the software requirements for the A-7E Aircraft]. The currently operational version of the software, which satisfies the requirements document, is still undergoing revision. The organization that has to test the software uses our document extensively to choose the tests that they do. When new changes are needed, the requirements document is used in describing what must be changed and what cannot be changed. Here we see that a document produced at the start of the ideal process is still in use many years after the software went into service. The clear message is that if documentation is produced with care, it will be useful for a long time. Conversely, if it is going to be extensively used, it is worth doing right.
Parnas and Clemens describe the benefits of returning after design to create a requirements document as if it had been present from the beginning.
In the light of all this literature, it's easy to understand why so many software engineering managers have made the mistake of believing they should have unchanging requirements before starting any project. This model or belief is what I call the Assumption of Fixed Requirements, an assumption that is a misreading of these classical works. These classics were not addressing the entire process of software engineering, but only selected parts of that process. What they are teaching us is how to translate requirements into code, once we have reliable requirements.
Translating requirements into code is an essential part of software engineering, and it is the part that has received the most research attention over the past decades. Because of that attention, however, it is no longer the most difficult part of the process. Many organizations know how to do this part quite well, but the quality of their products does not adequately reflect their coding prowess.
In recent internal studies of serious quality problems, three different clients of mine arrived at quite similar conclusions. They divided the sources of the most serious problems into a number of categories, including coding and gathering requirements. In all cases, coding contributed least of all categories to quality problems, and my clients would perhaps do better to work on the less glamorous job of improving their logistics processes. Perhaps these rather advanced organizations are not typical of all software engineering organizations. They still have a lot to learn about coding and especially design, but in each case, the majority of their serious problems stem from requirements.
Software engineers and their customers perceive quality differently, and this table accounts in large part for that discrepancy in perception. Over the past decades, engineers have seen coding faults drop dramatically as a result of their quality improvement efforts. The customers, however, have not seen a comparable decrease in the number of requirements problems, and so do not perceive the same increase in quality as the engineers, who are paying attention to their own priorities—which don't happen to coincide with their customers' priorities. The engineers need to learn that they will never become an Anticipating organization by getting better and better at coding—even though that was the improvement process that brought them as far as they've come.
