AKA WIBNI. From the Jargon File (http://catb.org/~esr/jargon/html/W/WIBNI.html): "What most requirements documents and specifications consist entirely of."

The implication here is that the WIBNI was pulled out of thin air by someone who understood the problems at hand no more than the people they're trying to communicate them to, and end up with specs that read a lot like "wouldn't it be nice if it could do the dishes, travel through time and reverse the entropic decay of the universe? Oh, and what I ''really'' want is a simple application that can do monthly account reports on my payroll database, but you'll have to find that out by reading between the lines." WIBNIs are often complete areas of research, and/or borne out of a desire not to look too timid when demanding software for those awesome, godlike computers.

Another frequent occurrence is in the SecondSystemEffect: people are obsessed with fixing the problems and limitations of the old system "once and for all", and come up with a BigDesignUpFront (minus the actual design...) that has little chance of exceeding the original -- and a good chance of actually ending up worse. Such systems are specified by long and structureless wishlists that lack any sort of coherent goal or outline, and tempt developers into delving into individual wishes, giving the users exactly the sort of roughshod patchwork they didn't know they were asking for.

Remember that YouArentGonnaNeedIt. Get a good SystemMetaphor started, instead. Most importantly, don't treat everything your customer says as gospel. Often, your customers don't ''know'' what they want. Part of your job is getting them to express it clearly.

Compare CreepingFeaturitis, CouldYouJust