Modeling the Mind of the Feed: Bridging Recommendation Rules and Requirements Engineering

TL;DR

Online Social Networks (OSNs) are the primary battlegrounds for the war against information overload. While most research focuses on the accuracy of algorithms, this paper shifts the focus to the representation of these algorithms. By using the i-star (i) framework*, the authors model recommendation rules as fundamental system requirements, visualization how content filtering affects user-system dependencies and long-term engagement.

Background: The Invisible Hand of the Algorithm

We often think of recommendation systems as purely mathematical entities (Collaborative Filtering, Content-Based). However, in the world of Requirements Engineering (RE), an algorithm is a set of rules that dictates system behavior and shapes user interaction. The authors argue that if an algorithm influences how a user perceives the value of a platform, it must be represented in the platform’s requirements model.

The Core Challenge: Content vs. Connection

Prior work in OSN recommendations largely focused on "Who should you follow?" (Friend recommendations). This paper dives into "What should you see?" (Event types).

The authors categorize OSN interactions into:

• Core Content: Profile updates, photo shares, direct messages (highly relevant).
• Neutral/Optional: Group joins, likes on status, "Sign in" notifications (context-dependent).

The challenge is defining a requirement set that balances the need for "Relevant Recommendations" (reducing noise) with "User Involvement" (keeping the user active).

Methodology: Mapping Rules to i* Models

The authors propose a dual-layered modeling approach using the i-star framework, which focuses on "the whys" behind system tasks.

1. The Decision Trees

They first define two algorithms based on user frequency. A "rare user" or "popular user" receives only Core content to avoid being buried in notifications (Fig 1). An "active user" with fewer friends receives Neutral content to maintain engagement (Fig 2).

2. Strategic Dependency (SD) & Rationale (SR)

The paper translates these trees into i* models:

• SD Model: Defines how the Receiver depends on the OSN to filter noise, while the OSN depends on the Generator to provide the raw content.
• SR Model: Breaks down the internal tasks of the OSN, such as "Apply decision tree" and "Gather user information."

Fig 5: This model illustrates the conflict between mitigating information overload and maximizing user involvement.

Critical Insight: The "Usage Loop"

One of the most profound contributions is the visualization of the OSN Usage Cycle. An event generated by User A triggers a recommendation rule, which determines if User B sees it. If User B reacts, it generates a new event, creating a feedback loop. Modeling this loop allows developers to see how a "relevant" filter at step one affects the growth of the network at step ten.

Experimental Lessons

Based on surveys of 600 students, the authors identified that factors like closeness of friends and common interests are the strongest predictors of subjective relevance. Surprisingly, many metadata elements (like location or emoticons) were found to be irrelevant to the perceived importance of a notification.

Critical Analysis & Future Outlook

While the paper provides a robust framework for modeling rules, it acknowledges two limitations:

1. Timing: The i* framework struggles to capture the chronological "Steps" of the loop (e.g., the delay between posting and noticing).
2. Implicit Data: The current models rely on explicit rules rather than the "hidden" latent features used in modern deep-learning recommendation engines.

The Takeaway: As AI becomes the backbone of software, we must stop treating algorithms as "implementation details." By bringing recommendation logic into Requirements Engineering, we can design OSNs that are not just technically efficient, but human-centrically relevant.