A friend of mine has a cartoon strip on his desk where somebody asks "why are the two servers named Benson and Hedges?" The response is "Because that's what it said on the design document..."
The case in the press about the ongoing legal battle between EDS and BSkyB over the failed CRM design is an exceptional reminder of what can go wrong when requirements are, in this instance according to the QC, "wholly unspecified."
Ten years ago I sat in a project meeting where it was decided to scrap two months worth of work because there was a lack of documentation against which it could be tested against. It seems that a decade later we still seem to think that we can wing it with projects and hope that they work without documenting requirements. In some instances without even having a good business case to go on.
We can probably get away with it within our own organisations. Somebody might end up being shifted into marketing and somebody else might resign but the outside world will most likely be unaffected. The trouble comes when we start outsourcing - now we have to get the specifications right because if we don't the result is likely to be conflict. "Sky knew it wanted a super-dooper CRM system but had little more idea of what it wanted or needed." Super-dooper is a great requirement but it doesn't quite translate into UML...
Now the EDS/BSkyB case might be extreme in the sums of money that are being laid out but it should serve as a timely reminder of the importance of having solid SLAs and requirements in place before any work commences.