I have not been involved in any mega or huge software application development. But i have developed number of smaller and medium scaled application with real stake holders. As they say customer is always right.. So one who is sponsoring the project is most important stake holder.

But in my view its the duty of the project manager to identify which changes in the requirement are critical and very important for the success of the project. After all a successful project is the requirement of all stake holders.

So in short the role of the project manager is most important as he has to fully understand the future vision of the project and how it will be successful and what changes are critical for its success and to find ways to convince other in a conflict situations that which way is more beneficial and which is less. If he is not clear himself and dont understand the domain very well and dont understand scope and target of the project he will not be able to handle conflict very well

Few techniques from experience and from the literature:

- A process called rethinking the requirements – by going back the sources of the conflicting requirements and tries to understand and address it differently.

- Getting all the stakeholders in one place and make them discuss and analyzing the trade-offs among the conflicting requirements and come up with prioritization process in terms of, value to the project, cost, time, etc.

- Try to replace 2 or more conflicting requirements (function or feature) with a single one that addresses the goals of the conflicting requirements.

Security and usability – always tend to conflict each other.

An example could be the conflict between non functional requirements, i.e. performance vs. security, the client want certain functionality being satisfied in minimal time (calculate something and display it on screen) and using a secure protocol for data-transferee and double password access control.

The solution would have to identify exactly where and when these features are required and if this combination is feasible.

I strongly suggest adding this question to the requirements engineering topic.

It is a very tricky situation. In any organization, every stakeholder will try to establish his/her supremacy and that leads to conflicts in requirements gathering. The best way to deal with the situation is to clearly define the role or domain of each stakeholder. The Group Leader should have the control to fine tune the conflicts and offer a mutually agreeable solutions.

You should compare stakeholders request with organizational documents

Requirements need to be analyzed and prioritized properly. Conflicts can be avoided by maintaining a balance between the requirements and accepting only those that are justified and for which quality solutions can be provided within project schedule and budget.

The best technique I know for working with functional requirements for software systems is known from Rational Unified Process and is named use-case workshop. You can invite stakeholders for this kind of meeting and create use-case diagram for the whole system, introduce short use-case descriptions and then detail the use-case descriptions. This is an iterative process, so you need several meetings of this kind. You can share your desktop in case of distributed team. I used this technique several times - always successfuly.

Other options are:

- using group-techniques such as focus group, brainstorming, KJ method, workshops, etc.

- using win-win model

-using GORE and i* diagrams to share the goals and objectives from the stakeholders

Yes, there is a lot of group-techniques that can be applied for your problem, but not all of them are good for regular work. I think you cannot assume that conflicts will not repeat - requirements usually change constantly. For example brainstorming is very exhausting for the team - I used this technique only once to solve a critical PM problem. That is why I suggested the best one for regular work, at least in my opinion.

Tracking the tenuous links between stakeholders could go on for ever and you need to draw boundaries as to whom you should consider. This depends very much on the nature of the systems being designed, but largely requires plain common sense. The first things to find out is who are your users according to the context of the system (for Example designing generic software is difficult because of many different users with different purposes and characteristics.) Instead of thinking of a generic user with generic skills and goals is better to think on several specific users. Second you have to consider that "you" and your own interests and abilities can differ from other users. Third step is talking to your "possible" stakeholders (participatory design): structured interviews, open-ended discussions, or bringing the stakeholders into the design process. I used the participatory design for my last project and the result were impressive. A system must be not only useful and usable, but also USED. Forth step is to "watch" your stakeholders and "hear" what they say. This may involve sitting and taking notes how they use a system like yours. You can use a video camera or tape recorder. Their explanation have to match what they really do. The last step is called: use your imagination. Even if you cannot involve every actual stakeholders you can at least try to imagine their experiences. One method that has been quite successful in helping design teams produce user-focused designs is the "persona"(a rich picture of an imaginary person who represents your core user group ).

References: Human-Computer Interaction; Alan Dix, Janet Finlay, Gregory D. Abowd, Russell Beale

There is also one nore thing that could be taken into account when talking about conflicts of stakeholder interests. This is somehow similar to negative and positive risks in IT projects. I mean, you can define on the level of requirements (and the contract as well) both what the system should do and what the system need not do. The last approach may help to block some areas against potential conflicts of stakeholder needs. Sometimes it is easier to achieve the agreement what the system need not do.

I recommend to have a look at the Value Proposition Model-Clash spiderweb http://www.sigs.de/download/oop_08/Biffl%20Do1.4.pdf

Another interesting approach is the "Specification by Example" approach http://specificationbyexample.com