Sounds simple, however, getting the requirements is one, finding out their corresponding stakes is another. Why bother anyway, what is it worth? A lot. As mentioned earlier, one can't effectively change the stakes, but one can change the requirements as long as they keep on supporting the stakes. In this way there is room to negotiate a set of requirements to the project, which do not conflict, match the stakes and thus making every one a winner! Right?

Taking it one step back. A stakeholder formulates a requirement for the software project. E.g. senior management states that "the project should be finished before the end of August." The project manager has to deal with it. When this deadline is no problem, he can rest assure. However, it's a software project, so the deadline will be a problem. The way to handle it is to get some information on the stakes that caused to formulate this requirement.

Perhaps it's the old "don't want to loose my face when my projects get delayed." That being the case, the project manager can offer alternatives that don't violate the stake, like keeping the deadline, but postpone a subsystem. Changes are that alternative requirements that keep supporting stakes, are accepted. Maybe not easily, but a project manager should do something to earn it's money.

An example, taken from Brooks:

… the reluctance to document designs is not due merely to laziness or time pressure. Instead it comes from the designer's reluctance to commit himself to the defense of decisions which he knows to be tentative. 'By documenting a design, the designer exposes himself to the criticisms of everyone, and must be able to defend everything he writes. If the organizational structure is threatening in anyway, nothing is going to be documented until it's completely defensible.' (The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition)