I grew up in programming in very small shops, where formal requirements were seldom, if ever used. I prided myself on my "customer service" and flexibility. If the customer wasn't happy with my guess, then I'd be happy to fix it. And fix it again ...As time went by the constant re-work that this mindset doomed me to began to wear on me. Projects didn't get done well, or even done. I began to see the users as adversaries, something I happen to believe is the kiss of death in this field.

A few years ago I started working with an App Development Manager who insisted that end users come up with clear specifications before work began. Many of the end users were used to the previous style and would say things like "Oh, you just throw something together for me and I'll change what I don't like" This manager would politely point out that our (the IT departments) time was a scarce resource and was not going to be used in guessing games. And that, to me was a new way of thinking.

Our time, knowledge, and talents are a scarce resource, whether we are more admin/DBA monks like me, or design wizards like Ovid. We need to use this resource wisely so we can be people who are smart, and get things done. Requirements cut down on re-work by exposing flaws in the business rules, or shortages of resources needed, before we attempt the first line of code.

I've had end users react in various ways to the requirement of clear specifications. Some think I'm shirking my responsibilities and are making them do my job. Some become treasured allies in the design/build process. Some get lost in the details. Some never come back with a spec!

In the end I can say we have less re-work, less finger-pointing, and more productivity. We also have much clearer communications between the users and IT staff. It's been a win for all.