Q:

How to deal with frequent requirements changes?

I'm dealing with pretty stressful (in my opinion) situation in my current work place. 
We've started developing new project, get some requirements, implemented it and then show to someone you can call a 'business advisor' (person who knows business requirements but will not use the program). That person is supposed to evaluate application from customers point of view, test it etc.
Here how the 'process' looks:

business advisor talks in the evening with my boss for hour or two on windows messenger
the next day I receive email with copy of that conversation. I am supposed to choose tasks from that, check reported bugs (which often aren't bugs, just poor testing and forgetting about past establishments)
I implement changes, implementation gets accepted and then in a week or two it turns out that isn't want they want (they talked with some potential client that have seen software for 5 minutes and he suggested changes) - I have to do new changes

Don't get me wrong, I understand that sometimes requirements change. What upsets me is how often the change occur in my workplace and how easy for 'management' is two give new requirements or sometimes fundamental changes to existing features. 
At the same we working on tight deadlines and I have impression that instead of going forward with our software we're running circles.
I seek advise from you how to deal with this situation? Is this normal situation and I'm just hypersensitive about it?

A:

If at all possible, take the conversation you're emailed and turn it into a requirements document. List the tasks that you can glean from it and order them by what you perceive to be the priority and assign an estimate to each. Then ask which features they want for the next release.
Basically, force some kind of feedback loop where the management is aware what is it that you're going to build. Write your own requirements documents until such time as they get the message.
Story Cards
I think your situation is well suited to introducing user stories. They're really helpful in providing an ongoing, interactive way for your manager to set priorities and he can even throw them away when he comes back to the idea a week later and realises it's not workable.

A:

In the real world, requirements change routinely.  On the plus side, you find out about it before you finish building the software and ship it out - you have a tight feedback cycle from the direct user of the software, which is actually great.
It seems like the biggest problem here is the very ad-hoc way that change is managed.  You have what agile / Scrum consider a "product owner", who gives feedback, but the process is poorly documented, and poorly thought out.
You probably want to look at the models in Scrum, and their view of what an effective product owner is, to help inform your next steps.
So, instead of having this ad-hoc process, aim to move to a world where you have a closer and more useful relationship with the "business advisor", and where everyone is on the same page about the outcomes of the changes they are discussing.

