Collective Intelligence in Internetware: Scaling Requirements Elicitation via Stigmergy

TL;DR

As software shifts toward the "Internetware" paradigm—defined by open, dynamic, and large-scale environments—traditional requirements engineering hits a wall. This paper proposes a radical shift: instead of engineers interviewing users, the collective intelligence of the user community is harnessed through stigmergy. By using a collaborative "Collective Feature Model," requirements emerge and evolve naturally from indirect user interactions, much like how a termite colony builds complex nests without a central architect.

The Scaling Wall: Why Traditional RE Fails Internetware

Traditional Requirements Engineering (RE) is fundamentally engineer-centered. It relies on face-to-face workshops and interviews. While effective for bespoke corporate software, this approach is physically and logically impossible for Internetware (e.g., massive social platforms, distributed service ecosystems) where:

• The user base is massive and physically distributed.
• Requirements are highly diverse and constantly evolving.
• Direct communication between all stakeholders creates a coordination overhead that kills productivity.

The authors argue that the missing link is a mechanism that allows individual work to translate into collective gain without forced consensus.

Methodology: The Fusion of Feature Models and Stigmergy

The core of the paper is the transition from individual mental models to a Collective Feature Model (CFM).

1. The Stigmergic Mechanism

In nature, stigmergy allows agents to communicate through the environment. In this framework, the "environment" is a Web space hosting the CFM. When a user creates or references a feature, they leave a "trace" (the nor attribute—number of referencers). This trace triggers other users to refine or modify that feature, creating a positive feedback loop.

2. The Collective Feature Model (CFM) Meta-model

Unlike a standard Feature Model, the CFM is designed to handle conflict and variability. It distinguishes between:

• System Elements (Features): The core entities.
• User Elements (Names, Descriptions, Relations): The diverse perspectives of different users.

A key innovation is the modified-from relation, which preserves the evolutionary history of a requirement rather than overwriting it, allowing the "strongest" or most accepted version to naturally surface via higher reference counts.

Experiments: The "Wisdom of the Novice Crowd"

The authors conducted a fascinating simulation comparing "Expert Collectives" (5 agents with high knowledge) against "Novice Collectives" (250 agents with minimal individual knowledge).

Key Findings:

• Greater Coverage: The novice collective produced a denser and more comprehensive feature model than the experts. The "massively parallel" exploration by novices, guided by environmental traces, overcame the limited bandwidth of the expert group.
• Self-Organization: The distribution of contributions followed a Power Law. This indicates that the system reached a state of "self-organized criticality," where a few highly active agents provide the backbone of the model while a "long tail" of users provides niche refinements.

Critical Insight: Beyond Consensus

The brilliance of this approach lies in its treatment of variability. Most collaborative tools force a "vote" or a "merge" to reach equilibrium. Stigmergy allows the model to remain in a state of flux. If a new requirement emerges or an old one becomes obsolete, the nor count simply shifts. The "Requirement" is not a static document but a dynamic, emergent property of the community's interactions.

Conclusion and Future Directions

This paper serves as a blueprint for the "Global Brain" in software engineering. By treating requirements as a biological emergence rather than a technical specification, it provides a path to manage the complexity of Internet-scale software.

Limitations: The primary challenge remains incentive. While the system works technically, why would a user volunteer their time to model features? Future research must bridge this with "Gamification" or "Incentive Engineering."

Takeaway for Architects: Stop trying to build the perfect feature list. Build the environment where your users can build it for you.