First: Welcome to this little thing I like to call "real life".
Software developers are always saying that before we start a project, all the requirements should be fully nailed down, from detailed descriptions of algorithms to screen mock-ups, and once development work begins, no changes should be allowed. When the product is delivered, we will of course fix any deviations from the written requirements, but no changes that involve a change to the requirements are permitted.
Yes, this would make life much easier for the software developer. And it's an absurd demand.
Imagine that you wanted to buy a car. So you go to the car dealer and find that it's just an office with one guy behind a desk. He hands you a blank sheet of paper and says, "Write down here exactly what you want in a car. We'll then find a car meeting those requirements and deliver it to you. Once you sign the paper, we'll start searching for a car, so at that point no changes are permitted." "But," you say, "I have a general idea what I want, but I'd certainly want to try out a few different cars, take them for test drives ..." "No, I'm sorry," he says, "That's not possible. Just write down what you want and we'll get you a car meeting those requirements."
Now suppose that on top of that you have never driven a car before. How would you know what you want before you tried it? Things that seem like a good idea on paper may not work out so well in practice, etc.
I wouldn't be worried about vague requirements, PROVIDED that everyone involved understands that the requirements are vague, that you are going to have to fill in the gaps, and that when they see the decisions you've made, there WILL be some decisions that they don't like and things will have to be reworked.
If this is a loose and co-operative environment, there should be no problem. You produce something, bring it for review, they tell you what they like and what they don't, you make changes, maybe go in many cycles. I've done many, many projects like that in my life. Often the user has to try out the software to see what works in practice and what doesn't.
If the boss or the client are making unreasonable demands, or if you don't know what the environment is like, then you need to get things in writing to protect yourself. I've done some projects in my life where the boss or the client says, "I don't know what all the requirements are, you just make something up". Then I make something up and when I bring it back they scream, "What! That's not what I wanted! What kind of moron are you? Surely it was obvious that ..." and then proceed to give a whole bunch of requirements that they never mentioned before and that were not obvious to me at all. In that sort of environment -- even if it's not yelling and threats of firing you or cancelling the contract, maybe it's just expressions of severe disappointment and frustration -- in that sort of environment, write up a paper describing what you propose to do and give it back to them for approval. If you're lucky, this will lead to discussion of what the real requirements are. At worst they say "yes yes whatever" and brush it off. But at least at this point, when you then come back with the software, if they say, "That's not what we wanted", you can bring back the document and say, "Oh, I'm sorry, this is what we agreed I should do. See, it's written right here, and you approved it." In a friendly environment you say this in a friendly way; in a hostile environment you may have to be more forceful. Either way you then say, "Okay, so what changes to the requirements do you want to make?" Then put those in writing and start another cycle.
If the boss or client expects impossible turn-around times and blames you when impossible demands are not met, then frankly it's time to start looking for another job or another client. Or if you need this job/client badly enough, you suck it up and take the abuse. (I have fond memories of the time my boss asked me how long it would take to convert a large, complex system our company had built years ago from an old computer language to a more modern language. I started trying to think out loud a bit, we'd done such a translation on another product so we had some experience, but no one in the company today was familiar with this product, blah blah, and then he said, "I don't need an exact answer, just roughly: two days? three days?" I was flabbergasted, "Umm, no," I said, "The question is how many months." He walked away muttering.)