[RE 2026] Engineering the Social Fabric: Requirements Patterns for Modern OSNs
Requirements engineering patterns for the modeling of Online Social Networks features
This paper proposes a systematic approach to Requirements Engineering (RE) for Online Social Networks (OSNs) by introducing a set of reusable requirements patterns. The authors identify recurring features across popular platforms (e.g., Facebook, LinkedIn, Twitter) and formalize them into i-star (i*) Strategic Rationale models to facilitate the elicitation and modeling of new OSN systems.
TL;DR
Building a successful Online Social Network (OSN) is no longer just about writing code; it's about understanding the intricate web of social dependencies. This paper introduces a library of Requirements Engineering (RE) patterns using the i-star (i) language*, providing a blueprint for modeling everything from user profiles to complex privacy permissions.
The "Blind Spot" in Social Network Design
Despite the ubiquity of platforms like Facebook and LinkedIn, the academic world has largely focused on analyzing existing networks (graph properties, data mining, or sociology) rather than the engineering process of creating them.
The authors argue that the current state of OSN development lacks rigor in its early phases. Without a formal way to model stakeholder goals (e.g., a user's need for "Social Capital" or "Control over Privacy"), developers often fall into the trap of implicit requirements, leading to systems that fail to meet user expectations or compromise data security.
Methodology: Mapping Social Needs to i-star Models
The core contribution is the translation of common OSN features into i-star Strategic Rationale (SR) models. Why i-star? Because social networks are fundamentally about actors and their interdependencies.
The authors categorized features into seven pillars:
- Profile: Identity and self-presentation.
- Relationships: Unidirectional (Follow) vs. Bidirectional (Friend).
- Content: The "Knowledge-Sharing" vs. "Network-Oriented" dichotomy.
- Privacy: Managing the Public, Semi-Public, and Private spheres.
- Goal: The overarching purpose of the network.
- Recommendations: Enhancing experience through data inference.
- Connection: Interoperability between different OSN ecosystems.
Architecture of a Pattern
In an i-star model, we don't just see a "Login" button. We see a Resource Dependency where the OSN requires a "Login/Password" from the User to achieve the Goal of "Displaying a Profile."
Fig 1: The Profile Category SR Model - Notice how the softgoal "Present Herself" drives the entire task decomposition.
Visualizing Social Logic
The paper excels at breaking down complex interactions into logical flows. For instance, the Privacy Model (Fig 4) identifies four distinct actors (User, OSN, Public, and Friend), showing how the "Sense of Control" is a softgoal that depends on specific system tasks like "Keep post private" or "Display to group."
Fig 2: Modelling the Relationship Category - Capturing the nuance of unreciprocated following vs. mutual friendship.
Critical Insight & SOTA Comparison
Unlike traditional software patterns that focus on code structure (e.g., Gang of Four), these are Requirement Patterns. They answer the "Why" before the "How."
The most valuable aspect of this work is its Inductive Bias toward social capital. By including "Softgoals" (represented by cloud-like shapes in the diagrams), the paper forces designers to consider qualitative human needs—like a "Feeling of Connection" or "Experience Enhancement"—as first-class citizens in the technical design.
Conclusion and Future Outlook
While the patterns provided are a massive leap forward for the RE community, the authors acknowledge a limitation: the models need to be validated across diverse OSN types (e.g., dating apps vs. professional networks).
As we move toward a world of Decentralized Social Networks (DeSo) and AI-driven content generation, these patterns provide a necessary baseline. The next challenge will be updating these models to include actors like "AI Agents" or "Automated Moderation Bots," which were less prevalent when this foundational work began.
Final Takeaway: Don't build your next social app from scratch; use a pattern to ensure you're not just building a database, but a community.
