Antipattern of the month #3: suicide requirements

Almost all living things in the world (with notable exceptions) have that little survival thinguie adhered to the brain, you know, striving for practical stuff like keeping alive and such.

And every now and then, evolution goes backwards and starts producing the kind of corporate species you can find at any project. People that train hard to distill the best equivalent to a Darwin Award of Project Management. These people claim ignorance, but are indeed thoroughly documented bastards that carefully handcraft THE requirement that might kill the whole project. When conceived, they manage to bury it with a single line at the end of the most innocent paragraph near the end of the The Big Requirements Pile, where your tired sight will most probably not notice:

"The system must be able to simulate the whole behaviour, connecting in real time with all the external systems with a rollback feature that restores up to one month of data to the start of the simulation." (No more references to this "simulation" requirement in the whole document)

"The billing system must be able to "undo" a bill, up to one week after its billing date [...] ERP accounting syncronization must be done once a day [...] bill rollback must propagate to the ERP." Note that this could potentially affect quarter and fiscal year results

"The whole system will be developed with a 5-layer SGML-based architecture." Substitute the architecture with your favourite design pattern: almighty-controller, database-object-repository, pink-flamingo-delegate.

"Can we completely remove the app server and the database?" (Asked after four months of full-speed development)

Oh, yes. All these are real requirements, in real projects. Viability is overrated.