StakeRare: Revolutionizing Large-Scale Requirements Elicitation with Social Networks and AI
6859_StakeRare Using Social Networks and Collaborative Filtering for Large-Scale Requirements Elicitation.
This paper introduces StakeRare, a novel requirements elicitation method that integrates Social Network Analysis (SNA) and Collaborative Filtering (CF) to identify and prioritize stakeholders and requirements. Evaluated on a 30,000-user project (RALIC), it successfully automated prioritization and improved requirements completeness over traditional manual methods.
TL;DR
Requirements engineering for massive systems is often a bottleneck characterized by "loudest voice" bias and manual exhaustion. StakeRare breaks this cycle by treating stakeholders as a social network and requirements as items in a recommender system. By using Social Network Analysis (SNA) to weight influence and Collaborative Filtering (CF) to predict needs, it captures a more complete set of requirements in roughly half the time of traditional methods.
Background: The Scaling Wall
In projects with tens of thousands of users—like the FBI’s Virtual Case File or University access systems—elicitation is the hardest activity to scale. Traditional interviews and focus groups create information overload. Managers often resort to "rough guesses" for prioritization, leading to missed critical needs and project failure.
The StakeRare Methodology: From Sociology to Algorithms
The authors propose a four-step pipeline that replaces manual gatekeeping with algorithmic transparency:
- Stakeholder Identification (SNA): Using a "snowball" approach, stakeholders recommend others. This forms a directed graph where nodes are people and edges are recommendations.
- Profile Collection: Stakeholders rate an initial list of requirements. Crucially, ratings propagate through a hierarchy (e.g., if you like "All-in-one card," the system assumes you like "Library integration").
- Requirements Prediction (CF): Using the k-Nearest Neighbor (kNN) algorithm, the system identifies "like-minded" stakeholders. If Stakeholder A and B have similar tastes, and B suggests a new requirement, the system recommends that requirement to A.
- Global Prioritization: Final priorities aren't just averages. They are weighted by the stakeholder's Betweenness Centrality—a measure of their influence within the social network.
Figure 1: The four-step StakeRare process: Identify, Collect, Predict, and Prioritize.
Empirical Evidence: The RALIC Project
The authors tested StakeRare on the RALIC project at University College London—a system serving 30,000 users.
1. Completeness (Recall)
StakeRare identified 10% more "ground truth" requirements than the original project team. While the team (mostly decision-makers) missed "in-the-trenches" process requirements like "visual checking of roles," StakeRare captured them by being inclusive.
2. Accuracy of Prioritization
How does it compare to the "Ground Truth"? The correlation for high-level objectives was a staggering 0.8. Weighting participants by their social network influence significantly boosted the accuracy of the rankings.
Figure 2: Predictability of stakeholder needs across different elicitation methods (RankP, RateP, PointP).
Deep Insight: Beyond Manual Triage
The beauty of StakeRare lies in its Inductive Bias. It assumes that project influence is a structural property (Location in a network) and that requirements interest is a collaborative property (Similarity to others).
The study revealed that the original RALIC project team spent a disproportionate amount of time on "Card Design" (low priority in ground truth), while neglecting "Process Improvement" (high priority). StakeRare's algorithm correctly identified the priority shift that human managers missed.
Conclusion & Limitations
StakeRare is a landmark work in Evidence-Based Software Engineering. However, it is not without challenges:
- Cold Start: The quality depends on a solid "initial list" of requirements.
- Strategic Manipulation: Malicious stakeholders could theoretically "game" the network to inflate their importance, though Betweenness Centrality makes this harder than simple voting.
- Technical Constraints: The system was better at finding functional needs than obscure technical constraints (e.g., SQL Server versions).
Ultimately, StakeRare shifts requirements engineering from a "gatekeeper" model to a "crowdsourced" model, proving that the wisdom of the crowd—when filtered through the right algorithms—is more accurate and efficient than the individual.