Requirements Engineers will be familiar with the general argument for RE, and for Systems Engineering in general.

It runs (as you know) that over half of all current projects fail to deliver on time, to the right quality, to budget. Project managers, when asked, report that over half the reasons for this concern requirements. Therefore, the argument runs, project managers must ensure that much more money, time and effort are spent on requirements. This will save them time, money, and embarrassment later.

Put another way, to err is human. Everybody injects mistakes into their work. Programmers do it; designers do it; analysts do it; even users trying to state requirements do it. So, there is a fixed number of bugs – let’s call it B – in a given size of system. Project managers can choose to do the bug fixing late, say at testing time, or early, say at specification time. Why should anybody care which it is? Is it actually better to be an eager ant, working through the summer, rather than a lazy grasshopper, singing while the sun shines? Why bother to do a whole lot of tiresome requirements elicitation and analysis, in fact?

Cover of ‘The Ant and the Grasshopper’
(a fable of Aesop, 6^th Century BC),
retold by Amy Lowry Poole, Holiday House, 2000

Well, the marching army is large, late on in the project, so more warm bodies are drawing salaries, chewing pencils, writing on flipcharts and generally trampling the fields of Flanders into mud than early in the project. So, the cost of each bug’s worth of delay is high. And, each bug is embedded in a bit of system which is connected to some other bits of system, which are documented in a lot of bits of specification and test plan, and … you get the picture. So there is a whole heap of rework for the grasshoppers to do. What’s more, every day of delay causes a bit more damage to market share, customer impatience and the bottom line. The overall cost of each bug – let’s call it C – is thus high in more ways than one.

So, the total price of the grasshopper approach is the painful B x C, where B is constant and C is very large.

On the other hand, the ants who eagerly discover and fix all the bugs (if you take my meaning) as early as possible do so while the project is small, there’s almost nothing to rework, and the world’s press is not camped on their doorstep.

Therefore the total price of the "left-shifting" ant approach is the painless B x c, where c is very small.

The ant approach is therefore much cheaper, faster, and better than the grasshopper approach, QED (the chief ant takes an elegant bow at this point), and how many licences for my patent Requirements Management tool did you say you wanted?

Whoa there! What about the other side of the argument? How does it look from the project manager’s point of view?

Rather different. Here is a marching army of ants, carrying all sorts of picks, shovels, and heavy earth-moving equipment that we didn’t know we needed. The chief ants recommend immediate expenditure of 15% of the total project budget, several months of hard work, and at the end of that they won’t have written a line of code!

What’s more, they want to spend that money NOW. I’m probably going to get promoted/ moved sideways into Corporate Configuration Management/ pregnant/ emigrate to Australia/ etc. The project is very likely going to get reshaped/ cancelled/ reorganized/ etc when the company gets taken over/ merged/ outsources its software development division/ etc. So who knows if anyone will ever get around to finding the bugs these JCB-wielding ants say must be in there. My money is here now – and the future, well, it may happen or it may not. Anyway, by then we’ll probably have a bit more spare cash to spend on fire-fighting, whoops I mean bug-fixing.

Furthermore, who knows if the ants are right about all those bugs anyway? My team are following Industry Best Practice and we have a fine reputation. So we’re with the grasshoppers. Where’s that violin now?