Social Requirements Engineering for Large Scale Personal Learning Environments
•
1 like•389 views
The document discusses using a social requirements engineering approach to develop a large-scale personal learning environment infrastructure. It proposes using social network analysis and user rankings to prioritize requirements stated by multiple heterogeneous communities with different interests and technical expertise. The approach aims to provide developers with a compact overview of learning needs and support continuous collaboration between stakeholders.
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (17)
Recently uploaded
Recently uploaded (20)
Social Requirements Engineering for Large Scale Personal Learning Environments
- 1. The Social Requirements Engineering (SRE) Approach to Developing a Large-scale Personal Learning Environment Infrastructure © www.role-project.eu
- 2. Personal Learning Environments (PLE) “a pedagogy-driven infrastructure that facilitates learners to integrate distributed contents, services, tools and contacts based on personal goals and preferences, thereby enabling them to control their own learning and to connect different learning contexts with the support of communities”
- 3. Why Social Requirements Engineering in ROLE? • Encourage continuous collaboration between Stakeholders • Challenges: • Massive amounts of requirements... • stated by lots of users... • organized in multiple heterogenous communities... • with different interests/practices/levels of technical literacy... • stating imprecise/informal requirements... • Needed: Decision Support for developers • Compact overview of learning needs(Requirements Baazar)
- 4. 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
- 5. Proposed Strategic Rationale model - (i* representation)
- 7. Proposed requirements prioritization dsfsfssasadas sdasdsadasds sdaddsasdsad dsfsfssasadas sdasdsadasds sdaddsasdsad dsadsadsad adsadasdas sdasds asdasdasdasd dsadsadsad adsadasdas sdasds asdasdasdasd asdasdasdasd asdasdasdasd adsad asdsasadasda adsad asdsasadasda sd sd sadsa sadsa d d User rankings: everybody contributes but we can‟t differentiate between users and impacts of their contributions + Social Network Analysis: roles of users are defined using different centrality measures, however users‟ behaviour of tool usage is not clear dsfsfssasadasdsadsaxvxc vc xvc x vxvc xvc xvxc vdftgdtgrdiogtrfodsfsfssasadasdsadsaxvxc vc xvc xv xvc xvc xvxc vdftgdtg rdiogtrfoigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiärepsitoprtölfkglkfl kjflj klfjl kfl kjfl kjl kfjgdsad dsfsfssasadasdsadsaxvxc vc xvc x vxvc xvc xvxc vdftgdtgrdiogtrfoigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiär epsitop rtölfkglkflkjfljklfjl kfl kjfl kjl kfjgdsad dsfsfssasadasdsadsaxvxc vc xvc x vxvc xvc xvxc vdftgdtgrdiogtrfoigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiär epsitop rtölfkglkflkjfljklfjl kfl kjfl kjl kfjgdsad Dsfsfssasadasdsadsaxvxc vc xvc xvxvc x vc xvxc vdftgdtgrdiogtrfoigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiär epsito prtölfkglkflkjfljklfjl kfl kjfl kj l kfjgdsadkjl kfjgdsad + dsfsfssasadasdsadsaxvxc vc xvc x vxvc xvc xvxc vdftgdtgrdiogtrfoigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiär epsitop rtölfkglkflkjfljklfjl kfl kjfl kjl kfjgdsad dsfsfssasadasdsadsaxvxc vc xvc x vxvc xvc xvxc vdftgdtgrdiogtrfoigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiär epsitop rtölfkglkflkjfljklfjl kfl kjfl kjl kfjgdsad dsfsfssasadasdsadsaxvxc vc xvc x vxvc xvc xvxc vdftgdtgrdiogtrfoigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiär epsitop rtölfkglkflkjfljklfjl kfl kjfl kjl kfjgdsaddsfsfs sasadasdsads axvxc vc xvc xvx vc xvc x vxc vdftgdtgrdiogtrfoigufighfgjhfjkghjjhgjkh djfhgkjfhgkjfgledkitopretiärepsitoprtölfkgl kfl kjflj klfjl kfl kjfl kjl kfjgdsad dsfsfssasadasdsadsaxvxc vc xvc x vxvc xvc xvxc vdftgdtgrdiogtrfoigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiär epsitop rtölfkglkflkjfljklfjl kfl kjfl kjl kfjgdsad dsfsfssasadasdsadsaxvxc vc xvc x vxvc xvc xvxc vdftgdtgrdiogtrfoigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiär epsitop rtölfkglkflkjfljklfjl kfl kjfl kjl kfjgdsad dsfsfssasadasdsadsaxvxc vc xvc x vxvc xvc xvxc vdftgdtgrdiogtrfoigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiär epsitop rtölfkglkflkjfljklfjl kfl kjfl kjl kfigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiärepsitoprtölfkglkfl kjflj klfj l kfl kjfl kjl kfjgdsad User statistics: power users and statistics of usage is known, still social positions are not clear dsfsfssasadasdsadsaxvxc vc xvc x vxvc xvc xvxc vdftgdtgrdiogtrfodsfsfssasadasdsadsaxvxc vc xvc xv xvc xvc xvxc vdftgdtgrdiogtrfoigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiärepsitoprtölfkglkfl kjflj klfjl kfl kjfl kj l kfjgdsad dsfsfssasadasdsadsaxvxc vc xvc x vxvc xvc xvxc vdftgdtgrdiogtrfodsfsfssasadasdsadsaxvxc vc xvc xv xvc xvc xvxc vdftgdtgrdiogtrfoigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiärepsitoprtölfkglkfl kjflj klfjl kfl kjfl kj l kfjgdsad dsfsfssasadasdsadsaxvxc vc xvc x vxvc xvc xvxc vdftgdtgrdiogtrfoigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiär epsitoprtölfkgl kfl kjflj kl fjl kfl kjfl kjl kfjgdsad dsfsfssasadasdsadsaxvxc vc xvc x vxvc xvc xvxc vdftgdtgrdiogtrfoigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiär epsitoprtölfkgl kfl kjflj kl fjl kfl kjfl kjl kfjgdsad dsfsfssasadasdsadsaxvxc vc xvc x vxvc xvc xvxc vdftgdtgrdiogtrfoigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiär epsitoprtölfkgl kfl kjflj kl fjl kfl kjfl kjl kfjgdsad dsfsfssasadasdsadsaxvxc vc xvc x vxvc xvc xvxc vdftgdtgrdiogtrfoigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiär epsitoprtölfkgl kfl kjflj kl fjl kfl kjfl kjl kfjgdsad Dsfsfssasadasdsadsaxvxc vc xvc xvxvc x vc xvxc vdftgdtgrdiogtrfoigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiär epsitoprtölfkgl kfl kjflj klfjl kfl kjfl kjl kfjgdsadkjl kfjgdsad Dsfsfssasadasdsadsaxvxc vc xvc xvxvc x vc xvxc vdftgdtgrdiogtrfoigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiär epsitoprtölfkgl kfl kjflj klfjl kfl kjfl kjl kfjgdsadkjl kfjgdsad dsfsfssasadasdsadsaxvxc vc xvc x vxvc xvc xvxc vdftgdtgrdiogtrfoigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiär epsitoprtölfkgl kfl kjflj kl fjl kfl kjfl kjl kfjgdsad dsfsfssasadasdsadsaxvxc vc xvc x vxvc xvc xvxc vdftgdtgrdiogtrfoigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiär epsitoprtölfkgl kfl kjflj kl fjl kfl kjfl kjl kfjgdsad dsfsfssasadasdsadsaxvxc vc xvc x vxvc xvc xvxc vdftgdtgrdiogtrfoigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiär epsitoprtölfkgl kfl kjflj kl fjl kfl kjfl kjl kfjgdsad dsfsfssasadasdsadsaxvxc vc xvc x vxvc xvc xvxc vdftgdtgrdiogtrfoigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiär epsitoprtölfkgl kfl kjflj kl fjl kfl kjfl kjl kfjgdsad dsfsfssasadasdsadsaxvxc vc xvc x vxvc xvc xvxc vdftgdtgrdiogtrfoigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiär epsitoprtölfkgl kfl kjflj kl fjl kfl kjfl kjl kfjgdsaddsfsfssasadasdsadsaxvxc vc xvc x vxvc xvc xvxc vdftgdtgrdiogtrfoigufighfgjhfjk dsfsfssasadasdsadsaxvxc vc xvc x vxvc xvc xvxc vdftgdtgrdiogtrfoigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiär epsitoprtölfkgl kfl kjflj kl fjl kfl kjfl kjl kfjgdsaddsfsfssasadasdsadsaxvxc vc xvc x vxvc xvc xvxc vdftgdtgrdiogtrfoigufighfgjhfjk ghjjhgjkhdjfhgkjfhgkjfgledkitopretiärepsitoprtölfkglkfl kj flj klfjl kfl kjfl kjl kfjgdsad ghjjhgjkhdjfhgkjfhgkjfgledkitopretiärepsitoprtölfkglkfl kj flj klfjl kfl kjfl kjl kfjgdsad dsfsfssasadasdsadsaxvxc vc xvc x vxvc xvc xvxc vdftgdtgrdiogtrfoigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiär epsitoprtölfkgl kfl kjflj kl fjl kfl kjfl kjl kfjgdsad dsfsfssasadasdsadsaxvxc vc xvc x vxvc xvc xvxc vdftgdtgrdiogtrfoigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiär epsitoprtölfkgl kfl kjflj kl fjl kfl kjfl kjl kfjgdsad dsfsfssasadasdsadsaxvxc vc xvc x vxvc xvc xvxc vdftgdtgrdiogtrfoigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiär epsitoprtölfkgl kfl kjflj kl fjl kfl kjfl kjl kfjgdsad dsfsfssasadasdsadsaxvxc vc xvc x vxvc xvc xvxc vdftgdtgrdiogtrfoigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiär epsitoprtölfkgl kfl kjflj kl fjl kfl kjfl kjl kfjgdsad dsfsfssasadasdsadsaxvxc vc xvc x vxvc xvc xvxc vdftgdtgrdiogtrfoigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiär epsitoprtölfkgl kfl kjflj kl fjl kfl kjfl kjl kfigufighfgjhfjkghjjhgjkhdjfhgkjfhg kjfgledkitopreti ärepsitoprtölfkgl kfl kjflj klfjl kfl kjfl kjl kfjg dsfsfssasadasdsadsaxvxc vc xvc x vxvc xvc xvxc vdftgdtgrdiogtrfoigufighfgjhfjkghjjhgjkhdjfhgkjfhgkjfgledkitopretiär epsitoprtölfkgl kfl kjflj kl fjl kfl kjfl kjl kfigufighfgjhfjkghjjhgjkhdjfhgkjfhg kjfgledkitopreti ärepsitoprtölfkgl kfl kjflj klfjl kfl kjfl kjl kfjg dsad dsad Community success model
- 8. Pilot Evaluation • Implemented mainly for early proof-of-concept. Inspired from communities like Ubuntu and services like UserVoice and GetSatisfaction • Lightweight standalone implementation • To be utilized in various TEL workshops • Target users: developers, academics and researchers • Prioritization limited to user ratings
- 9. Key objectives for pilot • Ease of contribution • Entering requirements should be a by-product of learning activities • Well integrated with their PLE/container • Integration at Widget Store level using an appropriate gadget • Ensure end-users are exposed to minimal technical information/Jargon. • Consider separation of views for developers and end-users • Provide status of existing requirements • Simple requirements rating/ranking mechanism
- 10. Implementation – Throwaway Prototype
- 11. Categorization and status indication
- 12. Identification of redundant requirements
- 13. Voting Restrictions • Prompting users to diligently prioritise requirements • They only had certain number of votes which they could use • Once their feature request is implemented/discarded the votes are returned to the user which they can again use.
- 14. Asynchronous Communications around requirements
- 15. Requirements Widget in ROLE SDK
- 16. Widget view for developers • Widget for Developers with core requirements • Various combinations can be exposed depending on need • Here widget is configured for dev-camp enabling developers to see both views across all contexts
- 17. Gadget view for learners • Widget for End-Users with context specific requirements can be integrated at container level • An integration along with Widget-Store search results will also be viable, enabling users to provide requirements if their store search does not yield desired results.
- 18. Usage during Developer Camp • Embedded in local ROLE SDK during demonstration • Participants invited to vote on existing requirements or create new ones • Useful URLs related to the Pilot: • http://www.cs.le.ac.uk/projects/ROLE/sre/ (Main site) • http://www.cs.le.ac.uk/projects/ROLE/sre/sre.xml (WidgetURL)
- 19. 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 • Lurking – 90-9-1 behaviour atypical of any community based forums
- 20. Lessons Learned • 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
- 21. Future Improvements • Ease of contribution • 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 • 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
- 22. THANK YOU © www.role-project.eu
Editor's Notes
- A community needs to be able to observe itself, to analyze and maybe even simulate its behavior, in order to evolve its rules of cooperation and to continuously identify and adapt its requirements. The above considerations originate from an operational theory of media called Transcriptivity Theory (Jäger, 2002) describing the operational semantics of medial artifacts founded on the three basic operations transcription, localization and addressing. Transcriptivity theorywas summarized in the abstract software architecture ATLAS (Architecture for Transcription, Localization, and Addressing Systems) (Jarke and Klamma, 2006). A CoP is a group of people who share a concern or a passion and who interact regularly to learn how to improve. Individual learning in a CoP is mainly based on “legitimate peripheral participation” (Lave and Wenger, 1991). Actor-network-theory (ANT) (Latour 1999), according to which no distinction is made between human and non-human actors, can be adopted. Such a non-differentiation between people and technologies intertwines actions, influences, or results of actions.
- Can now be integrated with any container for ease of contribution View separation depending on context (developer sees both infrastructure and widget requirements, users can only see requirements as per their context) Eg: SJTU users can only see requirements from their test-beds