Note: This post has been in draft since October 2006. But my views have changed very little, which is nice. My grammar has changed though, so I've made a few adjustments to reflect that.

There are many programmers/software developers out there who take a requirements spec, design what the spec says, and deliver the product which is what the client wants, right?

Software is for people, the people who use it. Not the people who wrote the spec. It is vital to understand the original business need rather than the software need. In most cases a non technical committee wrote this spec, and from that you can be sure that it is bloated, likely with after thoughts. It doesn't take much time to ask for more, but it takes more time to create it and even more time than that to avoid it when using it.

Spend time with the user. Don't ask them what they want, but observe and try to understand what they need. If you spend time with the customer/end user of the software, you will quickly realise that the core business need is much simpler than the spec your recieved.

I work as an software consultant in an IT Outsourcing company, based in Dublin. Software development is not one of the companies core markets, but we do have a need for small systems to help with our business processes.

When I recieve a spec, I read it once, then head to the person who needs the application. I spend time with them, watching their work, and what they do daily. I ask them their expectations for the system, and tell them my ideas. I know this is not ideal when a spec is from an external client, but if it can be built into the requirements building process, this can work to the advantage of all parties involved, ultimately to the end users satisfaction.