After posting my last entry on questioning suspect requirements, I've read a great piece on the SlickEdit blog titled "How to Design Software With Bad Requirements."

Scott offers some practical tips to help developers deal with bad requirements. These also apply very well to business analysts and systems analysts:

• come up with good use cases - to help the business user visualize the system or process scenarios which do not make sense,
• create a prototype - if the end user's request can be modeled using a UI prototype, do so - they may see the light,
• abstract and encapsulate - assume that these requirements will change eventually and design your system in such a way to be able to easily modify it in the future,
• don't get discouraged - keep your spirits up and make the best out of the situation.