Beyond Favoritism: Neutralizing In-Group Bias in Requirement Engineering

TL;DR

Requirement Engineering (RE) is often sabotaged by human nature: stakeholders tend to recommend their friends rather than the most qualified experts. This paper proposes a dual-layered filtering framework that combines Hybrid Centrality Measures (HCM) with the Power, Legitimacy, and Urgency (PLU) model to statistically dilute "in-group bias," resulting in more accurate stakeholder prioritization and a 40% increase in valid requirement identification.

The "Friendship Trap" in Requirement Engineering

In large-scale or distributed software projects, identification of the right stakeholders is critical. Modern tools use social network analysis—where stakeholders recommend others—to build a map of influence. However, this creates a Conflict of Interest Bias. Stakeholder A recommends Stakeholder B not because B is an expert, but because they have a "good rapport."

Prior works like StakeNet or StakeRare utilized centrality measures (betweenness, closeness) but failed to account for this human element. If the wrong people are prioritized, the resulting software requirements are skewed, leading to "feature bloat" or missing critical safety functions.

Methodology: The Synthesis of Math and Management

The core innovation lies in the mathematical fusion of two distinct domains: Graph Theory and Management Science.

1. The Hybrid Centrality Measure (HCM)

The authors argue that no single metric captures influence. They propose an HCM that balances three dimensions:

• Degree Centrality: Popularity (number of connections).
• Betweenness: Control (acting as a bridge between groups).
• Closeness: Efficiency (speed of information spread).

2. The PLU "Reality Check"

To counter the popularity contest, the Power, Legitimacy, and Urgency (PLU) model is introduced. Stakeholders are categorized into seven types (Dormant, Discretionary, Demanding, Dominant, Dangerous, Dependent, and Definite).

The Formula for Accuracy: $\mathbb{P}=himes{\mathcal{I}}^{\partial }$ Where $h$ is the HCM score and ${\mathcal{I}}^{\partial }$ is the PLU salience weight. This ensures that even if someone is highly "central" due to friendships, their score is moderated by their legitimate standing in the project.

Experimental Validation

The researchers conducted a controlled experiment with 40 participants (software engineers and researchers) divided into two groups. They faced "Easy" (Android MIS) and "Hard" (Safety-critical clouds hospital system) tasks.

Key Findings:

• Efficiency: The proposed process had a median completion time of 152 minutes, whereas the biased group took 192 minutes. Accurate identification reduced conflicts and negotiation time.
• Effectiveness: The HCM+PLU group identified 76 valid requirements compared to only 54 in the control group.

Critical Insight: The "Satisfaction" Paradox

Interestingly, while the proposed method was objectively better, participants reported lower satisfaction levels. Why? Human beings dislike the "complexity" of formal processes and often prefer the ease of traditional, biased communication. This highlights a major hurdle in RE: The psychological resistance to objective metrics.

Conclusion and Future Outlook

This work represents a significant step in making RE more scientific by quantifying social dynamics. The next frontier, as suggested by the authors, involves integrating Natural Language Processing (NLP) to further reduce the reliance on human moderators, potentially automating the detection of bias in real-time conversations on platforms like Slack or Microsoft Teams.

Final Takeaway: Software quality starts with people. If you don't filter the social noise during the requirement phase, no amount of clean code can save the project.