Because the stakeholders will have different interests in the project and requirements, it's good to review a copy of the project's accountability matrix, or the RACI chart which tells who's Responsible, Accountable, Consulted, and Informed. If the project files include some sort of accountability matrix, that's a good place to start assembling one for the requirements. (It's a good idea to create a unique accountability matrix for the requirements stakeholders, because they'll seldom be the same as the project stakeholders.)
Start by reviewing
your stakeholder analysis, to make sure you have a full list of stakeholders and their roles. Then consult your Requirements Management Plan, which should tell you the categories and organizational structure of the requirements. You should be able to combine these lists into a RACI chart that will show you, at a glance, who has a voice in each requirements category.
If you start out knowing which stakeholders are decision makers and which have a less active role in the requirements, you'll avoid confusion and tension later. If the project manager doesn't have an accountability matrix that covers the entire project, you can offer them your requirements responsibility matrix as a starting point.
Be aware that responsibilities are rarely clear-cut. For example, a stakeholder may have decision-making responsibility for one type of requirement, but no others. Understanding the relationships between your stakeholders early on, and their roles in the requirements process, will facilitate better communication as the project goes forward.