Recently I have talked to a number of clients that have referred to the fact that traditional requirements don’t work. It didn’t take long to ferret out that they were referring to creating software requirements using a waterfall model. I want to state for the record that I completely agree that the waterfall model doesn’t work. However I disagree with the statement that traditional requirements don’t work.
If you look at pretty much any software engineering book, you will find descriptions of multiple software development models including iterative, spiral, evolutionary, modified waterfall and waterfall. There are many others but they are often just modifications of the iterative model. All of these models are old enough to be “traditional” models. Interestingly, all of the models essentially break down to iterative vs. waterfall and all of the methods (except maybe extreme programming) involve “traditional requirements.”
The variations of iterative models for the most part just change the duration of the iterations. For example, Extreme Programming has iterations of a few weeks and Agile has iterations of a few months. The key point is that iterative models are just as “traditional” as the waterfall model and have been around for at least a few decades.
So what model do we advocate? Like most everyone these days we prefer an iterative approach with full development phases taking from 3-6 months (we work on software projects of 20+ software developers). Within these 3-6 month phases we use a modified waterfall approach. Design starts as soon as enough requirements are completed and development starts as soon as enough design is completed. We typically sign off on a requirements document that still has outstanding issues, but that has the biggest risk areas resolved. We will continue to change the requirements as necessary, but via change requests to ensure that all the stakeholders are aware of the changes.
So to those who ask the question “do traditional requirements work?” I would answer resoundingly yes.