Evidence-based stakeholder identification: Managing conflict and its impact on requirements prioritisation

In the complex world of building software, the people who matter most are often the hardest to find. These individuals, known as stakeholders, are the customers, managers, and users whose needs shape the final product. If a team misses a key person, the software might fail to solve the right problems or ignore critical risks. For decades, finding these people has been a matter of human intuition, relying on the experience of project managers to guess who holds the most influence. However, as projects grow larger and more global, guessing is no longer enough. The challenge is not just finding these people, but understanding how to weigh their conflicting opinions. One person might say a specific user is vital, while another insists they are irrelevant. When these subjective views clash, traditional methods often struggle to find a clear path forward, leaving teams unsure of who truly counts.

A team of researchers from the University of Almería has proposed a new way to solve this puzzle, moving away from gut feelings and toward a mathematical approach designed to handle disagreement. Their work focuses on a concept called "salience," which is simply a measure of how important or influential a person is perceived to be within a group. In their study, they treated the opinions of different people as pieces of evidence, much like a jury weighing testimony. They used a framework known as evidence theory, a method originally developed to handle uncertainty, to combine these subjective ratings into a single, clear picture. The researchers did not just look for agreement; they built a system specifically designed to manage conflict. By analyzing how much the recommenders disagreed with one another, their method could determine which stakeholders were genuinely central to the project and which were peripheral noise.

To test their idea, the researchers applied their method to a real-world dataset from a project at University College London called RALIC. This project involved merging library and fitness center access systems, and the original team had already identified a list of 18 key people and 28 roles. The researchers took a network of recommendations where hundreds of people rated the influence of others on a scale from zero to ten. They fed these ratings into their system, which converted the scores into a shared belief about who mattered most. The results were striking. In one version of the network, their method reduced the initial pool of potential stakeholders by nearly 85 percent, narrowing the list down to just 15 or 19 key individuals depending on the specific mathematical rule used. In another version, the reduction was about 70 percent. The system successfully filtered out the noise, identifying a core group that included people the original team had missed, while also confirming the importance of those they had already suspected.

The study revealed a fascinating relationship between conflict and clarity. The researchers found that when the people giving recommendations disagreed less, the system could agree on a smaller, more precise group of key stakeholders. Conversely, when the network was full of high conflict, the system became more cautious, identifying a slightly larger group to ensure nothing vital was missed. This behavior suggests that the level of disagreement within a team is a useful signal in itself. The researchers also discovered that the way people express their preferences matters immensely. They tested three different ways of gathering input: ranking items in order, giving them a score, or distributing a fixed number of points. They found that these different methods produced significantly different results. For instance, in a network with high conflict, changing from a ranking system to a scoring system completely altered which requirements were considered most important.

Perhaps the most significant finding was that the specific group of people chosen to provide input changed the outcome of the project's priorities. When the researchers compared the priorities set by the entire crowd of stakeholders against those set only by the "key" stakeholders identified by their method, the results were often statistically different. This means that relying on the opinions of everyone can lead to a different set of goals than relying on the opinions of the most influential people. In some cases, the "crowd" prioritized features that the key stakeholders did not care about, and vice versa. The study suggests that if a team does not carefully filter who they listen to, they risk building software that satisfies the many but fails the few who actually drive the project's success.

The researchers concluded that their approach offers a practical, automated way to identify the right people to listen to, turning a messy, subjective process into a structured, quantitative one. They did not claim to have solved every problem in software development, but they demonstrated that managing conflict is not just about smoothing things over; it is about using that conflict to refine the list of who matters. By treating stakeholder opinions as data that can be combined and analyzed, teams can move beyond intuition and make decisions based on a clear consensus. This work highlights that in the complex web of modern software projects, knowing who to listen to is just as critical as knowing what to build. The study serves as a reminder that the path to a successful project often begins not with a feature list, but with a precise understanding of the human network behind it.