I managed to get sight of a proposal from a competitor last week for a piece of development work that we eventually won and was suprised that they were advocating a waterfall style approach with a pretty comprehensive up-front requirements gathering and specification writing stage. Now whatever you may feel about the pros and cons of Agile, surely nobody really still believes that months of requirements gathering and specification writing is the most cost-effective way to build a web site?
The process of gathering requirements and system design is always thought of as a pretty linear process. The theory goes that as you gather more and more requirements you are better equipped to organise them and create the perfect system. Basically the relationship between understanding and time is one-to-one. A bit like the graph below.
Linear requirements process
If this was the case then it would make sense to spend the necessary time gaining a complete understanding of the system. Not only is each quanta of time (let’s say a day) worth the same, if you spend enough of them you will eventually get to a state of perfect understanding which will allow you to go off and employ a team of developers to build the perfect system without any further thought.
Now everybody knows that this doesn’t actually work in practice and however much effort you spend designing a system there will always be things that for whatever reason don’t quite work in the real world. Not everyone is quite so keen to admit that the theory is flawed so normally the blame is put on the implementation of the process:
“We really must make sure our design is more comprehensive next time.”
In reality the process of gathering requirements and system design is not linear. There’s normally a pretty steep curve at the beginning of the process as you get an idea of the core requirements and this tends to level off the more time that is spent. Arguably you never really get complete understanding and you can certainly never design the perfect system.
I think the curve looks a bit like this one:
Actual requirements process
So, there comes a point where it’s not really worth gathering any more requirements or spending any more effort designing the system as each day that is spent brings less and less extra knowledge.
Common sense tells you that you should stop trying to increase understanding at a point when the curve starts to level off and start building something.
When to start building
The trick is knowing how long it’s going to take to reach that point, recognising that you’ve got there and knowing what to do next…
These are great points, but I would argue that your position is a little too conservative. You can probably start building as soon as the slope of the curve starts to decline, rather than waiting for it flatten out. By then, you will have all of the key requirements outlined and the minor details that trickle in later can still be incorporated early in the dev cylcle.
Spot on! I’ve never seen it better expressed @:-)