Open Access

Using popular social network sites to support requirements elicitation, prioritization and negotiation

  • Norbert Seyff1, 2Email author,
  • Irina Todoran2,
  • Kevin Caluser2,
  • Leif Singer3 and
  • Martin Glinz2
Journal of Internet Services and Applications20156:7

DOI: 10.1186/s13174-015-0021-9

Received: 1 July 2014

Accepted: 2 March 2015

Published: 24 April 2015

Abstract

Social networks have changed our daily life and they have the potential to significantly influence and support Requirements Engineering (RE) activities. Social network-based RE approaches will allow us to overcome limitations of traditional approaches and allow end users to play a more prominent role in RE. They are key stakeholders in many software projects. However, involving end users is challenging, particularly when they are not within organizational reach. The goal of our work is to increase end user involvement in RE. In this paper we present an approach where we harness a social network to perform RE activities such as elicitation, prioritization and negotiation. Our approach was applied in three studies where students used Facebook to actively participate in RE activities of different projects. Although there are limitations, the results show that a popular social network site can support distributed RE.

Keywords

Requirements engineering Social network sites End user involvement

1 Introduction

The involvement of stakeholders such as future system end users is a key success factor for Software Engineering (SE) in general, and for Requirements Engineering (RE) in particular [1].

Several process models are available to describe RE activities [2]. Key activities include requirements elicitation, prioritization and negotiation. Requirements elicitation is the process of seeking, capturing and consolidating requirements from available requirements sources (e.g. stakeholders) [3]. The requirements gathered should be prioritized. The priority of a requirement shows its importance in comparison to others; it also helps decide which requirements to include in a project [3,4]. Furthermore, prioritization supports requirements negotiation which focuses on conflict resolution by finding a settlement that mostly satisfies allstakeholders [5].

Some approaches foster the involvement of success-critical stakeholders (e.g. end users) in requirements elicitation, prioritization and negotiation [6]. However, these approaches do not sufficiently support non-traditional contexts such as mobile computing [7], cloud computing [8] or software ecosystems [9]. This is due to the fact that in these contexts, we need to involve a large number of heterogeneous, globally distributed and potentially anonymous stakeholders [10]. Although the underlying idea of involving success-critical stakeholders is still valid in those settings, there is a lack of suitable elicitation techniques [8] and novel RE approaches and methods are needed to give end users their own voice [11].

In order to be successful and to cope with short time-to-market periods, the methods used need to be fast, easy and inexpensive. However, most state-of-the-art RE approaches and tools are built from an RE perspective and require end users to get familiar with a particular system and procedure. We therefore envision that novel RE approaches will focus on the end user perspective.

For this, we have investigated the potential of popular social network sites (SNS) for requirements elicitation, prioritization and negotiation. Considering the number of registered users and regional popularity, we selected four candidates for our studies: Facebook, Twitter, LinkedIn and Google+. From these, Facebook [12] was chosen as the support for this research. Today, many end users are familiar with social network sites in general and Facebook in particular. By using a platform that is part of end users’ daily lives, we aim to overcome current limitations of RE tools in terms of end user acceptance and involvement.

However, from an RE perspective, this strategy can cause new problems. Popular social network sites have not been designed for RE and might therefore not support RE activities adequately. Therefore, our aim is to investigate whether and how existing functionalities of a current social network site can support RE activities. To our knowledge, these are the first exploratory studies that research the possibility of using social network sites for meeting RE needs. Our exploratory studies with students and their Facebook friends lead to qualitative data showing that Facebook provides basic capabilities to support RE activities. Moreover, our findings show the advantages and limitations of an SNS-based approach for the RE activities mentioned.

Following the EasyWinWin methodology [6], we foresee that our lightweight and end user focused RE approach has many potential applications. We particularly see its relevance within novel software paradigms such as mobile and cloud computing and software ecosystems, where end users are not within immediate reach and where the support provided by traditional methods is insufficient. For example, smartphone application developers or cloud service providers could use our approach to elicit, prioritize and negotiate stakeholder needs. In software ecosystems, our approach provides a new channel for eliciting ideas and needs as well as receiving feedback from stakeholders who are not directly reachable by product owners or development teams. Moreover, we also see its application within traditional software projects as an additional means for involving end users.

The remainder of the paper is structured as follows: In Section 2, we discuss the research goal and questions. Section 3 gives an overview on how current social software is being used within the field of RE. In Section 4, we present a generic SNS-based RE approach. Section 5 introduces candidate SNS suitable for implementing our approach. In Sections 6 to 9 we report on three exploratory studies where students and their friends applied our approach with Facebook. After revisiting the research questions and discussing threats to validity in Section 10, we conclude the paper and present potential future research directions in Section 11.

2 Research goal and questions

The goal of our research is to investigate whether and how popular social network sites have the potential to support RE activities. We identified three research questions (RQ) to define the focus of our research:

RQ 1: Can a social network site support requirements elicitation, prioritization and negotiation? If so, how can existing features be used to elicit, prioritize and negotiate end users’ requirements?

Firstly, we are interested in finding out whether existing features exhibited by a social network site such as Facebook can help gathering, prioritizing and negotiating users’ requirements. To answer this question, we set up three exploratory studies and analyse their results. Moreover, we investigate how the existing features can be utilized, i.e. how an RE activity should be designed to make good use of the SNS features.

RQ 2: What are the benefits of using a social network site approach compared to existing elicitation, prioritization and negotiation techniques?

Secondly, we identify in what ways and under which circumstance such an SNS approach is better suited than traditional RE methods. Additionally, we investigate how this approach could potentially complement existing techniques.

RQ 3: What are the challenges and limitations of using a social network site for requirements elicitation, prioritization and negotiation?

Thirdly, we analyse potential issues associated with using an SNS approach to support RE activities, including their limitations. Relying on our findings, we elaborate preliminary guidelines that can be followed when utilizing SNS for RE activities.

3 Related work: RE and social software

Requirements Engineering is a multidisciplinary field [13] that requires active communication and interaction between different stakeholders. Depending on the project, its activities may be interleaved, iterative and span across the entire software life cycle [14]. Although various RE reference process models exist [15,16], it is generally agreed upon that early RE activities include (1) requirements elicitation and (2) requirements analysis and negotiation [14]. For each of these activities, there are several sub-activities that vary between projects – e.g. identifying key stakeholders, brainstorming stakeholder interests, prioritizing ideas and negotiating them [17]. Several RE approaches and tools follow these high level models and provide step-by-step guidance and support (e.g. EasyWinWin [6,17]). However, it might be hard for an end user to understand the sequence of activities, sub-activities and their respective purpose. Our work is inspired by EasyWinWin which focuses on providing support for requirements elicitation, prioritization and negotiation.

Social network sites are an example of social software and used for connecting and communicating with others – anytime and anywhere. Boyd and Ellison [18] describe social network sites as web-based services that allow individuals to (1) maintain a public or semi-public profile within a particular system, (2) maintain a list of connected users (e.g. friends), people with whom they share a connection and (3) view and follow connections made by themselves and by other users. Social network sites usually either target a specific user group (e.g. private people, business people or even specific groups such as photographers) or support a specific task (e.g. StakeSource [19] as an example for a social network site supporting RE activities).

The idea of using social software for supporting such RE activities has been explored by both researchers and practitioners throughout the recent years. This section presents related work focusing on strengthening end user involvement in RE with the help of social software. While conducting the analysis, we identified three categories of tool support. The first represents work on dedicated RE tools that include concepts of social software.

The idea of using social tools for RE and software design is not new - it was already discussed by Conklin and Begeman in their 1988 paper on gIBIS: a hypertext tool for exploratory policy discussion. This was also meant to be used in early RE activities such as design deliberations. The tool implements the IBIS method, which was designed to solve complex design problems by taking the perspectives of the stakeholders involved [20].

More recent research focuses on identifying and prioritizing stakeholders. This is supported by StakeSource which is a lightweight web-based tool implementing the StakeNet method [19]. The work by Lim et al. is based on social network analysis as well as collaborative filtering and provides requirements engineers with a list of the key stakeholders. The method requires an initial set of already identified stakeholders who themselves identify and suggest new stakeholders (snowballing effect). In addition, StakeSource provides basic capabilities to identify, negotiate and prioritize requirements [19]. Although this approach is rather straightforward, stakeholders need to make themselves familiar with the forms that allow entering and rating requirements.

According to the authors, SoftWiki is well suited for end users not familiar with RE practices. It is a dedicated web-based tool that allows stakeholders to enter and manage requirements themselves [21]. To make the processing by requirements engineers easier later on, the tool incorporates semantic web technologies [22]. However, end users would still have to learn how to use the tool. Letting end users structure and annotate requirements with semantics can bring further challenges and create a barrier for end users participation.

In their work on WinBook, Kukreja and Boehm [23,24] explore social network functionalities to develop a new avatar of the WinWin framework [6]. Early evaluation results suggest that the toolset supports non-technical stakeholders in negotiating requirements. However, no more in depth evaluation studies have been conducted yet.

The second category we identified is work that describes the use of existing social software to support RE and also SE activities.

Early work in this field focused on comparing asynchronous text chats to face-to-face meetings for requirements negotiation [25]. The study conducted with geographically distributed students revealed that face-to-face meetings become more effective if they are preceded by text-based, asynchronous discussions. This resolved several conflicts and reduced the workload in the following physical meetings. However, the use of chats was only complementary to the physical meetings and therefore not sufficient on its own.

Researchers such as Maalej et al. [26,27] highlight the importance of end user involvement in today’s software development projects. They promote a conceptual framework which combines several existing techniques for better handling continuous user input during the elicitation phase.

A particular approach supporting elicitation and product development is presented by Hess et al. [28] who report on participatory product development in and with online communities. Their work represents an example of user-centered, community-based requirements elicitation as part of participatory design. They targeted a large population of heterogeneous and globally distributed users and facilitated the interaction by using online tools. Moreover, they demonstrate that the role of user representatives is vital when managing heterogeneity in an online community.

Apart from research, companies have started to include social media in their software development processes. Bajic and Lyons present a study on social media used by different software development companies [29]. They figured out that, in an early stage, especially small companies use social media to gather feedback from their customers. It is unclear, however, how far companies integrate these initiatives into their development processes and whether they use traditional RE approaches at all.

Companies such as UserVoice.com [30] have started to reduce barriers for involving end users in the software development process by providing a service that allows software companies to gather feedback from their customers. Other organizations already use existing social media tools, such as Facebook and Twitter [31]. It is however unclear whether the use of these tools goes beyond the purposes of marketing and public relations.

A third category of relevant research we have identified is the work that focuses on the analysis of data documented within SNS.

Currently, there are attempts to utilize users’ reviews that can be found in app stores for mobile platforms to mine requirements or extract features. For instance, Harman et al. use data mining techniques to extract feature information which is then used to analyse technical, business and customer aspects of the apps. Such approaches target large-scale, unknown and heterogeneous audiences [32].

In their research, Guzman and Maalej [33] also focus on analysing user reviews in app stores. They have developed an automated approach that supports developers in filtering, aggregating and analysing user reviews in order to conduct a fine-grained sentiment analysis.

Apart from research including or focusing on the end user perspective, there is research focusing on developers. For example, Singer et al. have investigated how developers stay current using Twitter [34]. Furthermore, researchers are starting to mine information stored in GitHub [35] to better understand how developers collaborate [36]. This research also focuses on open source software development. However, we would like to highlight that in our work we are focusing on the end user perspective, investigating how end user involvement can be strengthened in RE activities.

We conclude that there are manifold ways of using social software for RE. Dedicated RE tools based on social software allow the involvement of end users in the RE process. However, these tools might still require end user training and other additional effort (e.g. registration) before RE activities can take place. Apart from dedicated RE methods and tools, researchers and practitioners are using existing social software to support RE and SE activities. This means that instead of providing methods and tools which are fully based on using the functionality of an SNS, those functionalities are only used in part to complement existing processes. We conclude that current attempts to use existing social software tools in an RE context are still in an early stage.

4 Designing a social network site-supported RE approach for requirements elicitation, prioritization and negotiation

Following our research goal to investigate whether and how popular SNS can support RE activities, we aimed at providing a generic RE approach based on well-known social network functionalities. This approach should present RE activities from an end user perspective and require neither lengthy process guidance nor support documents. It should be usable ad hoc, anytime and anywhere to allow distributed requirements elicitation, prioritization and negotiation in an iterative manner.

Inspired by EasyWinWin, our approach is driven by a moderator, a person who has an interest in the system to be, and whose aim is to gather requirements for that system. Our solution is designed to also require minimal training for the moderator (e.g. a mobile app developer who would like to gather requirements from potential end users).

We distinguish three high-level activities and detailed steps which require the participation of the moderator, stakeholders (e.g. end users) or both. Those activities and steps can also be interpreted as requirements an SNS has to satisfy so that it is possible to apply the approach we propose.

The first activity contains required preparation activities (1). The moderator undertakes the following steps:

1.1 Set up a space for discussion: As a first step, the moderator creates a discussion space (e.g. a group) with an appropriate title for the project at hand. The moderator can decide to create an open or a private discussion space.

1.2 Provide key information about the project: The moderator provides the initial information (such as a vision statement for the project). This information should be structured and it should be possible to discuss several topics - e.g. information about the project, instructions for the participants.

The second high-level activity implements requirements elicitation, prioritization and negotiation activities (2). The following tasks are mainly performed by the participating stakeholders (e.g. end users), guided by the moderator. It should be noted that steps 2.1 through 2.4 are running simultaneously and in an iterative manner. They will not necessarily follow a strict sequence.

2.1 Invitation of participants: The moderator invites stakeholders to the group. The invitation itself might include key information about the project and purpose of the group. Depending on the project, the moderator can ask invitees to support the stakeholder identification by inviting more participants.

2.2 Participants brainstorm ideas: The moderator invites stakeholders to begin posting their ideas, needs, and concerns that can later be turned into well-defined requirements for the project.

2.3 Participants discuss ideas: As soon as ideas are posted, stakeholders can start a discussion. They can ask questions for clarification and post issues they identify regarding a certain idea. This allows the inclusion of several different stakeholder perspectives. The moderator should now engage with the participants in order to stimulate and steer the negotiation – e.g. by asking questions for further clarification.

2.4 Participants approve and prioritize ideas: Participants communicate their approval of ideas and comments in this step. It can help to guide the direction of a discussion. Furthermore, the number of approvals given for an idea or comment can highlight its importance.

The third high-level activity implements requirements analysis and follow-up (3), and is performed by the moderator:

3.1 Transcribe ideas into prioritized requirements: Stakeholder (e.g. end user) contributions may vary in quantity, quality and content. Although the moderator is available during discussions, we do not expect the process output to provide high quality requirements descriptions. As a last step, he can transcribe initial user needs into well-defined requirements. By analyzing the number of approvals per idea, the moderator can also define the priority of requirements. For this analysis we do not request explicit support from an SNS. It strongly depends on the skills and expertise of the moderator.

We conclude that in order to support the approach depicted, an SNS has to fulfill the following key requirements:

R1: The SNS must enable users to communicate ideas.

R2: The SNS must enable users to comment on ideas.

R3: The SNS must enable users to express approval for ideas and comments.

R4: The SNS must enable users to control content distribution.

R5: The SNS must provide a dedicated space for group discussions.

R6: The SNS must enable users to control group access.

5 Analyzing social network sites for RE support

Facebook, Twitter, LinkedIn [37] and Google+ [38] are prominent examples of SNS that have millions of registered users. We choose them to become our candidates for an implementation of our generic RE approach since all of them have a high number of registered and active users - according to the statistics provided by Alexa [39]. Another criterion was regional popularity – the selected SNS are popular in central Europe where we performed our exploratory studies. In order to identify the most suitable SNS, two of the authors performed an initial comparison after we had defined the key requirements for our generic SNS-supported RE approach.

We investigated which of their features would allow us to support the predefined key requirements (Table 1).
Table 1

Initial comparison of social network sites

Requirements

Facebook

Twitter

Linkedln

Google+

R1: Users communicate ideas

R2: Users comment on ideas

R3: Users express approval

R4: Control content distribution

R5: Dedicated space for group disc.

R6: Control group access

Our analysis revealed that all would allow an individual end user to express an idea – i.e. a requirement, a need (R1). Apart from Twitter, all platforms would allow users to post comments (R2). Except Twitter, all social networks allow people connected to publicly express their approval of an idea (R3). This, for example, includes like in Facebook or +1 in Google+. Twitter contains similar mechanisms (retweet, favorite), but only notifies the owner of a post. Facebook, Twitter and Google+ users are even able to restrict the access to their ideas and can therefore control the distribution of the content (R4). In LinkedIn, however, an idea is automatically shared with all connected people.

Although people could discuss an idea on a user profile, we consider a single, protected (private) and dedicated space for group discussions to be more adequate (R5). Facebook, LinkedIn and Google+ allow their users to create such a space. Those groups represent a dedicated space for discussing and communicating ideas and allow the moderator to invite stakeholders and manage user settings – e.g. define whether group members may invite additional contacts (R6).

After an initial comparison of the four social network sites, we concluded that three out of four would allow us to instantiate and apply our generic SNS-supported RE approach. Although all three candidates (i.e. Facebook, LinkedIn and Google+) would have fulfilled our initial requirements, we selected Facebook to become the platform for further investigation. Our main reasons were: (1) Facebook has over a billion users worldwide and is currently the leading social network site; and (2) the target group for our experimental studies (students and their friends) would be more likely to already have an account and be accustomed to Facebook.

6 SNS as an RE tool - exploratory studies

We performed three exploratory studies with a popular SNS (i.e. Facebook) to evaluate our SNS-supported RE approach. Our aim was to apply it in settings where moderators have limited RE knowledge and where potential end users for the systems under discussion are available to participate. We targeted projects with real-world character but which would still allow some level of control regarding the participants and the topics discussed. While designing our studies, we had in mind the metaphor of a mobile app developer who would set up a group on Facebook and act as moderator; this in order to gather requirements for a new app he is planning to realize or to elicit requirements for the evolution of an existing app. The developer could then, for example, invite existing end users of his app(s) for a discussion. Based on this metaphor we decided to perform evaluation studies within RE lectures in Switzerland and Austria, where students basically have some, but limited, RE knowledge. Those students acted as moderators and invited potential end users (other students and friends) to requirements discussions on Facebook. In Study I and Study II the evaluation was presented as an exercise to train the students’ moderation skills and to also highlight the dynamics of distributed RE for those students who were participating as end users. In Study III the evaluation was conducted to gather requirements for real-world projects the students were involved in.

All studies followed an approach where we first had a briefing session. This for example included the presentation of a description of the RE approach as depicted in Section 4. However, students were not told that they were using a novel RE approach. The briefing session was followed by the actual evaluation. In all three studies students were given a timeframe of two weeks to conduct their requirements engineering activities. However, in Study I, students would have had the option to prolong the given period. We did not interact with the students during this period. The evaluation was followed by a debriefing either directly with the students or using a questionnaire. The debriefing meetings were held to understand the benefits and limitations of the process. Facebook friends, who were invited to the discussion in some studies, were not involved in the debriefing activities. This means that in those studies the debriefing focused on the moderator who always was a student.

The studies were performed in sequential order. Therefore, the output of a preceding study supported us in defining the scope of the following study in more detail. The results of each study were analyzed by at least two authors of the paper as soon as the study was finished. One of the authors performed a qualitative analysis as described below and the first author reviewed those results for all three studies. He also checked the validity of the requirements gathered (i.e. are they relevant and useful for the implementation of the system under discussion and will they satisfy user needs?).

The third author acted as the main analyst and performed the analysis for two of the three studies. The remaining study was analyzed by the second author of the paper and results were reviewed and approved by the third author before the first author conducted a final review.

As a first step the author conducting the analysis exported all the data from Facebook to Microsoft Excel. This was done by copying and pasting the data. The following content analysis of the data gathered included the task of identifying the type of the content posted. We distinguished elicitation, negotiation, moderation and other posts. In this context, elicitation posts refer to statements communicating a new idea; negotiation posts discuss an idea; moderation posts represent statements from the moderator or other participants to facilitate the discussion; other posts refer to any other statements identified in the discussions. To better understand the nature of the posts, we applied a goal-design level metrics for categorization [40]. We distinguished the following categories: goal-level, domain- and product-level and design-level posts. We extracted the total number of distinct requirements from the end users’ posts and differentiated between functional and non-functional requirements. The non-functional were classified according to Volere [41,42].

The following sections present the three studies in detail. We discuss the different settings, the methods used, the results and the findings. For the quantitative analysis, we report on key numbers (e.g. invited stakeholders, participating stakeholders, active days, generated posts, distinct requirements). For calculating some of these numbers, we had to define metrics. For example, we defined active days as days where some group interaction took place, (e.g. stakeholders being added, ideas being posted, comments added to discussions).

7 Evaluation study I

The first study was conducted at FHNW University of Applied Sciences in Switzerland. Participants were second term iCompetence Bachelor students. The iCompetence curriculum includes design and management oriented subjects in addition to computer science courses. In their first term, the students get an overview on software engineering and programming. At this time they are typically in their early twenties. In contrast to other computer science studies, the students of iCompetence include a large number of female students (typically more than 50%).

7.1 Method

The study was presented as an exercise within the RE course (taught by the first author). This course gives an introduction to Requirements Engineering and discusses topics similar to the content requested by the IREB CPRE certification schema [43]. The goal of the exercise from the students’ perspective was to train their moderation skills and to give them the chance to experience distributed RE with stakeholders. We made clear that the exercise would not be graded. In general, students were familiar with Facebook and also used it to stay in touch with their friends and colleagues.

The evaluation was in three parts: briefing, evaluation and debriefing. During the briefing, the students were informed of the purpose of the exercise and the task they were about to perform. We presented the process depicted in Section 4 and asked the students to think of a software-intensive system that they would like to gather requirements for (e.g. the fridge of the future, a personal finance manager). For each group a moderator was chosen; he invited Facebook friends (people who could be potential end users or who have a general interest in the topic) to discuss the topic in a Facebook group. During the evaluation, we did not contact students to give advice. In this first study we suggested a timeframe of two weeks to conduct the experiment but, as we were not aware of the dynamics of our RE approach, we did not strictly limit this timeframe. We told them to start immediately and to inform us when the group discussions had stopped, which in all the cases was within the two weeks timeframe we suggested. In the debriefing, we discussed the results with the students and asked them to fill out an online questionnaire on how they experienced requirements elicitation, prioritization and negotiation using Facebook. After the debriefing meetings, we accessed the group discussions and started to analyze the students’ contributions.

7.2 Results

In total, 17 students and 74 external persons were involved in this study discussing requirements within 8 different Facebook groups (see Table 2). The students came up with innovative ideas for potential software systems. Those ideas were focusing on novel systems and also on the evolution of existing systems.
Table 2

Study I - Results

 

Gr 1

Gr 2

Gr 3

Gr 4

Gr 5

Gr 6

Gr 7

Gr 8

Avg

Invited people

37

17

27

17

24

18

23

21

23

Contributing people

12

4

11

4

7

5

6

8

7.1

Active days

4

4

4

2

4

5

7

4

4.3

Total posts

39

10

28

10

24

12

33

18

21.8

% Elicitation posts

54

90

79

40

75

100

76

61

71.9

% Negotiation posts

31

10

21

60

25

0

24

39

26.3

% Moderation posts

13

0

0

0

0

0

0

0

1.6

% Other posts

3

0

0

0

0

0

0

0

0.4

Distinct requirements

22

10

22

8

21

13

23

16

16.9

% Functional req.

82

90

73

75

90

69

83

100

82.9

% Non-functional req.

18

10

27

25

10

31

17

0

17.1

Likes

12

4

33

4

42

5

9

10

14.9

Group 1, for example, discussed requirements for a mobile app which supports healthy cooking by providing adequate recipes. Students discussed requirements such as that the app should know about the allergies of its user. Group 2 investigated how the agenda planner of the future should look like. They envisioned a ubiquitous system and requested, for example, an agenda available also when driving a car and that the car should present the agenda on the windscreen. Group 3 focused on the fridge of the future and discussed requirements such as the automatic generation of shopping lists. Group 4 elaborated how media could be consumed in the future and were, for example, requesting to replace remote controls with alternative solutions. Group 5 investigated the functionality of future SNS such as Facebook. For example, they suggested the SNS should be able to provide more information on the character of a person by analysing available content. Group 6 was looking for requirements for an app which should support their studies. For example, they discussed the option to get information about students in the same courses. Group 7 caused quite some discussion as the goal was to provide an app which would support someone who would like to become a dropout (i.e. a hermit). Requirements included guidelines for building shelters and huts, also a function which would warn the hermit of poisonous food (e.g. mushrooms). Group 8 discussed requirements for a personal finance manager app. Requirements included that the app automatically tracks the money spent on certain goods (e.g. clothes).

As some students participated in several groups, the eight Facebook groups considered in this analysis contained a total of 184 stakeholders. However, on average only 31% responded positively – meaning that 57 stakeholders joined the groups and actively contributed to the Facebook discussions (e.g. by posting comments and using likes). Therefore, the average of Facebook friends involved in each group was about seven members, with a minimum of four and a maximum of 11.

On average, the groups were active for 4.3 days. While the shortest discussion lasted only for two days, the maximum was seven days. Figure 1 aggregates the eight different groups of Study I and highlights the distribution of the different kinds of posts over time.
Figure 1

Aggregate values of Study I over time.

The 57 contributing stakeholders created 174 posts, thus generating an average of 3.1 posts per participant. There were no major differences among the eight groups (Table 2).

For the qualitative analysis, we categorized posts by the type of content they represented (Table 2). A very high number (71.9%) were elicitation posts discussing new ideas. 26.3% were negotiation posts whereas the moderation and other posts were rather rare (1.6% and 0.4% respectively).

We also analyzed the elicitation posts regarding the level of abstraction of needs posted [40]. The most numerous posts could be aligned with the domain and product-level requirements category (96%), with only 1.9% discussing goals and 2.4% implementation details.

We analyzed the number of likes in order to get an idea on the priority of the needs posted. On average, a participant used the like functionality 2.1 times. However, the use of likes varied significantly between the groups (see Table 2).

An analysis of the posts allowed us to extract 135 distinct requirements. We identified duplicates and overlaps which revealed that, on average, each of the eight groups gathered 16.9 requirements resulting in 2.4 distinct requirements per active participant. The majority of the participants posted ideas that led to functional requirements (82.9%). The 23 non-functional requirements collected referred mostly to look and feel needs (56.5%), followed by usability requirements (17.4%), performance (8.7%), environmental (8.7%), security (4.4%) and cultural requirements (4.3%).

7.3 Findings

This study investigated whether and how end users were able to participate in an SNS-supported RE approach and whether students with limited RE knowledge were able to facilitate the approach. The main findings of this study are highlighted below:

1.1 End users were able to follow the process and communicated their needs: As shown by the results, following the approach proposed and without training, end users were able to express their needs and discuss ideas on Facebook. By analyzing the ideas and needs communicated by end users, we were able to identify a high number of requirements. For example, the group discussing needs for the Fridge of the Future mentioned: “The fridge suggests recipes that take into account the current content of the fridge”.

1.2 Moderation was insufficient: Although moderators were present, they did not fully play their role. They also got involved in elicitation and negotiation activities (e.g. posted new ideas). We could only identify dedicated moderation posts in one group (see Table 2). One main reason might be the students’ limited RE knowledge and moderation experience.

1.3 Most of the content was created within the first days: In this study, all moderators mostly invited stakeholders only at the beginning of the discussion. An analysis of the group discussions revealed that most content was created after participants were invited. This suggests that participants are only active in the group discussion for a limited amount of time.

1.4 Prioritization results were insufficient: Some groups hardly used the like functionality (see Table 2). The likes provided by the participants were not sufficient to build a prioritized list of requirements. However, we were able to identify some favorites in most groups.

1.5 No snowball effect: We had expected some “friends of friends” to join the discussion. In half the groups, none of the friends invited took part in the stakeholder identification. In the other groups, some participants invited friends. However, there was no real snowball effect, especially as the contribution of “friends of friends” did not even result in one single requirement.

8 Evaluation study II

The second study was conducted at the University of Zurich in Switzerland. The participants were seven computer science graduate students. All of them had successfully completed an undergraduate course on RE and some of them already had industrial experience.

8.1 Method

The study was presented as an exercise in an advanced course on RE (taught by the fifth author) where selected RE topics are discussed with students. Again, this exercise had no impact on the students’ grades. As in the first study, the evaluation was structured into briefing, evaluation and debriefing phases. In the briefing session, the students were advised to work with Facebook and invite friends – but not fellow students – in order to train their moderation skills and experience requirements elicitation and negotiation with stakeholders. We further told them not to invite all friends at once and to ask their friends to additionally invite other friends who might be interested in the topic. Furthermore, we asked them to explicitly invite the participants to use the like functionality as soon as the discussion had produced stable needs. This time, we defined upfront two discussion topics we knew all participants would be familiar with – the Fridge of the Future (FoF) and the Smartphone of the Future (SoF). While four student moderators chose the first topic, the remaining three wanted to discuss needs regarding the SoF.

As several groups were discussing the same topic, we asked the students to consolidate and aggregate their results after the individual discussions. Furthermore, they were advised to invite all participating discussants for a final prioritization using likes. As the group of students also included one of the authors of this paper, we chose to exclude his group when we presented the analysis of the results. During the exercise, we had no contact with the students and no access to their groups. We limited the timeframe of the exercise to two weeks and told the students to start immediately. We conducted a debriefing meeting to explore the students’ experiences after the exercise and requested access to their groups for further analysis of the results.

8.2 Results

The six moderators invited a total of 73 friends, 38.4% became active members of the groups (28 friends). In the smallest group, there were two active participants while the largest group had seven contributors. On average, the participation was 4.7 friends per group. Groups were active for an average of four days – the longest discussion lasted six days while the shortest took two days (Table 3). The six groups generated a total of 131 posts with 78 posts originating from the FoF groups and 53 from the SoF groups. The result is an average 6.5 and 3.3 posts respectively per contributor. 18.7% of the posts in the three FoF groups were elicitation posts. 29.7% of the posts focused on negotiation, 46% on moderation and 5.6% were other posts. In the SoF groups we identified 48.7% elicitation, 20.7% negotiation, 26.6% moderation and 4% other posts. For example, in their posts, participants were asking for longer battery run times (elicitation post). The moderator requested a more detailed discussion (moderation post) and other participants started a negotiation. One participant requested that the battery of the smartphone of the future should at least last for 16 hours, while another participant’s vision included a smartphone which would not run out of battery at all by using novel energy sources such as solar energy.
Table 3

Study II - Results

 

SoF1

SoF2

SoF3

Avg SoF

FoF1

FoF2

FoF3

Avg FoF

Author

Invited people

8

6

13

9.0

32

9

5

15.3

19

Contributing people

6

5

5

5.3

7

2

3

4.0

11.0

Active days

5

4

4

4.3

6

2

3

3.7

8.0

Total posts

17

12

24

17.7

47

18

13

26.0

168.0

% Elicitation posts

70

42

34

48.7

19

6

31

18.7

26.0

% Negotiation posts

12

17

33

20.7

28

38

23

29.7

44.0

% Moderation posts

18

33

29

26.6

36

56

46

46.0

8.0

% Other posts

0

8

4

4.0

17

0

0

5.6

21.0

Distinct Requirements

13

7

14

11.3

34

14

15

21.0

80.0

 

Consolidated req. SoF: 26

Consolidated req. FoF: 48

 

% Functional req.

46

29

36

36.8

74

79

80

77.4

90.0

% Non-functional req.

54

71

64

63.2

26

21

20

22.6

10.0

Likes individual groups

8

2

8

6.0

2

6

0

2.7

38.0

Likes consolidated

38

29

22

29.7

13

26

24

21.0

98.0

We analyzed the posts’ abstraction level. Regarding the FoF, most posts referred to domain- and product-level details (77.3%). The remainder discussed design-level details (21%) and goals (1.7%). For the SoF, 17.6% of the posts discussed goals, 55% domain- and product-level requirements and 27.4% design-level details. These posts led to a total of 63 (FoF) and 34 (SoF) requirements. While the FoF groups mainly gathered functional requirements (77.4%), the SoF groups found more non-functional requirements (63.2%). The 35 non-functional requirements (NFR) mostly referred to needs regarding look and feel (40% FoF, 50% SoF) and usability (40% FoF, 30% SoF), but also performance (13.3% FoF, 20% SoF) and environmental issues (6.7% FoF, 0% SoF). For example, participants requested that the SoF should be no thicker than 5.0 mm.

After the individual group discussions, we consolidated the requirements gathered. The moderators identified overlaps regarding requirements among the different groups. 11 duplicates could be found within the FoF topic and 3 within the SoF topic. For example, all groups discussing the FoF highlighted the need to be informed when the food is approaching its expiration date. After the moderators entered the transcribed requirements in a new Facebook group, participants were invited to prioritize. 88% of the participants who had contributed to the individual group discussions also participated in this phase. They used the like functionality 152 times (63 for FoF, 89 for SoF) giving an average of 5.6 likes per contributing participant and 2.1 likes per requirement. The highest rated requirements were liked eight times while the lowest rated requirements received no likes at all.

We also analyzed the results of the author’s group (see Table 3). This group managed to gather 80 requirements, 13 of which could also be found in the other FoF groups. The number of requirements per contributing participant was considerably higher than the average of the other groups in Study II (7.3 compared to 3.5).

8.3 Findings

2.1 No prerequisites required for participants: The result of Study II shows that it is not necessary for a participant to have RE knowledge in order to take part in the proposed SNS-based RE approach. We discussed who students invited to the discussions in debriefing meetings. This revealed that the friends invited had various backgrounds, mostly unrelated to computer science. All of them were familiar with the topic under discussion and had a Facebook account and Facebook experience prior to the discussion. However, we did not request any more demographic data on the friends invited, this was for privacy reasons.

2.2 Factors improving success: The group of the author and FoF1 produced better results in terms of distinct requirements gathered. Analyzing the groups in more detail, we could identify three possible reasons: (1) High motivation of the moderators resulting in intensive care of the participants, (2) using friendly, lauding, and sometimes funny posts to engage people in discussions and stimulate creativity and, (3) continuously inviting new participants to keep the discussions alive over a longer period of time.

2.3 Consolidation and prioritization: Although participants were not explicitly asked to use likes within the individual group discussions, several likes were generated (see Table 3). In Study II, the moderators provided consolidated requirements for each topic and invited participants to like them. This resulted in a prioritized list of requirements.

2.4 Again, no snowball effect: Although in several groups the moderators actively asked participants to invite their friends, no snowball effect occurred. One single friend of a friend joined the group, which cannot be seen as a snowball effect.

2.5 Friendship and interests made friends participate: Debriefing meetings revealed that many friends participated in order to support their friend – the moderator. Furthermore, the friends who contributed, because they were generally interested in the topic, had a sudden brilliant idea they wanted to share or they participated out of curiosity.

2.6 Knowledge and skills: Although the students adopted the role of moderator more strictly than in the first study – in terms of more moderation posts – this did not result in more requirements (16.9 in Study I vs. 16.2 in Study II on average). However, the number of requirements per contributing participant increased from 2.4 in the first study to 3.5 in the second study.

9 Evaluation study III

The third study was conducted at FH Hagenberg, a University of Applied Sciences in Austria. Second term mobile computing students who were involved in projects with industrial partners had to identify needs for their projects. We wanted to investigate whether the fact that participants have to build the systems under discussion had an effect on the outcome. The students had basic software engineering skills but had not attended an RE course before.

9.1 Method

The study was presented as an exercise within their RE course (taught by the first author). This course gives an introduction to RE and is aligned with the content requested by the IREB CPRE certification schema. In the briefing meeting, we discussed the SNS-supported RE process with the students and advised them to invite stakeholders – friends or fellow students – who were potential end users and likely to provide requirements for their projects. Furthermore, we gave the same instructions as in Study II: ask friends to invite friends, consolidate the results of group discussions and then explicitly ask for likes for requirements prioritization. After the evaluation, we requested that the students answer an online questionnaire and we accessed their Facebook groups for further analysis.

9.2 Results

In total, 18 students and 81 external persons (friends) were involved in this study. In our study we had nine groups gathering requirements for software systems (mostly apps) they were about to develop. The customer for those apps was either from industry or an internal customer (e.g. professor) of the applied university. One additional group, where students were not involved in a particular project, was asked to gather requirements for the Smartphone of the Future (SoF). The results of this group were not considered in the later evaluation because of this different setting.

The nine groups working on real-world software projects had to gather requirements for different systems that did not exist. This means no group was discussing requirements regarding the evolution of an existing system. For example, Group 1 had to develop an app which would allow its users to control personal expenses. Group 2 had a more technical topic and was focusing on programmers as end users. Their goal was to develop an OpenGL image shader. The aim of group 3 was to build an app capable of counting the user’s steps while Group 4 was working on an app which would provide the optimal push-up training for its users. Group 5 was to provide an app supporting a yearly soccer tournament. In contrast, Group 6 with their “City Detective” app had the idea to develop an app for tourists where they would play the role of detectives in order to visit important sights of a city. Group 7 was working on an app supporting the local paramedic group. Group 8 had to provide an app to manage a user’s sticker collection and Group 9 was working on a friends finder app.

As some students participated in several groups, the nine Facebook groups considered in this analysis contained a total of 134 stakeholders. In total, 59 became active group members (41.2%). While 64% of the participants were fellow students, 36% were usually other Facebook friends. The smallest group had two active participants while the largest had 11. On average, 6.6 participants were engaged in a group discussion.

The groups were active for an average of 7.2 days. While the shortest discussion lasted three days, the longest took ten days. In total, the 59 participants created 290 posts. An average of 4.9 posts was generated per contributing participant (see Table 4).
Table 4

Study III - Results

 

Gr1

Gr2

Gr3

Gr4

Gr5

Gr6

Gr7

Gr8

Gr9

Avg

SoF

Invited people

33

7

21

12

28

19

8

8

7

15.9

6

Contributing people

10

5

4

7

11

7

7

2

6

6.6

3

Active days

5

5

8

9

10

9

10

6

3

7.2

6

Total posts

23

34

28

39

43

44

32

22

25

32.2

16

% Elicitation posts

35

53

21

23

76

34

41

36

56

41.7

25

% Negotiation posts

22

29

50

56

19

50

31

32

32

35.7

19

% Moderation posts

43

18

21

21

5

16

25

32

12

21.4

50

% Other posts

0

0

8

0

0

0

3

0

0

1.2

6

Distinct requirements

14

24

24

22

31

36

25

12

15

22.6

11

% Functional req.

79

63

50

73

77

86

72

92

87

75.3

45

% Non-functional req.

21

38

50

27

23

14

28

8

13

24.7

55

Likes individual groups

39

36

3

10

34

4

0

14

5

16.1

1

Likes consolidated

-

29

78

47

-

83

37

27

22

46.1

20

Again, we categorized the posts by type of content represented. We identified an average of 41.7% elicitation posts, 35.7% negotiation posts, 21.4% moderation and 1.2% other posts. Only 2.2% of the posts reflected end user goals. Around 85.6% were assigned to the domain- and product-level category. Around 12.2% discussed design-level issues.

We were able to define 203 distinct requirements. On average, each of the nine groups gathered 22.6 requirements resulting in 3.44 distinct requirements per active participant. The majority of the requirements was functional (75.3%). The 52 NFR included requirements regarding usability (19.2%), look and feel (28.9%), performance (13.5%), operation and environment (34.6%), security (1.9%) and legal (1.9%).

After the moderators consolidated the group discussions, they explicitly asked participants for likes. Without considering Group 1 and Group 5 who did not perform this task (see Table 4), the number of likes was 323 in total. On average, a participant used the like functionality seven times.

9.3 Findings

3.1 A motivated moderator is a success factor: The fact that students had to realize the system under discussion might have been a key motivational factor. Although the students in this study had limited RE skills (similar to the students in Study I), they were engaged moderators. This is reflected in the high number of moderation posts and the high quality of the posts. The data suggests that the students really wanted to know what end users would expect from the system to be built. This might also be reflected by the high percentage of posts referring to the design-level and the high number of moderators’ posts asking for clarification. The students’ high motivation might have caused the high number of requirements identified. In particular, the average number of distinct requirements gathered for industrial projects in Study III (22.6) was significantly higher than the number of requirements describing the Smartphone of the Future in Study III (11).

3.2 Students were satisfied with the results: Besides our analysis, we asked for their opinion on the results. For 81% of them, the results were satisfying. Furthermore, 68% stated that the use of Facebook to support requirements elicitation and negotiation was a good idea. However, the students also mentioned the limitations of Facebook, e.g. using like for prioritization is not precise enough and it is hard to keep sight of the overview in Facebook discussions.

3.3 Sense of duty and interest made students participate: The questionnaire revealed several reasons given by students for participating in the discussions. One main reason was that it was an exercise within a lecture and their participation was expected. Another reason was their interest in the topic and they wanted to be part of the discussion.

3.4 Minor differences between friends and fellow students: Analyzing the results, again, we could not identify any difference in the results they produced. However, we did identify issues related to the opportunity to participate. While 58.9% of the fellow students invited actually participated, on average only 27.2% of the friends invited joined the discussions.

3.5 Requirements prioritization worked: Moderators did not explicitly ask participants for likes before they consolidated the needs. Nevertheless, three groups gathered more than 30 likes each. This allowed for a prioritized list of requirements. Participants from other groups completely ignored this opportunity (Table 4). However, asking for likes on the consolidated requirements led to a sufficient number of likes for all the groups to come up with a prioritized list of requirements.

3.6 The discrepancy of the Smartphone group: In Study III, one group was not involved in an industrial project and discussed the topic Smartphone of the Future. Analyzing the requirements, we identified more non-functional requirements (55%). This pattern also appears in the Study II Smartphone Groups but it is different from all the other groups in our three studies. We cannot give a clear explanation but we have a hypothesis: identifying requirements for the Smartphone of the Future is hard for the average person. The features of smartphones were extended significantly in the last years. People are overwhelmed by new functionalities and might already be satisfied with the current capabilities of their smartphones. However, they might want an improved quality as shown by the high number of non-functional requirements.

10 Research questions revisited and threats to validity

We sought to answer the three research questions from the standpoint of our conceptual solution and the findings of the studies conducted. The empirical evidence we collected allows us to clearly identify trends. However, given the exploratory nature of the studies, we cannot present any statistically significant results.

10.1 RQ 1: Can a social network site support requirements elicitation, prioritization and negotiation? If so, how can existing features be used to elicit, prioritize and negotiate end users’ requirements?

The findings of all three studies reveal that existing features of Facebook, e.g. the possibility to build dedicated groups, comment on or like posts, support RE activities such as requirements elicitation, prioritization and negotiation. Generally, end users were able to follow the process, express their needs, provide input to ongoing discussions (Finding 1.1) and prioritize requirements (Finding 3.5). They used the commenting functionality to mention what they would want the system or product to be, and the liking feature for prioritizing their needs. For these tasks, no prerequisites were required of the participants (Finding 2.1) since they were already familiar with Facebook, the chosen social network site. Moreover, the students participating in Study III, who also had to develop the system themselves, were satisfied with the needs elicited (Finding 3.2) and considered them to be valid requirements (i.e. relevant and useful for their future implementation). For all studies the first author of this paper investigated the validity of the requirements and came to the conclusion that the involvement of several stakeholders discussing their needs leads to requirements that are agreed and useful for the implementation of the system under discussion. However, as in Study I and II the output of the discussion was not used for actual system development, we do not know which of them would have actually been implemented. Also for Study III we do not know which of the requirements discussed were actually implemented.

Using an SNS-based RE approach in real-world settings could increase end user involvement in RE and support projects with a list of end user needs. This should be seen as an initial vision and not as an exhaustive list of validated requirements. As expected, the approach did not provide well-defined requirements but rather end user needs which could then be turned into requirements. The output obtained with our approach does not in any way exclude the usage of other existing elicitation and prioritization methods but rather complements them.

10.2 RQ 2: What are the benefits of using a social network site approach compared to existing elicitation, prioritization and negotiation techniques?

With the emergence of cloud systems and the growing development and popularity of smartphone and tablet applications, understanding the needs coming from geographically distributed, heterogeneous and often unknown potential users becomes increasingly challenging [8]. Therefore, there seems to be a need for RE methods that can be used in these contexts. Our social network site approach supports the gathering of needs from such audiences without adding any learning overhead to users, i.e. no prerequisites are required from the participants (Finding 2.1), given the assumption that the large majority is used to the Facebook platform. Moreover, according to our findings, the consolidation and prioritization of needs can be supported on a large scale (Finding 2.3) and the social aspect plays an important role: friendship and common interests are significant incentives for people to participate in elicitation activities (Finding 2.5). These features of our approach differ from traditional RE methods such as interviews or workshops and stem from its distinct nature: it is based on an SNS end users are already familiar with. Therefore, it can be integrated in the overall RE process to supplement existing techniques when working in contexts like the ones mentioned above. Furthermore, applying our approach within a social network adds a unique side to the RE process: new stakeholders get involved because their friends are already taking part thus embedding the participation in their relationship. This characteristic is virtually never supported by traditional methods.

10.3 RQ 3: What are the challenges and limitations of using a social network site for requirements elicitation, prioritization and negotiation?

Naturally, there is no single general purpose RE technique. As explained under RQ2, our approach is best suited for particular contexts and should generally be used in conjunction with other existing methods. One of its limitations is that the number of needs elicited, prioritized and negotiated can overly depend on moderator’s abilities and motivation (Finding 1.2). As a result, in Study I, the prioritization results were insufficient (Finding 1.4). Therefore, special care should be taken when choosing and potentially training the moderator. For instance, when the Study III moderator was highly motivated, the results obtained were satisfactory for the participants questioned (Finding 3.2). Additionally, generating a snowball effect can be challenging (Findings 1.5 and 2.4). We did hope to see this effect, which could have led to more stakeholders discussing the system under investigation, but we do not consider its occurrence to be a prerequisite for successful SNS-based RE.

The approach we propose is inspired by the EasyWinWin methodology [6]. As recommended by EasyWinWin, it uses brainstorming to elicit requirements. Brainstorming is a widely recognized requirements elicitation technique and is described in e.g. [44]. Our approach uses Facebook posts to bring brainstorming about. Facebook likes allow the communication of approval and support requirements prioritization. Although stakeholders can prioritize requirements, this approach does not allow them to communicate a certain degree of approval which is supported by state-of-the-art prioritization approaches [4]. Comments to posts support requirements negotiation. By using comments, stakeholders can discuss issues regarding a requirement posted in a way similar to the one proposed by EasyWinWin. However, the content of a Facebook comment cannot be defined in more detail. This means it is not possible for the stakeholders to immediately grasp the purpose of the post (e.g. to see whether it is an issue or an option). Stakeholders have to keep in mind the structure of a discussion while more elaborate negotiation tools provide this kind of support (e.g. by highlighting the WinWin tree) [45].

As far as the guidelines that can be followed when utilizing SNS for early RE activities are concerned, the main lessons (L) we learned are the following:

L1: Moderators play an important role in steering discussions and should be carefully chosen. Evidence: Findings 2.2, 2.6 and 3.1.

L2: High inner motivation of participants leads to high numbers of generated and prioritized needs. Evidence: Findings 3.1 and 3.3.

L3: The social aspect is a factor contributing to success: friendships, personal relations and interests increase the participation rate. Evidence: Finding 2.5.

L4: The moderator should, on a regular basis, invite participants to have continuous contributions. Evidence: Findings 1.3 and 2.2.

L5: Friendly and funny posts stimulate discussions and creativity and should therefore be encouraged. Evidence: Finding 2.2.

These findings and lessons learned hold for Facebook, the SNS we used as support for our study. We expect that similar results could be obtained when using other social network sites, as long as the necessary features for our approach are present (see Section 4). However, when replicating this study in other contexts, users’ interaction with the SNS should also be considered. For example, whereas LinkedIn may provide rather similar features that could support the method introduced here, LinkedIn users tend to log-in and check their network activity more rarely than Facebook users. This could potentially lead to less input from users or to longer periods of waiting for gathering needs and requirements. We cannot draw any objective conclusions in this direction and further studies are needed to find out to what extent and how other SNS can be used successfully to support our approach.

10.4 Threats to validity

In our studies, we asked RE students to become the moderators of Facebook groups. In two of the three studies the students might have had a limited interest in the exercise. Only in Study III did the students have a stake in the outcome of the Facebook discussion as the results would contribute to their projects.

The studies heavily relied on the participation of RE students and friends of moderators. Although debriefing meetings suggest that participating friends had diverse backgrounds, we consider the lack of a broader audience in our studies a threat to construct validity.

We focused on a setup that would reflect real-world settings in an uncontrolled environment such as the one provided by Facebook. For example, the moderator students in Study III can be compared to real-world app developers asking their customers – who might include their friends – for new ideas and comments on a planned app. However, several contextual issues – e.g. presenting the study in the form of an (ungraded) exercise and assigning predefined topics – might have had an influence on the results. These issues are threats to the internal validity.

The results of the three studies do not allow us to make statistically significant claims, which is a threat to conclusion validity. However, students and friends were able to identify relevant requirements in all the three studies. This allows us to draw conclusions on the feasibility of the approach we presented.

In the three studies the authors focused on a setting where stakeholders were students and therefore motivated to participate. In real-world settings we need to identify other ways to motivate potential contributors. Only one popular social network was considered within our initial studies. The profile, background, motivation and behaviour of users might be different in other social networks. This can be seen as a threat to external validity.

11 Contribution and future work

The work presented in this paper investigates whether and how popular social network sites (i.e. Facebook) can support and allow end users to participate in RE activities such as elicitation, prioritization and negotiation. Inspired by EasyWinWin we have developed a generic SNS-based RE approach. We foresee that such approaches will increase end user participation in RE and allow geographically distributed end users to communicate their needs in an asynchronous way. Our three exploratory studies reveal that potential end users and moderators with limited RE knowledge are able to identify needs for the system under investigation.

We would like to stress that the approach presented does not necessarily provide well-specified requirements but rather reveals end user needs. However, we envision that SNS-supported RE approaches will become additional channels for RE. Therefore, they will complement traditional RE methods and tools and could potentially also support projects with limited RE budgets (e.g. mobile app development). Instead of highly skilled requirements engineers being trained to apply complex RE approaches and tools, the moderator within the SNS-supported RE approach presented could be a person who only has limited RE knowledge.

Further work is needed to answer open questions and outline the scope, capabilities and limitations of such a lightweight approach.

Better understanding risks and issues: This work focused on feasibility. However, future work will also need to clearly identify issues regarding SNS-supported approaches. This, for example, includes issues regarding participation (e.g. privacy issues) and tool-support (e.g. limited prioritization capabilities).

Evaluation of other suitable SNS: As discussed in Section 5, we know that SNS other than Facebook would allow researchers and practitioners to instantiate our generic SNS-based RE approach. Although our exploratory studies have shown that the approach works with Facebook, we cannot be certain if and how the approach would actually work with other SNS. For example, in LinkedIn, members maintain contacts on a more professional level which might have an influence on the results. Further studies are needed to investigate this issue. Moreover, our main aim was to investigate how an SNS-based RE approach could be used in practice and we see the chosen SNS as a support for leveraging our idea.

Evaluation in real-world projects: Apart from Study III, the studies presented focus on exercise projects rather than real-word industrial projects. Further evaluations will target the application of our approach in industrial settings. We are currently discussing the option to use our approach within a company developing mobile apps.

Exploring the motivation of end users: We would like to better understand the motivation of end users and have therefore started collaborating with the Department of Psychology at the University of Zurich. The degree of end user commitment may vary within projects. In some projects, it might be the duty of end users to participate in requirements elicitation, prioritization and negotiation activities. Other end users might draw motivation from different sources (e.g. interest in the topic, supporting a friend, curiosity). Better understanding the motivation of end users will support us in defining more stable and predictable approaches.

Declarations

Acknowledgements

This research is partly funded by the Swiss National Science Foundation (project number 200021_150142). We are grateful to all participants contributing to the presented research. Furthermore, we would like to thank Simone Schoch, Anne Koziolek, Olga Liskin, Dustin Wüest and Noële Renard for feedback and input.

Authors’ Affiliations

(1)
University of Applied Sciences and Arts Northwestern Switzerland
(2)
University of Zurich
(3)
University of Victoria

References

  1. Kujala S, Kauppinen M, Lehtola L, Kojo T (2005) The role of user involvement in requirements quality and project success In: Proceedings of the International Requirements Engineering Conference, 75–84.. IEEE, Piscataway, NJ, USA.Google Scholar
  2. Aurum A, Wohlin C (2005) Requirements engineering: Setting the context. In: Aurum A Wohlin C (eds)Engineering and Managing Software Requirements, 1–15.. Springer, Secaucus, NJ, USA.View ArticleGoogle Scholar
  3. Glinz M (2014) A Glossary of Requirements Engineering Terminology. Version 1.6. http://www.ireb.org/fileadmin/IREB/Download/Homepage\%20Downloads/IREB_CPRE_Glossary_16.pdf. Accessed 2014-12-23.
  4. Berander P, Andrews A (2005) Requirements prioritization. In: Aurum A Wohlin C (eds)Engineering and Managing Software Requirements, 69–94.. Springer, Secaucus, NJ, USA.View ArticleGoogle Scholar
  5. Easterbrook S (1991) Handling conflict between domain descriptions with computer-supported negotiation. Knowl Acquis 3: 255–289.View ArticleGoogle Scholar
  6. Boehm B, Gruenbacher P, Briggs R (2001) Developing groupware for requirements negotiation: Lessons learned. IEEE Soft 18(3): 46–55.View ArticleGoogle Scholar
  7. Seyff N, Ollmann G, Bortenschlager M (2014) Appecho: A user-driven, in situ feedback approach for mobile platforms and applications In: Proceedings of the 1st International Conference on Mobile Software Engineering and Systems. MOBILESoft 2014, 99–108.. ACM, New York, NY, USA.View ArticleGoogle Scholar
  8. Todoran I, Seyff N, Glinz M (2013) How cloud providers elicit consumer requirements: An exploratory study of nineteen companies In: Proceedings IEEE International Requirements Engineering Conference (RE), 105–114.. IEEE, Piscataway, NJ, USA.Google Scholar
  9. Dittrich Y (2014) Software engineering beyond the project – sustaining software ecosystems. Inf Softw Technol 56(11): 1436–1456.View ArticleGoogle Scholar
  10. Lloyd WJ, Rosson MB, Arthur JD (2002) Effectiveness of elicitation techniques in distributed requirements engineering In: Proceedings IEEE Joint International Conference on Requirements Engineering, 311–318.. IEEE, Piscataway, NJ, USA.View ArticleGoogle Scholar
  11. Seyff N, Graf F, Maiden N (2010) Using mobile RE tools to give end-users their own voice In: Proceedings IEEE International Requirements Engineering Conference (RE), 37–46.. IEEE, Piscataway, NJ, USA.Google Scholar
  12. Facebook. https://www.facebook.com. Accessed Dec 2014.
  13. Nuseibeh B, Easterbrook S (2000) Requirements engineering: a roadmap In: Proceedings of the Conference on The Future of Software Engineering, 35–46.. ACM, New York, NY, USA.Google Scholar
  14. Kotonya G, Sommerville I (1998) Requirements engineering - processes and techniques. John Wiley & Sons, New York, NY, USA.Google Scholar
  15. Zowghi D (2000) A requirements engineering process model based on defaults and revisions In: DEXA Workshop, 966–972.. IEEE, Piscataway, NJ, USA.Google Scholar
  16. Rolland C (1994) Modeling the requirements engineering process In: Information Modelling and Knowledge Bases, 85–96, IOS B.V., Amsterdam, Netherlands.
  17. Grünbacher P (2000) Collaborative requirements negotiation with EasyWinWin In: DEXA Workshop, 954–960.. IEEE, Piscataway, NJ, USA.Google Scholar
  18. Boyd D, Ellison NB (2007) Social network sites: Definition, history, and scholarship. J Computer-Mediated Commun 13(1): 210–230.View ArticleGoogle Scholar
  19. Lim SL, Quercia D, Finkelstein A (2010) Stakesource: harnessing the power of crowdsourcing and social networks in stakeholder analysis In: Proceedings of the 32Nd ACM/IEEE International Conference on Software Engineering - Volume 2, 239–242.. ACM, New York, NY, USA.Google Scholar
  20. Conklin J, Begeman ML (1988) gibis: A hypertext tool for exploratory policy discussion. ACM Trans Inf Syst (TOIS) 6(4): 303–331.View ArticleGoogle Scholar
  21. Lohmann S, Dietzold S, Heim P, Heino N (2009) A web platform for social requirements engineering. In: Münch J Liggesmeyer P (eds)Software Engineering (Workshops). LNI, 309–315.. Köllen Druck Verlag GmbH, Bonn, Germany.Google Scholar
  22. Lohmann S, Riechert T (2010) Bringing semantics into social software engineering: Applying ontologies to a community-oriented requirements engineering environment In: 3rd International Workshop on Social Software Engineering.. Köllen Druck Verlag GmbH, Bonn, Germany.Google Scholar
  23. Kukreja N, Boehm B (2012) Process implications of social networking-based requirements negotiation tools In: Proceedings of the 2012 International Conference on Software and System Process. ICSSP 2013, 68–72.. IEEE, Piscataway, NJ, USA.Google Scholar
  24. Kukreja N, Boehm B (2013) Integrating collaborative requirements negotiation and prioritization processes: A match made in heaven In: Proceedings of the 2013 International Conference on Software and System Process. ICSSP 2013, 141–145.. ACM, New York, NY, USA.View ArticleGoogle Scholar
  25. Damian D. E, Lanubile F, Mallardo T (2006) The role of asynchronous discussions in increasing the effectiveness of remote synchronous requirements negotiations. In: Osterweil LJ, Rombach HD, Soffa ML (eds)ICSE, 917–920, ACM, New York, NY, USA.
  26. Maalej W, Happel H-J, Rashid A (2009) When users become collaborators: towards continuous and context-aware user input. In: Arora S Leavens GT (eds)OOPSLA Companion, 981–990.. ACM, New York, NY, USA.Google Scholar
  27. Maalej W, Pagano D (2011) On the socialness of software In: Proceedings of the IEEE Ninth International Conference on Dependable, Autonomic and Secure Computing, 864–871.. IEEE, Piscataway, NJ, USA.Google Scholar
  28. Hess J, Randall D, Pipek V, Wulf V (2013) Involving users in the wild—participatory product development in and with online communities. Int J Human-Computer Stud 71(5): 570–589.View ArticleGoogle Scholar
  29. Bajic D, Lyons K (2011) Leveraging social media to gather user feedback for software development In: Proceedings of the 2nd International Workshop on Web 2.0 for Software Engineering. Web2SE ’11, 1–6.. ACM, New York, NY, USA.View ArticleGoogle Scholar
  30. UserVoice. https://www.uservoice.com. Accessed April 2015.
  31. Twitter. https://twitter.com. Accessed April 2015.
  32. Harman M, Jia Y, Zhang Y (2012) App store mining and analysis: MSR for app stores In: IEEE Working Conference on Mining Software Repositories (MSR), 108–111.. ACM, New York, NY, USA.Google Scholar
  33. Guzman E, Maalej W (2014) How do users like this feature? A fine grained sentiment analysis of app reviews In: Proceedings IEEE 22nd International Requirements Engineering Conference (RE), 153–162.. IEEE, Piscataway, NJ, USA.Google Scholar
  34. Singer L, Figueira Filho F, Storey M-A (2014) Software engineering at the speed of light: How developers stay current using twitter In: Proceedings of the 36th International Conference on Software Engineering. ICSE 2014, 211–221.. ACM, New York, NY, USA.View ArticleGoogle Scholar
  35. GitHub. https://github.com. Accessed April 2015.
  36. Kalliamvakou E, Gousios G, Blincoe K, Singer L, German DM, Damian D (2014) The promises and perils of mining GitHub In: Proceedings of the 11th Working Conference on Mining Software Repositories. MSR 2014, 92–101.. ACM, New York, NY, USA.View ArticleGoogle Scholar
  37. LinkedIn. https://www.linkedin.com. Accessed April 2015.
  38. Google+. https://plus.google.com. Accessed April 2015.
  39. Alexa. http://www.alexa.com. Accessed April 2015.
  40. Lauesen S (2002) Software Requirements: Styles and Techniques. Addison-Wesley, Glasgow, UK.Google Scholar
  41. Volere Requirements Resources. http://www.volere.co.uk. Accessed April 2015.
  42. Robertson S, Robertson J (1999) ACM Press/Addison-Wesley Publishing Co.
  43. International Requirements Engineering Board (IREB). http://www.ireb.org/en/home.html. Accessed April 2015.
  44. Zowghi D, Coulin C (2005) Engineering and Managing Software Requirements. In: Aurum A Wohlin C (eds), 19–46.. Springer, Secaucus, NJ, USA.
  45. Grünbacher P, Seyff N (2005) Engineering and Managing Software Requirements. In: Aurum A Wohlin C (eds), 143–162.. Springer, Secaucus, NJ, USA.

Copyright

© Seyffet al.; licensee Springer. 2015

This is an Open Access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/4.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly credited.