Soo Ling Lim

StakeRare: Using Social Networks and Collaborative Filtering for Large-Scale Requirements Elicitation

Requirements elicitation is the software engineering activity in which stakeholder needs are understood. It involves identifying and prioritizing requirements-a process difficult to scale to large software projects with many stakeholders. This paper proposes StakeRare, a novel method that uses social networks and collaborative filtering to identify and prioritize requirements in large software projects. StakeRare identifies stakeholders and asks them to recommend other stakeholders and stakeholder roles, builds a social network with stakeholders as nodes and their recommendations as links, and prioritizes stakeholders using a variety of social network measures to determine their project influence. It then asks the stakeholders to rate an initial list of requirements, recommends other relevant requirements to them using collaborative filtering, and prioritizes their requirements using their ratings weighted by their project influence. StakeRare was evaluated by applying it to a software project for a 30,000-user system, and a substantial empirical study of requirements elicitation was conducted. Using the data collected from surveying and interviewing 87 stakeholders, the study demonstrated that StakeRare predicts stakeholder needs accurately and arrives at a more complete and accurately prioritized list of requirements compared to the existing method used in the project, taking only a fraction of the time.

StakeNet: using social networks to analyse the stakeholders of large-scale software projects

Many software projects fail because they overlook stakeholders or involve the wrong representatives of significant groups. Unfortunately, existing methods in stakeholder analysis are likely to omit stakeholders, and consider all stakeholders as equally influential. To identify and prioritise stakeholders, we have developed StakeNet, which consists of three main steps: identify stakeholders and ask them to recommend other stakeholders and stakeholder roles, build a social network whose nodes are stakeholders and links are recommendations, and prioritise stakeholders using a variety of social network measures. To evaluate StakeNet, we conducted one of the first empirical studies of requirements stakeholders on a software project for a 30,000-user system. Using the data collected from surveying and interviewing 68 stakeholders, we show that StakeNet identifies stakeholders and their roles with high recall, and accurately prioritises them. StakeNet uncovers a critical stakeholder role overlooked in the project, whose omission significantly impacted project success.

Investigating Country Differences in Mobile App User Behavior and Challenges for Software Engineering

Mobile applications (apps) are software developed for use on mobile devices and made available through app stores. App stores are highly competitive markets where developers need to cater to a large number of users spanning multiple countries. This work hypothesizes that there exist country differences in mobile app user behavior and conducts one of the largest surveys to date of app users across the world, in order to identify the precise nature of those differences. The survey investigated user adoption of the app store concept, app needs, and rationale for selecting or abandoning an app. We collected data from more than 15 countries, including USA, China, Japan, Germany, France, Brazil, United Kingdom, Italy, Russia, India, Canada, Spain, Australia, Mexico, and South Korea. Analysis of data provided by 4,824 participants showed significant differences in app user behaviors across countries, for example users from USA are more likely to download medical apps, users from the United Kingdom and Canada are more likely to be influenced by price, users from Japan and Australia are less likely to rate apps. Analysis of the results revealed new challenges to market-driven software engineering related to packaging requirements, feature space, quality expectations, app store dependency, price sensitivity, and ecosystem effect.

Investigating the suitability of social robots for the wellbeing of the elderly

This study aims to understand if, and how, social robots can promote wellbeing in the elderly. The existing literature suggests that social robots have the potential to improve wellbeing in the elderly, but existing robots focus more on healthcare and healthy behaviour among the elderly. This work describes a new investigation based on focus groups and home studies, in which we produced a set of requirements for social robots that reduce loneliness and improve psychological wellbeing among the elderly. The requirements were validated with the participants of our study. We anticipate that the results of this work will lead to the design of a new social robot more suited to improving wellbeing of the elderly.

Empirical evaluation of search based requirements interaction management

Context: Requirements optimization has been widely studied in the Search Based Software Engineering (SBSE) literature. However, previous approaches have not handled requirement interactions, such as the dependencies that may exist between requirements, and, or, precedence, cost- and value-based constraints. Objective: To introduce and evaluate a Multi-Objective Search Based Requirements Selection technique, using chromosome repair and to evaluate it on both synthetic and real world data sets, in order to assess its effectiveness and scalability. The paper extends and improves upon our previous conference paper on requirements interaction management. Method: The popular multi-objective evolutionary algorithm NSGA-II was used to produce baseline data for each data set in order to determine how many solutions on the Pareto front fail to meet five different requirement interaction constraints. The results for this baseline data are compared to those obtained using the archive based approach previously studied and the repair based approach introduced in this paper. Results: The repair based approach was found to produce more solutions on the Pareto front and better convergence and diversity of results than the previously studied NSGA-II and archive-based NSGA-II approaches based on Kruskal-Wallis test in most cases. The repair based approach was also found to scale almost as well as the previous approach. Conclusion: There is evidence to indicate that the repair based algorithm introduced in this paper is a suitable technique for extending previous work on requirements optimization to handle the requirement interaction constraints inherent in requirement interactions arising from dependencies, and, or, precedence, cost- and value-based constraints.

Getting RID of pain-related behaviour to improve social and self perception: A technology-based perspective

People with chronic musculoskeletal pain can experience pain-related fear of physical activity and low confidence in their own motor capabilities. These pain-related emotions and thoughts are often communicated through communicative and protective non-verbal behaviours. Studies in clinical psychology have shown that protective behaviours affect well-being not only physically and psychologically, but also socially. These behaviours appear to be used by others to appraise not just a persons physical state but also to make inferences about their personality traits, with protective pain-related behaviour more negatively evaluated than the communicative behaviour. Unfortunately, people with chronic pain may have difficulty in controlling the triggers of protective behaviour and often are not even aware they exhibit such behaviour. New sensing technology capable of detecting such behaviour or its triggers could be used to support rehabilitation in this regard. In this paper we briefly discuss the above issues and present our approach in developing a rehabilitation system.

How to be a successful app developer: lessons from the simulation of an app ecosystem

App developers are constantly competing against each other to win more downloads for their apps. With hundreds of thousands of apps in these online stores, what strategy should a developer use to be successful? Should they innovate, make many similar apps, optimise their own apps or just copy the apps of others? Looking more deeply, how does a complex app ecosystem perform when developers choose to use different strategies? This paper investigates these questions using AppEco, the first Artificial Life model of mobile application ecosystems. In AppEco, developer agents build and upload apps to the app store; user agents browse the store and download the apps. A distinguishing feature of AppEco is the explicit modelling of apps as artefacts. In this work we use AppEco to simulate Apples iOS app ecosystem and investigate common developer strategies, evaluating them in terms of downloads received, app diversity, and adoption rate.

App Epidemics: Modelling the Effects of Publicity in a Mobile App Ecosystem

In mobile app ecosystems, an app can behave like a virus. Once downloaded, it may cause its user to recommend that app to friends who then may download the app and “infect” other friends. Epidemics occur when a small number of downloads causes a snowballing effect that results in a massive number of downloads (and consequently, a rich developer). This paper presents AppEco, the first Artificial Life model of mobile application ecosystems. AppEco models the app store, app developers, apps, users, and their behaviour. We use AppEco to simulate Apple’s iOS app ecosystem and investigate common publicity strategies adopted by developers and their effects on app downloads. Specifically, we investigate three causal factors for a widespread “app infection” from epidemiology: the users’ exposure to the app, the users’ susceptibility to the app, and the infectiousness of the app.

Anticipating Change in Requirements Engineering

Requirements change is inevitable in the development and maintenance of software systems. One way to reduce the adverse impact of change is by anticipating change during requirements elicitation, so that software architecture components that are affected by the change are loosely coupled with the rest of the system. This chapter proposes Change-oriented Requirements Engineering (CoRE), a method to anticipate change by separating requirements into layers that change at relatively different rates. From the most stable to the most volatile, the layers are: patterns, functional constraints, non-functional constraints, and business policies and rules. CoRE is empirically evaluated by applying it to a large-scale software system, and then studying the requirements change from development to maintenance. Results show that CoRE accurately anticipates the relative volatility of the requirements.

Using Web 2.0 for Stakeholder Analysis: StakeSource and Its Application in Ten Industrial Projects

Software projects often fail because stakeholders are omitted. Existing stakeholder analysis methods rely on practitioners to manually identify and prioritise stakeholders, which is time consuming, especially in large projects with many stakeholders. This chapter investigates the use of Web 2.0 technologies, such as crowdsourcing and social networking, to identify and prioritise stakeholders. The investigation is based on the application of StakeSource in practice. StakeSource is a Web 2.0 tool that uses social networking and crowdsourcing techniques to identify and prioritise stakeholders. This chapter describes our experiences of and lessons learnt from applying StakeSource in ten real-world projects from six organisations in UK, Japan, Australia, and Canada, involving more than 600 stakeholders. We find that StakeSource can yield significant benefits, but its effectiveness depends on the stakeholders’ incentives to share information. In some projects, StakeSource elicited valuable stakeholder information; in other projects, the stakeholder responses were insufficient to add value. We conclude with a description of factors that influence stakeholder engagement via the use of Web 2.0 tools such as StakeSource. If collaborative tools such as StakeSource were to find a place in requirements engineering, we would need to understand what motivates stakeholders to contribute.