The answer for some of this questions is strongly dependent from the problem domain, and the amount of knowledge that your development team and the stakeholders have about it.

First of all, what do you mean by big projects ? Projects are not big just because of the amount of users, they are big because of their complexity.

The task of a team leader is to break that complexity into smaller units and make them flow over smaller teams or individuals capable of assimilate them.

The main sources of complexity of a software system are:

1. Functional requirements (It comes from the problem domain: The concepts involved and the nature of their relationships)

2. Non-functional requirements (usability, performance, cost, survivability, and reliability, etc..)

As long as I know, the requirements come from the stakeholders. They represent the users, and in a perfect world they should make a lot of the work you have already done and give you the requirements.

My advice is that you should not negotiate requirements with the users. It happens a lot (and more with big projects) that the vast amount of users do not comprehend completely the problem domain.

You'll see, one organization is defined more or less like: a group of persons and resources organized for some end or work. They should have a common vision and mission. They should comprehend all their process, the performance key indicators to measure their success and achieve the goal.

For big organizations, it frequently happens that users doesn't have idea of how the whole system works. If you ask them they can even give you conflicting requirements. And the bad side is that, given that the complexity of the problem domain is big, you might note this later during the development phase, when the ball is in your side.

And the challenge is even bigger for your team if such a thing happen. They might stop by the need to ask back the resolution of such conflicting requirements. And that breaks your team dynamic.

The fact that users don't know how the whole system work to perform their daily task is normal. Even without a software they have a system with their own complexity, that might not fit into a single brain.

As a matter of fact, in its book Object Oriented Analysis and Design with applications, Grady Booch defines:

The distinguishing characteristic of industrial-strength software is that it is intensely difficult, if not impossible, for the individual developer to comprehend all the subtleties of its design.

I guess you are responsible of driving the complexity in your team. In the same way, there should be a directive from the side of the client in charge of driving their complexity. That's usually the stakeholder, not the user.

My advice is that you stop accessing the users, and find the minimal amount of persons that can tell you the requirements. That force them to reach an agreement and align to a common vision. They will need time and resources to do that, but it its not charged to you.

I am almost sure that the software development process is used by a lot of clients, intentionally or not, to organize their process. I think that this should not fall into your team at least that you know precisely the problem domain, have planned the resources for it, and invoice it properly.

---- a note about the changing requirements ---

In the same book referenced before, read the part: The Complexity of the Problem Domain. There Booch talks about the impedance mismatch that exists between the users of a system and its developers and the complexity it represents.

It also points out which is the cause of the changing requirements, and how you should classify their costs to succeed.