The Social Requirements Engineering (SRE) Approach to Developing a Large-scale Personal Learning Environment Infrastructure Effie Lai-Chong Law, Arunangsu Chatterjee, Dominik Renzel and Ralf Klamma Department of Computer Science, University of Leicester, UK Chair of Computer Science 5 - Information Systems, RWTH Aachen University, Germany EC-TEL 2012, Saarbrücken, Germany September 21, 2012

1. The Social Requirements Engineering (SRE)
Approach to Developing a Large scale Personal
Large-scale
Learning Environment Infrastructure
Effie Lai-Chong Law1, Arunangsu Chatterjee1, Dominik Renzel2 and Ralf Klamma2
1Department of Computer Science, University of Leicester, UK
2Chair of Computer Science 5 - Information Systems, RWTH Aachen University, Germany
EC-TEL 2012, Saarbrücken, Germany
September 21, 2012
This work by the above authors is licensed under a
Creative Commons Attribution-ShareAlike 3.0 Unported.
© www.role-project.eu

2. Personal Learning Environments (PLE)
“a pedagogy-driven infrastructure that facilitates learners to
integrate distributed contents services tools and contacts
contents, services,
based on personal goals and preferences, thereby enabling
them to control their own learning and to connect different
g
learning contexts with the support of communities”

3. Motivation
I know which tools my
Which tools should I learners would need
need...
develop to create But I can‘t develop!
most impact?

4. Motivation
 Users (many)
 high potential to elicit requirements from domain knowledge [Hipp86]
 usually not acquainted with formal specs developer tools & tech jargon
specs,
 need intuitive means for stating community-specific requirements
 dependent on developers realizing their requirements
 Developers (few)
 often not acquainted with domain knowledge and community jargon
 use formal specs tools & jargon for reasons of effectiveness & efficiency
specs,
 used to integration between development tools
 interested in requirements prioritization to maximize outcome
 Needed: model & software to support negotiation process
 ROLE Social Requirements Engineering (SRE)
 ROLE Requirements Bazaar

5. Theoretical Premises
 Transcriptivity Theory (Jäger, 2002) describing the operational
semantics
 ATLAS (Architecture for Transcription, Localization, and
Addressing Systems) - , scalable and interoperable repositories
on top of databases support communities by web service
technologies (Jarke and Klamma, 2006)
 Communities of Practice (CoP) (Wenger, 1998)
 Actor-network-theory (ANT) (Latour 1999)
Details available via ROLE website > Results > Deliverables > Wp1
deliverables

6. The ROLE SRE Approach – Support for the Long Tail
 No Mainstream Web 2.0 RE!
 “O
“Overall T N“ naive approach
ll Top-N“: i h
 Needs of specialized CoPs neglected
 I
Innovation Killer ( l
ti Kill (clones only)
l )
 Rather Long-Tail RE
 “Community-Aware Top-N“
 Special support for niche CoPs
 High specialization, but high innovation

7. ROLE Social Requirements Engineering (SRE) – i* SR

8. ROLE Requirements Bazaar – Required Features

9. ROLE Requirements Bazaar – Initial Mockup

10. ROLE Requirements Bazaar – Early Prototypes
Quantitative assistance mechanisms
during negotiation
Hybrid ranking mechanism
Web-based requirements elicitation form
Requirements review

11. Lessons Learned from Early Prototype Evaluations
 Evaluations in 2 workshops in 2011
 Developers & pedagogical experts (N~20)
 Early-stage TEL researchers (N~20)
 Issues Identified
 Culture & language diversity
 Lack of common understanding about PLEs
 Inadequate communication
I d t i ti
 Distinction between infrastructure and widgets requirements
 Lurking
 Resolutions Proposed
 Documentation for improving understanding of PLE
 Easy-to-use templates for requirements elicitation
 Mandatory voting
 Prioritisation model

12. Intuitive Means for Requirements Elicitation
Comic-like
C i lik annotations
t ti Web 2.0 feedback tools:
on screenshots/Storytelling  uservoice.com
 getsatisfaction.com

13. ROLE Requirements Bazaar – Current Prototype

14. ROLE Requirements Bazaar –
Community-aware Requirements Prioritization
Community-dependent
requirements ranking lists
Factors influencing
requirements ranking
User-controlled weighting
of ranking factors

15. Useful Sources for Requirements Ranking
 User-to-Service Communication
 CoP-aware usage statistics
 Identification of successful CoP services
 Identification of CoP service usage patterns
 User to User Communication
User-to-User
 CoP-aware Social Network Analysis
 Identification of influential CoP members
de ca o o ue a Co e be s
 Identification of CoP member interaction patterns
+

16. ROLE Requirements Bazaar –
Requirements Ranking Infrastructure
URA = User Rating Analysis (baseline)
UMA = User Monitoring Analysis

17. Integration of the Bazaar with external services

18. Lessons Learned
 Lack of common understanding and awareness about PLEs.
 Developers/teachers/researchers acting as “surrogate customer”
which is a potential problem
 Inadequate communication among “end-users” and developers
around proposed requirements
 Cultural diversity and language barrier – Chinese, German and
English
 View Separation important as demonstrated earlier
 Expose relevant requirements as per users context
 Ensure easily configurable views
 Devise mechanism to counter ‘Cold Start’ problems
 Mandatory voting
 Reward mechanism in terms of visible reputation scores or badges

19. Future Improvements
 E
Ease of contribution
f t ib ti
 Create templates that users can edit rather than forcing them to
start from scratch
 Allow users to enter requirements in their preferred language
 Integrate with development infrastructure (e.g JIRA) for enhanced
traceability
t bilit
 Prioritisation model
 Attempt of extract rationales behind ratings
 Utilise SNA and Monitoring data to assist decision support via a
RE dashboard
 Requirements dashboard
 Users able to view their own activity
 View community activity