Seyff et al. Journal of Internet Services and Applications (2015) 6:7 DOI 10.1186/s13174-015-0021-9

RESEARCH Open Access

Using popular social network sites to supportrequirements elicitation, prioritization andnegotiationNorbert Seyff1,2*, Irina Todoran2, Kevin Caluser2, Leif Singer3 and Martin Glinz2

Abstract

Social networks have changed our daily life and they have the potential to significantly influence and supportRequirements Engineering (RE) activities. Social network-based RE approaches will allow us to overcome limitations oftraditional approaches and allow end users to play a more prominent role in RE. They are key stakeholders in manysoftware projects. However, involving end users is challenging, particularly when they are not within organizationalreach. The goal of our work is to increase end user involvement in RE. In this paper we present an approach where weharness a social network to perform RE activities such as elicitation, prioritization and negotiation. Our approach wasapplied 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 IntroductionThe involvement of stakeholders such as future systemend users is a key success factor for Software Engineering(SE) in general, and for Requirements Engineering (RE) inparticular [1].

Several process models are available to describe REactivities [2]. Key activities include requirements elici-tation, prioritization and negotiation. Requirements elic-itation is the process of seeking, capturing and con-solidating requirements from available requirementssources (e.g. stakeholders) [3]. The requirements gath-ered should be prioritized. The priority of a require-ment shows its importance in comparison to others;it also helps decide which requirements to includein a project [3,4]. Furthermore, prioritization supportsrequirements negotiation which focuses on conflict res-olution by finding a settlement that mostly satisfies allstakeholders [5].

*Correspondence: norbert.seyff@fhnw.ch1University of Applied Sciences and Arts Northwestern Switzerland,Bahnhofstrasse 6, Windisch, Switzerland2University of Zurich, Binzmühlestrasse 14, Zurich, SwitzerlandFull list of author information is available at the end of the article

Some approaches foster the involvement of success-critical stakeholders (e.g. end users) in requirements elic-itation, prioritization and negotiation [6]. However, theseapproaches do not sufficiently support non-traditionalcontexts such as mobile computing [7], cloud comput-ing [8] or software ecosystems [9]. This is due to the factthat in these contexts, we need to involve a large num-ber of heterogeneous, globally distributed and potentiallyanonymous stakeholders [10]. Although the underlyingidea of involving success-critical stakeholders is still validin those settings, there is a lack of suitable elicitationtechniques [8] and novel RE approaches and methods areneeded 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 REapproaches and tools are built from an RE perspectiveand require end users to get familiar with a particular sys-tem and procedure. We therefore envision that novel REapproaches will focus on the end user perspective.

For this, we have investigated the potential of popu-lar social network sites (SNS) for requirements elicitation,prioritization and negotiation. Considering the number ofregistered users and regional popularity, we selected fourcandidates for our studies: Facebook, Twitter, LinkedIn

© 2015 Seyff et al.; licensee Springer. This is an Open Access article distributed under the terms of the Creative CommonsAttribution License (http://creativecommons.org/licenses/by/4.0), which permits unrestricted use, distribution, and reproductionin any medium, provided the original work is properly credited.

Seyff et al. Journal of Internet Services and Applications (2015) 6:7 Page 2 of 16

and Google+. From these, Facebook [12] was chosen asthe support for this research. Today, many end users arefamiliar with social network sites in general and Facebookin particular. By using a platform that is part of end users’daily lives, we aim to overcome current limitations of REtools in terms of end user acceptance and involvement.

However, from an RE perspective, this strategy cancause new problems. Popular social network sites havenot been designed for RE and might therefore not sup-port RE activities adequately. Therefore, our aim is toinvestigate whether and how existing functionalities of acurrent social network site can support RE activities. Toour knowledge, these are the first exploratory studies thatresearch the possibility of using social network sites formeeting RE needs. Our exploratory studies with studentsand their Facebook friends lead to qualitative data show-ing that Facebook provides basic capabilities to supportRE activities. Moreover, our findings show the advan-tages and limitations of an SNS-based approach for the REactivities mentioned.

Following the EasyWinWin methodology [6], we foreseethat our lightweight and end user focused RE approachhas many potential applications. We particularly see itsrelevance within novel software paradigms such as mobileand cloud computing and software ecosystems, where endusers are not within immediate reach and where the sup-port provided by traditional methods is insufficient. Forexample, smartphone application developers or cloud ser-vice providers could use our approach to elicit, prioritizeand negotiate stakeholder needs. In software ecosystems,our approach provides a new channel for eliciting ideasand needs as well as receiving feedback from stakehold-ers who are not directly reachable by product owners ordevelopment teams. Moreover, we also see its applica-tion within traditional software projects as an additionalmeans 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 soft-ware is being used within the field of RE. In Section 4,we present a generic SNS-based RE approach. Section 5introduces candidate SNS suitable for implementingour approach. In Sections 6 to 9 we report on threeexploratory studies where students and their friendsapplied our approach with Facebook. After revisiting theresearch questions and discussing threats to validity inSection 10, we conclude the paper and present potentialfuture research directions in Section 11.

2 Research goal and questionsThe goal of our research is to investigate whether and howpopular social network sites have the potential to supportRE activities. We identified three research questions (RQ)to define the focus of our research:

RQ 1: Can a social network site support requirementselicitation, prioritization and negotiation? If so, how canexisting features be used to elicit, prioritize and negotiateend users’ requirements?

Firstly, we are interested in finding out whether exist-ing features exhibited by a social network site such asFacebook can help gathering, prioritizing and negotiat-ing users’ requirements. To answer this question, we setup three exploratory studies and analyse their results.Moreover, we investigate how the existing features canbe utilized, i.e. how an RE activity should be designed tomake good use of the SNS features.

RQ 2: What are the benefits of using a social network siteapproach compared to existing elicitation, prioritizationand negotiation techniques?

Secondly, we identify in what ways and under which cir-cumstance such an SNS approach is better suited thantraditional RE methods. Additionally, we investigate howthis approach could potentially complement existing tech-niques.

RQ 3: What are the challenges and limitations of using asocial network site for requirements elicitation, prioritiza-tion and negotiation?

Thirdly, we analyse potential issues associated withusing an SNS approach to support RE activities, includ-ing their limitations. Relying on our findings, we elaboratepreliminary guidelines that can be followed when utilizingSNS for RE activities.

3 Related work: RE and social softwareRequirements Engineering is a multidisciplinary field[13] that requires active communication and interactionbetween different stakeholders. Depending on the project,its activities may be interleaved, iterative and span acrossthe entire software life cycle [14]. Although various RE ref-erence process models exist [15,16], it is generally agreedupon that early RE activities include (1) requirements elic-itation and (2) requirements analysis and negotiation [14].For each of these activities, there are several sub-activitiesthat vary between projects – e.g. identifying key stake-holders, brainstorming stakeholder interests, prioritizingideas and negotiating them [17]. Several RE approachesand 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 understandthe sequence of activities, sub-activities and their respec-tive purpose. Our work is inspired by EasyWinWin whichfocuses on providing support for requirements elicitation,prioritization and negotiation.

Social network sites are an example of social softwareand used for connecting and communicating withothers – anytime and anywhere. Boyd and Ellison [18]describe social network sites as web-based services thatallow individuals to (1) maintain a public or semi-public

Seyff et al. Journal of Internet Services and Applications (2015) 6:7 Page 3 of 16

profile within a particular system, (2) maintain a list ofconnected users (e.g. friends), people with whom theyshare a connection and (3) view and follow connec-tions made by themselves and by other users. Social net-work sites usually either target a specific user group (e.g.private people, business people or even specific groupssuch as photographers) or support a specific task (e.g.StakeSource [19] as an example for a social network sitesupporting RE activities).

The idea of using social software for supporting suchRE activities has been explored by both researchers andpractitioners throughout the recent years. This sectionpresents related work focusing on strengthening end userinvolvement in RE with the help of social software. Whileconducting the analysis, we identified three categories oftool support. The first represents work on dedicated REtools that include concepts of social software.

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

More recent research focuses on identifying and pri-oritizing stakeholders. This is supported by StakeSourcewhich is a lightweight web-based tool implementing theStakeNet method [19]. The work by Lim et al. is basedon social network analysis as well as collaborative filter-ing and provides requirements engineers with a list ofthe key stakeholders. The method requires an initial setof already identified stakeholders who themselves iden-tify and suggest new stakeholders (snowballing effect). Inaddition, StakeSource provides basic capabilities to iden-tify, negotiate and prioritize requirements [19]. Althoughthis approach is rather straightforward, stakeholders needto make themselves familiar with the forms that allowentering and rating requirements.

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

In their work on WinBook, Kukreja and Boehm [23,24]explore social network functionalities to develop a newavatar of the WinWin framework [6]. Early evaluationresults suggest that the toolset supports non-technicalstakeholders 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 alsoSE activities.

Early work in this field focused on comparingasynchronous text chats to face-to-face meetings forrequirements negotiation [25]. The study conducted withgeographically distributed students revealed that face-to-face meetings become more effective if they are precededby text-based, asynchronous discussions. This resolvedseveral conflicts and reduced the workload in the follow-ing physical meetings. However, the use of chats was onlycomplementary to the physical meetings and therefore notsufficient on its own.

Researchers such as Maalej et al. [26,27] highlight theimportance of end user involvement in today’s softwaredevelopment projects. They promote a conceptual frame-work which combines several existing techniques for bet-ter handling continuous user input during the elicitationphase.

A particular approach supporting elicitation and prod-uct development is presented by Hess et al. [28] whoreport on participatory product development in and withonline communities. Their work represents an example ofuser-centered, community-based requirements elicitationas part of participatory design. They targeted a large pop-ulation of heterogeneous and globally distributed usersand facilitated the interaction by using online tools. More-over, they demonstrate that the role of user representa-tives is vital when managing heterogeneity in an onlinecommunity.

Apart from research, companies have started to includesocial media in their software development processes.Bajic and Lyons present a study on social media used bydifferent software development companies [29]. They fig-ured out that, in an early stage, especially small companiesuse social media to gather feedback from their customers.It is unclear, however, how far companies integrate theseinitiatives into their development processes and whetherthey use traditional RE approaches at all.

Companies such as UserVoice.com [30] have started toreduce barriers for involving end users in the softwaredevelopment process by providing a service that allowssoftware companies to gather feedback from their cus-tomers. Other organizations already use existing socialmedia tools, such as Facebook and Twitter [31]. It is how-ever unclear whether the use of these tools goes beyondthe purposes of marketing and public relations.

A third category of relevant research we have identifiedis the work that focuses on the analysis of data documentedwithin SNS.

Currently, there are attempts to utilize users’ reviewsthat can be found in app stores for mobile platformsto mine requirements or extract features. For instance,

Seyff et al. Journal of Internet Services and Applications (2015) 6:7 Page 4 of 16

Harman et al. use data mining techniques to extractfeature information which is then used to analyse tech-nical, business and customer aspects of the apps. Suchapproaches target large-scale, unknown and heteroge-neous audiences [32].

In their research, Guzman and Maalej [33] alsofocus on analysing user reviews in app stores. Theyhave developed an automated approach that supportsdevelopers in filtering, aggregating and analysing userreviews in order to conduct a fine-grained sentimentanalysis.

Apart from research including or focusing on the enduser perspective, there is research focusing on devel-opers. For example, Singer et al. have investigated howdevelopers stay current using Twitter [34]. Furthermore,researchers are starting to mine information stored inGitHub [35] to better understand how developers col-laborate [36]. This research also focuses on open sourcesoftware development. However, we would like to high-light that in our work we are focusing on the end userperspective, investigating how end user involvement canbe strengthened in RE activities.

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

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

Following our research goal to investigate whether andhow popular SNS can support RE activities, we aimed atproviding a generic RE approach based on well-knownsocial network functionalities. This approach shouldpresent RE activities from an end user perspective andrequire neither lengthy process guidance nor support doc-uments. It should be usable ad hoc, anytime and anywhereto allow distributed requirements elicitation, prioritiza-tion and negotiation in an iterative manner.

Inspired by EasyWinWin, our approach is driven by amoderator, a person who has an interest in the systemto be, and whose aim is to gather requirements for thatsystem. Our solution is designed to also require minimaltraining for the moderator (e.g. a mobile app developer

who would like to gather requirements from potential endusers).

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

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

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

1.2 Provide key information about the project: The mod-erator provides the initial information (such as a visionstatement for the project). This information should bestructured and it should be possible to discuss several top-ics - e.g. information about the project, instructions forthe participants.

The second high-level activity implements requirementselicitation, prioritization and negotiation activities (2).The following tasks are mainly performed by the partic-ipating stakeholders (e.g. end users), guided by the mod-erator. It should be noted that steps 2.1 through 2.4 arerunning simultaneously and in an iterative manner. Theywill not necessarily follow a strict sequence.

2.1 Invitation of participants: The moderator invitesstakeholders to the group. The invitation itself mightinclude key information about the project and purpose ofthe group. Depending on the project, the moderator canask invitees to support the stakeholder identification byinviting more participants.

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

2.3 Participants discuss ideas: As soon as ideas areposted, stakeholders can start a discussion. They can askquestions for clarification and post issues they identifyregarding a certain idea. This allows the inclusion of sev-eral different stakeholder perspectives. The moderatorshould now engage with the participants in order to stim-ulate and steer the negotiation – e.g. by asking questionsfor further clarification.

2.4 Participants approve and prioritize ideas: Partic-ipants communicate their approval of ideas and com-ments in this step. It can help to guide the directionof a discussion. Furthermore, the number of approvalsgiven for an idea or comment can highlight its impor-tance.

The third high-level activity implements requirementsanalysis and follow-up (3), and is performed by the mod-erator:

Seyff et al. Journal of Internet Services and Applications (2015) 6:7 Page 5 of 16

3.1 Transcribe ideas into prioritized requirements:Stakeholder (e.g. end user) contributions may vary inquantity, quality and content. Although the moderator isavailable during discussions, we do not expect the processoutput to provide high quality requirements descriptions.As a last step, he can transcribe initial user needs intowell-defined requirements. By analyzing the number ofapprovals per idea, the moderator can also define the pri-ority of requirements. For this analysis we do not requestexplicit support from an SNS. It strongly depends on theskills and expertise of the moderator.

We conclude that in order to support the approachdepicted, an SNS has to fulfill the following key require-ments:

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 distri-

bution.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 supportFacebook, Twitter, LinkedIn [37] and Google+ [38] areprominent examples of SNS that have millions of regis-tered users. We choose them to become our candidatesfor an implementation of our generic RE approach sinceall of them have a high number of registered and activeusers - according to the statistics provided by Alexa [39].Another criterion was regional popularity – the selectedSNS are popular in central Europe where we performedour exploratory studies. In order to identify the mostsuitable SNS, two of the authors performed an initial com-parison after we had defined the key requirements for ourgeneric SNS-supported RE approach.

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

Our analysis revealed that all would allow an individ-ual end user to express an idea – i.e. a requirement, aneed (R1). Apart from Twitter, all platforms would allowusers to post comments (R2). Except Twitter, all social

networks allow people connected to publicly express theirapproval of an idea (R3). This, for example, includes likein Facebook or +1 in Google+. Twitter contains simi-lar mechanisms (retweet, favorite), but only notifies theowner of a post. Facebook, Twitter and Google+ usersare even able to restrict the access to their ideas and cantherefore control the distribution of the content (R4). InLinkedIn, however, an idea is automatically shared with allconnected people.

Although people could discuss an idea on a user pro-file, we consider a single, protected (private) and dedicatedspace for group discussions to be more adequate (R5).Facebook, LinkedIn and Google+ allow their users to cre-ate such a space. Those groups represent a dedicated spacefor discussing and communicating ideas and allow themoderator to invite stakeholders and manage user set-tings – e.g. define whether group members may inviteadditional contacts (R6).

After an initial comparison of the four social networksites, we concluded that three out of four would allow usto instantiate and apply our generic SNS-supported REapproach. Although all three candidates (i.e. Facebook,LinkedIn and Google+) would have fulfilled our initialrequirements, we selected Facebook to become the plat-form for further investigation. Our main reasons were: (1)Facebook has over a billion users worldwide and is cur-rently the leading social network site; and (2) the targetgroup for our experimental studies (students and theirfriends) would be more likely to already have an accountand be accustomed to Facebook.

6 SNS as an RE tool - exploratory studiesWe performed three exploratory studies with a popularSNS (i.e. Facebook) to evaluate our SNS-supported REapproach. Our aim was to apply it in settings where mod-erators have limited RE knowledge and where potentialend users for the systems under discussion are availableto participate. We targeted projects with real-world char-acter but which would still allow some level of controlregarding the participants and the topics discussed. Whiledesigning our studies, we had in mind the metaphor ofa mobile app developer who would set up a group onFacebook and act as moderator; this in order to gather

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 ✓ ✗ ✓ ✓

Seyff et al. Journal of Internet Services and Applications (2015) 6:7 Page 6 of 16

requirements for a new app he is planning to realize orto elicit requirements for the evolution of an existingapp. The developer could then, for example, invite exist-ing end users of his app(s) for a discussion. Based onthis metaphor we decided to perform evaluation stud-ies within RE lectures in Switzerland and Austria, wherestudents basically have some, but limited, RE knowledge.Those students acted as moderators and invited poten-tial end users (other students and friends) to requirementsdiscussions on Facebook. In Study I and Study II the eval-uation was presented as an exercise to train the students’moderation skills and to also highlight the dynamics ofdistributed RE for those students who were participatingas end users. In Study III the evaluation was conducted togather requirements for real-world projects the studentswere involved in.

All studies followed an approach where we first had abriefing session. This for example included the presen-tation of a description of the RE approach as depictedin Section 4. However, students were not told that theywere using a novel RE approach. The briefing session wasfollowed by the actual evaluation. In all three studies stu-dents were given a timeframe of two weeks to conducttheir requirements engineering activities. However, inStudy I, students would have had the option to prolong thegiven period. We did not interact with the students duringthis period. The evaluation was followed by a debriefingeither directly with the students or using a questionnaire.The debriefing meetings were held to understand the ben-efits and limitations of the process. Facebook friends, whowere invited to the discussion in some studies, were notinvolved in the debriefing activities. This means that inthose studies the debriefing focused on the moderatorwho always was a student.

The studies were performed in sequential order. There-fore, the output of a preceding study supported us indefining the scope of the following study in more detail.The results of each study were analyzed by at leasttwo authors of the paper as soon as the study was fin-ished. One of the authors performed a qualitative analysisas described below and the first author reviewed thoseresults for all three studies. He also checked the validity ofthe requirements gathered (i.e. are they relevant and use-ful for the implementation of the system under discussionand will they satisfy user needs?).

The third author acted as the main analyst and per-formed the analysis for two of the three studies. Theremaining study was analyzed by the second author of thepaper and results were reviewed and approved by the thirdauthor before the first author conducted a final review.

As a first step the author conducting the analysisexported all the data from Facebook to Microsoft Excel.This was done by copying and pasting the data. The fol-lowing content analysis of the data gathered included

the task of identifying the type of the content posted.We distinguished elicitation, negotiation, moderation andother posts. In this context, elicitation posts refer tostatements communicating a new idea; negotiation postsdiscuss an idea; moderation posts represent statementsfrom the moderator or other participants to facilitatethe discussion; other posts refer to any other statementsidentified in the discussions. To better understand thenature of the posts, we applied a goal-design level met-rics for categorization [40]. We distinguished the fol-lowing categories: goal-level, domain- and product-leveland design-level posts. We extracted the total number ofdistinct requirements from the end users’ posts and differ-entiated between functional and non-functional require-ments. The non-functional were classified according toVolere [41,42].

The following sections present the three studies indetail. We discuss the different settings, the methodsused, the results and the findings. For the quantitativeanalysis, we report on key numbers (e.g. invited stake-holders, participating stakeholders, active days, generatedposts, distinct requirements). For calculating some ofthese numbers, we had to define metrics. For example,we defined active days as days where some group interac-tion took place, (e.g. stakeholders being added, ideas beingposted, comments added to discussions).

7 Evaluation study IThe first study was conducted at FHNW University ofApplied Sciences in Switzerland. Participants were secondterm iCompetence Bachelor students. The iCompetencecurriculum includes design and management orientedsubjects in addition to computer science courses. In theirfirst term, the students get an overview on software engi-neering and programming. At this time they are typicallyin their early twenties. In contrast to other computer sci-ence studies, the students of iCompetence include a largenumber of female students (typically more than 50%).

7.1 MethodThe study was presented as an exercise within the REcourse (taught by the first author). This course gives anintroduction to Requirements Engineering and discussestopics similar to the content requested by the IREB CPREcertification schema [43]. The goal of the exercise from thestudents’ perspective was to train their moderation skillsand to give them the chance to experience distributedRE with stakeholders. We made clear that the exercisewould not be graded. In general, students were familiarwith Facebook and also used it to stay in touch with theirfriends and colleagues.

The evaluation was in three parts: briefing, evaluationand debriefing. During the briefing, the students wereinformed of the purpose of the exercise and the task

Seyff et al. Journal of Internet Services and Applications (2015) 6:7 Page 7 of 16

they were about to perform. We presented the processdepicted in Section 4 and asked the students to think ofa software-intensive system that they would like to gatherrequirements for (e.g. the fridge of the future, a personalfinance manager). For each group a moderator was cho-sen; he invited Facebook friends (people who could bepotential end users or who have a general interest in thetopic) to discuss the topic in a Facebook group. Duringthe evaluation, we did not contact students to give advice.In this first study we suggested a timeframe of two weeksto conduct the experiment but, as we were not aware ofthe dynamics of our RE approach, we did not strictly limitthis timeframe. We told them to start immediately andto inform us when the group discussions had stopped,which in all the cases was within the two weeks timeframewe suggested. In the debriefing, we discussed the resultswith the students and asked them to fill out an onlinequestionnaire on how they experienced requirements elic-itation, prioritization and negotiation using Facebook.After the debriefing meetings, we accessed the groupdiscussions and started to analyze the students’ contri-butions.

7.2 ResultsIn total, 17 students and 74 external persons were involvedin this study discussing requirements within 8 differentFacebook groups (see Table 2). The students came up withinnovative ideas for potential software systems. Thoseideas were focusing on novel systems and also on theevolution of existing systems.

Group 1, for example, discussed requirements for amobile app which supports healthy cooking by providingadequate recipes. Students discussed requirements suchas that the app should know about the allergies of its

user. Group 2 investigated how the agenda planner of thefuture should look like. They envisioned a ubiquitous sys-tem and requested, for example, an agenda available alsowhen driving a car and that the car should present theagenda on the windscreen. Group 3 focused on the fridgeof the future and discussed requirements such as the auto-matic generation of shopping lists. Group 4 elaboratedhow media could be consumed in the future and were,for example, requesting to replace remote controls withalternative solutions. Group 5 investigated the function-ality of future SNS such as Facebook. For example, theysuggested the SNS should be able to provide more infor-mation on the character of a person by analysing availablecontent. Group 6 was looking for requirements for an appwhich should support their studies. For example, they dis-cussed the option to get information about students inthe same courses. Group 7 caused quite some discussionas the goal was to provide an app which would sup-port someone who would like to become a dropout (i.e.a hermit). Requirements included guidelines for buildingshelters and huts, also a function which would warn thehermit of poisonous food (e.g. mushrooms). Group 8 dis-cussed requirements for a personal finance manager app.Requirements included that the app automatically tracksthe money spent on certain goods (e.g. clothes).

As some students participated in several groups, theeight Facebook groups considered in this analysis con-tained a total of 184 stakeholders. However, on averageonly 31% responded positively – meaning that 57 stake-holders joined the groups and actively contributed to theFacebook discussions (e.g. by posting comments and usinglikes). Therefore, the average of Facebook friends involvedin each group was about seven members, with a minimumof four and a maximum of 11.

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

Seyff et al. Journal of Internet Services and Applications (2015) 6:7 Page 8 of 16

On average, the groups were active for 4.3 days. Whilethe shortest discussion lasted only for two days, the maxi-mum was seven days. Figure 1 aggregates the eight differ-ent groups of Study I and highlights the distribution of thedifferent kinds of posts 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 bythe type of content they represented (Table 2). A veryhigh number (71.9%) were elicitation posts discussing newideas. 26.3% were negotiation posts whereas the moder-ation and other posts were rather rare (1.6% and 0.4%respectively).

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

We analyzed the number of likes in order to get an ideaon the priority of the needs posted. On average, a partic-ipant used the like functionality 2.1 times. However, theuse of likes varied significantly between the groups (seeTable 2).

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

7.3 FindingsThis study investigated whether and how end users wereable to participate in an SNS-supported RE approach and

whether students with limited RE knowledge were able tofacilitate the approach. The main findings of this study arehighlighted below:

1.1 End users were able to follow the process and com-municated their needs: As shown by the results, followingthe approach proposed and without training, end userswere able to express their needs and discuss ideas on Face-book. By analyzing the ideas and needs communicatedby end users, we were able to identify a high number ofrequirements. For example, the group discussing needs forthe Fridge of the Future mentioned: “The fridge suggestsrecipes that take into account the current content of thefridge”.

1.2 Moderation was insufficient: Although moderatorswere present, they did not fully play their role. Theyalso got involved in elicitation and negotiation activities(e.g. posted new ideas). We could only identify dedicatedmoderation posts in one group (see Table 2). One mainreason might be the students’ limited RE knowledge andmoderation experience.

1.3 Most of the content was created within the first days:In this study, all moderators mostly invited stakeholdersonly at the beginning of the discussion. An analysis of thegroup discussions revealed that most content was createdafter participants were invited. This suggests that partici-pants are only active in the group discussion for a limitedamount of time.

1.4 Prioritization results were insufficient: Some groupshardly used the like functionality (see Table 2). The likesprovided by the participants were not sufficient to build aprioritized list of requirements. However, we were able toidentify some favorites in most groups.

1.5 No snowball effect: We had expected some“friends of friends” to join the discussion. In half thegroups, none of the friends invited took part in thestakeholder identification. In the other groups, someparticipants invited friends. However, there was noreal snowball effect, especially as the contribution of“friends of friends” did not even result in one singlerequirement.

Figure 1 Aggregate values of Study I over time.

Seyff et al. Journal of Internet Services and Applications (2015) 6:7 Page 9 of 16

8 Evaluation study IIThe second study was conducted at the University ofZurich in Switzerland. The participants were seven com-puter science graduate students. All of them had success-fully completed an undergraduate course on RE and someof them already had industrial experience.

8.1 MethodThe study was presented as an exercise in an advancedcourse on RE (taught by the fifth author) where selectedRE topics are discussed with students. Again, this exer-cise had no impact on the students’ grades. As in the firststudy, the evaluation was structured into briefing, evalu-ation and debriefing phases. In the briefing session, thestudents were advised to work with Facebook and invitefriends – but not fellow students – in order to train theirmoderation skills and experience requirements elicitationand negotiation with stakeholders. We further told themnot to invite all friends at once and to ask their friends toadditionally invite other friends who might be interestedin the topic. Furthermore, we asked them to explicitlyinvite the participants to use the like functionality as soonas the discussion had produced stable needs. This time,we defined upfront two discussion topics we knew all par-ticipants would be familiar with – the Fridge of the Future(FoF) and the Smartphone of the Future (SoF). While fourstudent moderators chose the first topic, the remainingthree wanted to discuss needs regarding the SoF.

As several groups were discussing the same topic, weasked the students to consolidate and aggregate theirresults after the individual discussions. Furthermore, theywere advised to invite all participating discussants for afinal prioritization using likes. As the group of students

also included one of the authors of this paper, we choseto exclude his group when we presented the analysis ofthe results. During the exercise, we had no contact withthe students and no access to their groups. We limitedthe timeframe of the exercise to two weeks and told thestudents to start immediately. We conducted a debrief-ing meeting to explore the students’ experiences after theexercise and requested access to their groups for furtheranalysis of the results.

8.2 ResultsThe six moderators invited a total of 73 friends, 38.4%became active members of the groups (28 friends). In thesmallest group, there were two active participants whilethe largest group had seven contributors. On average,the participation was 4.7 friends per group. Groups wereactive for an average of four days – the longest discussionlasted six days while the shortest took two days (Table 3).The six groups generated a total of 131 posts with 78posts originating from the FoF groups and 53 from theSoF groups. The result is an average 6.5 and 3.3 postsrespectively per contributor. 18.7% of the posts in thethree FoF groups were elicitation posts. 29.7% of the postsfocused on negotiation, 46% on moderation and 5.6% wereother posts. In the SoF groups we identified 48.7% elici-tation, 20.7% negotiation, 26.6% moderation and 4% otherposts. For example, in their posts, participants were ask-ing for longer battery run times (elicitation post). Themoderator requested a more detailed discussion (moder-ation post) and other participants started a negotiation.One participant requested that the battery of the smart-phone of the future should at least last for 16 hours, whileanother participant’s vision included a smartphone which

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

Seyff et al. Journal of Internet Services and Applications (2015) 6:7 Page 10 of 16

would not run out of battery at all by using novel energysources such as solar energy.

We analyzed the posts’ abstraction level. Regardingthe 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. Theseposts led to a total of 63 (FoF) and 34 (SoF) require-ments. While the FoF groups mainly gathered functionalrequirements (77.4%), the SoF groups found more non-functional requirements (63.2%). The 35 non-functionalrequirements (NFR) mostly referred to needs regardinglook and feel (40% FoF, 50% SoF) and usability (40% FoF,30% SoF), but also performance (13.3% FoF, 20% SoF) andenvironmental issues (6.7% FoF, 0% SoF). For example,participants requested that the SoF should be no thickerthan 5.0 mm.

After the individual group discussions, we consoli-dated the requirements gathered. The moderators identi-fied overlaps regarding requirements among the differentgroups. 11 duplicates could be found within the FoF topicand 3 within the SoF topic. For example, all groups dis-cussing the FoF highlighted the need to be informed whenthe food is approaching its expiration date. After the mod-erators entered the transcribed requirements in a newFacebook group, participants were invited to prioritize.88% of the participants who had contributed to the indi-vidual group discussions also participated in this phase.They used the like functionality 152 times (63 for FoF, 89for SoF) giving an average of 5.6 likes per contributing par-ticipant and 2.1 likes per requirement. The highest ratedrequirements were liked eight times while the lowest ratedrequirements received no likes at all.

We also analyzed the results of the author’s group (seeTable 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 participantwas considerably higher than the average of the othergroups in Study II (7.3 compared to 3.5).

8.3 Findings2.1 No prerequisites required for participants: The resultof Study II shows that it is not necessary for a partici-pant to have RE knowledge in order to take part in theproposed SNS-based RE approach. We discussed who stu-dents invited to the discussions in debriefing meetings.This revealed that the friends invited had various back-grounds, mostly unrelated to computer science. All ofthem were familiar with the topic under discussion andhad a Facebook account and Facebook experience priorto the discussion. However, we did not request any moredemographic data on the friends invited, this was forprivacy reasons.

2.2 Factors improving success: The group of the authorand FoF1 produced better results in terms of distinctrequirements gathered. Analyzing the groups in moredetail, we could identify three possible reasons: (1) Highmotivation of the moderators resulting in intensive careof the participants, (2) using friendly, lauding, and some-times funny posts to engage people in discussions andstimulate creativity and, (3) continuously inviting newparticipants to keep the discussions alive over a longerperiod of time.

2.3 Consolidation and prioritization: Although partic-ipants were not explicitly asked to use likes within theindividual group discussions, several likes were gener-ated (see Table 3). In Study II, the moderators providedconsolidated requirements for each topic and invited par-ticipants to like them. This resulted in a prioritized list ofrequirements.

2.4 Again, no snowball effect: Although in several groupsthe moderators actively asked participants to invite theirfriends, no snowball effect occurred. One single friendof a friend joined the group, which cannot be seen as asnowball effect.

2.5 Friendship and interests made friends participate:Debriefing meetings revealed that many friends partici-pated in order to support their friend – the moderator.Furthermore, the friends who contributed, because theywere generally interested in the topic, had a sudden bril-liant idea they wanted to share or they participated out ofcuriosity.

2.6 Knowledge and skills: Although the students adoptedthe role of moderator more strictly than in the first study –in terms of more moderation posts – this did not result inmore requirements (16.9 in Study I vs. 16.2 in Study II onaverage). However, the number of requirements per con-tributing participant increased from 2.4 in the first studyto 3.5 in the second study.

9 Evaluation study IIIThe third study was conducted at FH Hagenberg, a Uni-versity of Applied Sciences in Austria. Second term mobilecomputing students who were involved in projects withindustrial partners had to identify needs for their projects.We wanted to investigate whether the fact that partic-ipants have to build the systems under discussion hadan effect on the outcome. The students had basic soft-ware engineering skills but had not attended an RE coursebefore.

9.1 MethodThe study was presented as an exercise within their REcourse (taught by the first author). This course givesan introduction to RE and is aligned with the contentrequested by the IREB CPRE certification schema. Inthe briefing meeting, we discussed the SNS-supported

Seyff et al. Journal of Internet Services and Applications (2015) 6:7 Page 11 of 16

RE process with the students and advised them to invitestakeholders – friends or fellow students – who werepotential end users and likely to provide requirements fortheir projects. Furthermore, we gave the same instructionsas in Study II: ask friends to invite friends, consolidatethe results of group discussions and then explicitly ask forlikes for requirements prioritization. After the evaluation,we requested that the students answer an online question-naire and we accessed their Facebook groups for furtheranalysis.

9.2 ResultsIn total, 18 students and 81 external persons (friends) wereinvolved in this study. In our study we had nine groupsgathering requirements for software systems (mostlyapps) they were about to develop. The customer for thoseapps 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 ofthe Future (SoF). The results of this group were not con-sidered in the later evaluation because of this differentsetting.

The nine groups working on real-world softwareprojects had to gather requirements for different systemsthat did not exist. This means no group was discussingrequirements regarding the evolution of an existing sys-tem. For example, Group 1 had to develop an app whichwould allow its users to control personal expenses. Group2 had a more technical topic and was focusing on pro-grammers as end users. Their goal was to develop anOpenGL image shader. The aim of group 3 was to build anapp 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 appsupporting a yearly soccer tournament. In contrast, Group6 with their “City Detective” app had the idea to developan app for tourists where they would play the role of detec-tives in order to visit important sights of a city. Group 7was working on an app supporting the local paramedicgroup. Group 8 had to provide an app to manage a user’ssticker collection and Group 9 was working on a friendsfinder app.

As some students participated in several groups, thenine Facebook groups considered in this analysis con-tained a total of 134 stakeholders. In total, 59 becameactive group members (41.2%). While 64% of the par-ticipants were fellow students, 36% were usually otherFacebook friends. The smallest group had two activeparticipants while the largest had 11. On average, 6.6participants were engaged in a group discussion.

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

Again, we categorized the posts by type of content rep-resented. We identified an average of 41.7% elicitationposts, 35.7% negotiation posts, 21.4% moderation and1.2% other posts. Only 2.2% of the posts reflected end usergoals. Around 85.6% were assigned to the domain- andproduct-level category. Around 12.2% discussed design-level issues.

We were able to define 203 distinct requirements. Onaverage, each of the nine groups gathered 22.6 require-ments resulting in 3.44 distinct requirements per active

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

Seyff et al. Journal of Internet Services and Applications (2015) 6:7 Page 12 of 16

participant. The majority of the requirements was func-tional (75.3%). The 52 NFR included requirements regard-ing 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 discus-sions, they explicitly asked participants for likes. Withoutconsidering Group 1 and Group 5 who did not performthis task (see Table 4), the number of likes was 323 in total.On average, a participant used the like functionality seventimes.

9.3 Findings3.1 A motivated moderator is a success factor: The factthat students had to realize the system under discus-sion might have been a key motivational factor. Althoughthe students in this study had limited RE skills (similarto the students in Study I), they were engaged modera-tors. This is reflected in the high number of moderationposts and the high quality of the posts. The data sug-gests that the students really wanted to know what endusers would expect from the system to be built. This mightalso be reflected by the high percentage of posts referringto the design-level and the high number of moderators’posts asking for clarification. The students’ high motiva-tion might have caused the high number of requirementsidentified. In particular, the average number of distinctrequirements gathered for industrial projects in Study III(22.6) was significantly higher than the number of require-ments describing the Smartphone of the Future in StudyIII (11).

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

3.3 Sense of duty and interest made students partici-pate: The questionnaire revealed several reasons given bystudents for participating in the discussions. One mainreason was that it was an exercise within a lecture andtheir participation was expected. Another reason wastheir interest in the topic and they wanted to be part of thediscussion.

3.4 Minor differences between friends and fellow stu-dents: Analyzing the results, again, we could not identifyany difference in the results they produced. However, wedid identify issues related to the opportunity to partici-pate. While 58.9% of the fellow students invited actuallyparticipated, on average only 27.2% of the friends invitedjoined the discussions.

3.5 Requirements prioritization worked: Moderators didnot explicitly ask participants for likes before they con-solidated the needs. Nevertheless, three groups gatheredmore than 30 likes each. This allowed for a prioritizedlist of requirements. Participants from other groups com-pletely ignored this opportunity (Table 4). However, ask-ing for likes on the consolidated requirements led to asufficient number of likes for all the groups to come upwith a prioritized list of requirements.

3.6 The discrepancy of the Smartphone group: In StudyIII, one group was not involved in an industrial projectand discussed the topic Smartphone of the Future. Analyz-ing the requirements, we identified more non-functionalrequirements (55%). This pattern also appears in the StudyII Smartphone Groups but it is different from all the othergroups in our three studies. We cannot give a clear expla-nation but we have a hypothesis: identifying requirementsfor the Smartphone of the Future is hard for the averageperson. The features of smartphones were extended sig-nificantly in the last years. People are overwhelmed bynew functionalities and might already be satisfied with thecurrent capabilities of their smartphones. However, theymight want an improved quality as shown by the highnumber of non-functional requirements.

10 Research questions revisited and threats tovalidity

We sought to answer the three research questions fromthe standpoint of our conceptual solution and the findingsof the studies conducted. The empirical evidence we col-lected allows us to clearly identify trends. However, giventhe exploratory nature of the studies, we cannot presentany statistically significant results.

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

The findings of all three studies reveal that existing fea-tures of Facebook, e.g. the possibility to build dedicatedgroups, comment on or like posts, support RE activi-ties such as requirements elicitation, prioritization andnegotiation. Generally, end users were able to followthe process, express their needs, provide input to ongo-ing discussions (Finding 1.1) and prioritize requirements(Finding 3.5). They used the commenting functionality tomention what they would want the system or product tobe, and the liking feature for prioritizing their needs. Forthese tasks, no prerequisites were required of the par-ticipants (Finding 2.1) since they were already familiarwith Facebook, the chosen social network site. Moreover,the students participating in Study III, who also had todevelop the system themselves, were satisfied with theneeds elicited (Finding 3.2) and considered them to be

Seyff et al. Journal of Internet Services and Applications (2015) 6:7 Page 13 of 16

valid requirements (i.e. relevant and useful for their futureimplementation). For all studies the first author of thispaper investigated the validity of the requirements andcame to the conclusion that the involvement of severalstakeholders discussing their needs leads to requirementsthat are agreed and useful for the implementation of thesystem under discussion. However, as in Study I and II theoutput of the discussion was not used for actual systemdevelopment, we do not know which of them would haveactually been implemented. Also for Study III we do notknow which of the requirements discussed were actuallyimplemented.

Using an SNS-based RE approach in real-world settingscould increase end user involvement in RE and supportprojects with a list of end user needs. This should beseen as an initial vision and not as an exhaustive list ofvalidated requirements. As expected, the approach didnot provide well-defined requirements but rather enduser needs which could then be turned into require-ments. The output obtained with our approach does notin any way exclude the usage of other existing elicita-tion and prioritization methods but rather complementsthem.

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

With the emergence of cloud systems and the grow-ing development and popularity of smartphone andtablet applications, understanding the needs comingfrom geographically distributed, heterogeneous and oftenunknown potential users becomes increasingly challeng-ing [8]. Therefore, there seems to be a need for RE meth-ods that can be used in these contexts. Our social networksite approach supports the gathering of needs from suchaudiences 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 major-ity is used to the Facebook platform. Moreover, accordingto our findings, the consolidation and prioritization ofneeds can be supported on a large scale (Finding 2.3) andthe social aspect plays an important role: friendship andcommon interests are significant incentives for people toparticipate in elicitation activities (Finding 2.5). These fea-tures of our approach differ from traditional RE methodssuch as interviews or workshops and stem from its dis-tinct nature: it is based on an SNS end users are alreadyfamiliar with. Therefore, it can be integrated in the over-all RE process to supplement existing techniques whenworking in contexts like the ones mentioned above. Fur-thermore, applying our approach within a social networkadds a unique side to the RE process: new stakeholders getinvolved because their friends are already taking part thusembedding the participation in their relationship. This

characteristic is virtually never supported by traditionalmethods.

10.3 RQ 3: What are the challenges and limitations ofusing a social network site for requirementselicitation, prioritization and negotiation?

Naturally, there is no single general purpose RE tech-nique. As explained under RQ2, our approach is bestsuited for particular contexts and should generally beused in conjunction with other existing methods. Oneof its limitations is that the number of needs elicited,prioritized and negotiated can overly depend on moder-ator’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 takenwhen choosing and potentially training the modera-tor. For instance, when the Study III moderator washighly motivated, the results obtained were satisfactoryfor the participants questioned (Finding 3.2). Addition-ally, 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 discussingthe system under investigation, but we do not considerits occurrence to be a prerequisite for successful SNS-based RE.

The approach we propose is inspired by the EasyWin-Win methodology [6]. As recommended by EasyWinWin,it uses brainstorming to elicit requirements. Brainstorm-ing is a widely recognized requirements elicitation tech-nique and is described in e.g. [44]. Our approach usesFacebook posts to bring brainstorming about. Facebooklikes allow the communication of approval and supportrequirements prioritization. Although stakeholders canprioritize requirements, this approach does not allowthem to communicate a certain degree of approval whichis supported by state-of-the-art prioritization approaches[4]. Comments to posts support requirements nego-tiation. By using comments, stakeholders can discussissues regarding a requirement posted in a way simi-lar to the one proposed by EasyWinWin. However, thecontent of a Facebook comment cannot be defined inmore detail. This means it is not possible for the stake-holders to immediately grasp the purpose of the post(e.g. to see whether it is an issue or an option). Stake-holders have to keep in mind the structure of a dis-cussion while more elaborate negotiation tools providethis kind of support (e.g. by highlighting the WinWintree) [45].

As far as the guidelines that can be followed when uti-lizing SNS for early RE activities are concerned, the mainlessons (L) we learned are the following:

L1: Moderators play an important role in steering discus-sions and should be carefully chosen. Evidence: Findings2.2, 2.6 and 3.1.

Seyff et al. Journal of Internet Services and Applications (2015) 6:7 Page 14 of 16

L2: High inner motivation of participants leads to highnumbers 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 theparticipation rate. Evidence: Finding 2.5.

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

L5: Friendly and funny posts stimulate discussions andcreativity 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 expectthat similar results could be obtained when using othersocial network sites, as long as the necessary features forour approach are present (see Section 4). However, whenreplicating this study in other contexts, users’ interactionwith the SNS should also be considered. For example,whereas LinkedIn may provide rather similar featuresthat could support the method introduced here, LinkedInusers tend to log-in and check their network activity morerarely than Facebook users. This could potentially lead toless input from users or to longer periods of waiting forgathering needs and requirements. We cannot draw anyobjective conclusions in this direction and further studiesare needed to find out to what extent and how other SNScan be used successfully to support our approach.

10.4 Threats to validityIn our studies, we asked RE students to become the mod-erators of Facebook groups. In two of the three studiesthe students might have had a limited interest in the exer-cise. Only in Study III did the students have a stake in theoutcome of the Facebook discussion as the results wouldcontribute to their projects.

The studies heavily relied on the participation of REstudents and friends of moderators. Although debriefingmeetings suggest that participating friends had diversebackgrounds, we consider the lack of a broader audiencein our studies a threat to construct validity.

We focused on a setup that would reflect real-worldsettings in an uncontrolled environment such as the oneprovided by Facebook. For example, the moderator stu-dents in Study III can be compared to real-world appdevelopers asking their customers – who might includetheir friends – for new ideas and comments on a plannedapp. However, several contextual issues – e.g. presentingthe study in the form of an (ungraded) exercise and assign-ing predefined topics – might have had an influence onthe results. These issues are threats to the internal validity.

The results of the three studies do not allow us to makestatistically significant claims, which is a threat to con-clusion 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 theapproach we presented.

In the three studies the authors focused on a settingwhere stakeholders were students and therefore moti-vated to participate. In real-world settings we need toidentify other ways to motivate potential contributors.Only one popular social network was considered withinour initial studies. The profile, background, motivationand behaviour of users might be different in other socialnetworks. This can be seen as a threat to external validity.

11 Contribution and future workThe work presented in this paper investigates whetherand how popular social network sites (i.e. Facebook) cansupport and allow end users to participate in RE activ-ities such as elicitation, prioritization and negotiation.Inspired by EasyWinWin we have developed a genericSNS-based RE approach. We foresee that such approacheswill increase end user participation in RE and allow geo-graphically distributed end users to communicate theirneeds in an asynchronous way. Our three exploratorystudies reveal that potential end users and moderatorswith limited RE knowledge are able to identify needs forthe system under investigation.

We would like to stress that the approach presenteddoes not necessarily provide well-specified requirementsbut rather reveals end user needs. However, we envisionthat SNS-supported RE approaches will become addi-tional channels for RE. Therefore, they will complementtraditional RE methods and tools and could potentiallyalso support projects with limited RE budgets (e.g. mobileapp development). Instead of highly skilled requirementsengineers being trained to apply complex RE approachesand tools, the moderator within the SNS-supported REapproach presented could be a person who only has lim-ited RE knowledge.

Further work is needed to answer open questions andoutline the scope, capabilities and limitations of such alightweight approach.

Better understanding risks and issues: This workfocused on feasibility. However, future work will alsoneed to clearly identify issues regarding SNS-supportedapproaches. This, for example, includes issues regardingparticipation (e.g. privacy issues) and tool-support (e.g.limited prioritization capabilities).

Evaluation of other suitable SNS: As discussed inSection 5, we know that SNS other than Facebookwould allow researchers and practitioners to instanti-ate our generic SNS-based RE approach. Although ourexploratory studies have shown that the approach workswith Facebook, we cannot be certain if and how theapproach would actually work with other SNS. For exam-ple, in LinkedIn, members maintain contacts on a more

Seyff et al. Journal of Internet Services and Applications (2015) 6:7 Page 15 of 16

professional level which might have an influence on theresults. 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 seethe 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 ratherthan real-word industrial projects. Further evaluationswill target the application of our approach in industrialsettings. We are currently discussing the option to use ourapproach within a company developing mobile apps.

Exploring the motivation of end users: We would like tobetter understand the motivation of end users and havetherefore started collaborating with the Department ofPsychology at the University of Zurich. The degree ofend user commitment may vary within projects. In someprojects, it might be the duty of end users to participatein requirements elicitation, prioritization and negotiationactivities. Other end users might draw motivation fromdifferent sources (e.g. interest in the topic, supporting afriend, curiosity). Better understanding the motivation ofend users will support us in defining more stable andpredictable approaches.

Competing interestsThe authors declare that they have no competing interests.

Authors’ contributionsNS, IT and KC are the main authors of the article. They have jointly conductedthe studies, analyzed the results and worked on the manuscript. LScontributed to a first version of the manuscript. MG was involved in writingthe manuscript and gave continuous feedback. All authors read and approvedthe final manuscript.

AcknowledgementsThis research is partly funded by the Swiss National Science Foundation(project number 200021_150142). We are grateful to all participantscontributing to the presented research. Furthermore, we would like to thankSimone Schoch, Anne Koziolek, Olga Liskin, Dustin Wüest and Noële Renardfor feedback and input.

Author details1University of Applied Sciences and Arts Northwestern Switzerland,Bahnhofstrasse 6, Windisch, Switzerland. 2University of Zurich,Binzmühlestrasse 14, Zurich, Switzerland. 3University of Victoria, 3800 FinnertyRd, Victoria, Canada.

Received: 1 July 2014 Accepted: 2 March 2015

References1. Kujala S, Kauppinen M, Lehtola L, Kojo T (2005) The role of user

involvement in requirements quality and project success. In: Proceedingsof the International Requirements Engineering Conference. IEEE,Piscataway, NJ, USA. pp 75–84

2. Aurum A, Wohlin C (2005) Requirements engineering: Setting thecontext. In: Aurum A, Wohlin C (eds). Engineering and ManagingSoftware Requirements. Springer, Secaucus, NJ, USA. pp 1–15

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.Springer, Secaucus, NJ, USA. pp 69–94

5. Easterbrook S (1991) Handling conflict between domain descriptionswith computer-supported negotiation. Knowl Acquis 3:255–289

6. Boehm B, Gruenbacher P, Briggs R (2001) Developing groupware forrequirements negotiation: Lessons learned. IEEE Soft 18(3):46–55

7. Seyff N, Ollmann G, Bortenschlager M (2014) Appecho: A user-driven, insitu feedback approach for mobile platforms and applications. In:Proceedings of the 1st International Conference on Mobile SoftwareEngineering and Systems. MOBILESoft 2014. ACM, New York, NY, USA.pp 99–108

8. Todoran I, Seyff N, Glinz M (2013) How cloud providers elicit consumerrequirements: An exploratory study of nineteen companies. In:Proceedings IEEE International Requirements Engineering Conference(RE). IEEE, Piscataway, NJ, USA. pp 105–114

9. Dittrich Y (2014) Software engineering beyond the project – sustainingsoftware ecosystems. Inf Softw Technol 56(11):1436–1456

10. Lloyd WJ, Rosson MB, Arthur JD (2002) Effectiveness of elicitationtechniques in distributed requirements engineering. In: Proceedings IEEEJoint International Conference on Requirements Engineering. IEEE,Piscataway, NJ, USA. pp 311–318

11. Seyff N, Graf F, Maiden N (2010) Using mobile RE tools to give end-userstheir own voice. In: Proceedings IEEE International RequirementsEngineering Conference (RE). IEEE, Piscataway, NJ, USA. pp 37–46

12. Facebook. https://www.facebook.com. Accessed Dec 201413. Nuseibeh B, Easterbrook S (2000) Requirements engineering: a roadmap.

In: Proceedings of the Conference on The Future of Software Engineering.ACM, New York, NY, USA. pp 35–46

14. Kotonya G, Sommerville I (1998) Requirements engineering - processesand techniques. John Wiley & Sons, New York, NY, USA

15. Zowghi D (2000) A requirements engineering process model based ondefaults and revisions. In: DEXA Workshop. IEEE, Piscataway, NJ, USA.pp 966–972

16. Rolland C (1994) Modeling the requirements engineering process. In:Information Modelling and Knowledge Bases, IOS B.V., Amsterdam,Netherlands. pp 85–96

17. Grünbacher P (2000) Collaborative requirements negotiation withEasyWinWin. In: DEXA Workshop. IEEE, Piscataway, NJ, USA. pp 954–960

18. Boyd D, Ellison NB (2007) Social network sites: Definition, history, andscholarship. J Computer-Mediated Commun 13(1):210–230

19. Lim SL, Quercia D, Finkelstein A (2010) Stakesource: harnessing the powerof crowdsourcing and social networks in stakeholder analysis. In:Proceedings of the 32Nd ACM/IEEE International Conference on SoftwareEngineering - Volume 2. ACM, New York, NY, USA. pp 239–242

20. Conklin J, Begeman ML (1988) gibis: A hypertext tool for exploratorypolicy discussion. ACM Trans Inf Syst (TOIS) 6(4):303–331

21. Lohmann S, Dietzold S, Heim P, Heino N (2009) A web platform for socialrequirements engineering. In: Münch J, Liggesmeyer P (eds). SoftwareEngineering (Workshops). LNI. Köllen Druck Verlag GmbH, Bonn, GermanyVol. 150. pp 309–315

22. Lohmann S, Riechert T (2010) Bringing semantics into social softwareengineering: Applying ontologies to a community-oriented requirementsengineering environment. In: 3rd International Workshop on SocialSoftware Engineering. Köllen Druck Verlag GmbH, Bonn, Germany

23. Kukreja N, Boehm B (2012) Process implications of socialnetworking-based requirements negotiation tools. In: Proceedings of the2012 International Conference on Software and System Process. ICSSP2013. IEEE, Piscataway, NJ, USA. pp 68–72

24. Kukreja N, Boehm B (2013) Integrating collaborative requirementsnegotiation and prioritization processes: A match made in heaven. In:Proceedings of the 2013 International Conference on Software andSystem Process. ICSSP 2013. ACM, New York, NY, USA. pp 141–145

25. Damian D. E, Lanubile F, Mallardo T (2006) The role of asynchronousdiscussions in increasing the effectiveness of remote synchronousrequirements negotiations. In: Osterweil LJ, Rombach HD, Soffa ML (eds).ICSE, ACM, New York, NY, USA. pp 917–920

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. ACM, New York, NY, USA. pp 981–990

27. Maalej W, Pagano D (2011) On the socialness of software. In: Proceedingsof the IEEE Ninth International Conference on Dependable, Autonomicand Secure Computing. IEEE, Piscataway, NJ, USA. pp 864–871

28. Hess J, Randall D, Pipek V, Wulf V (2013) Involving users in thewild—participatory product development in and with onlinecommunities. Int J Human-Computer Stud 71(5):570–589

Seyff et al. Journal of Internet Services and Applications (2015) 6:7 Page 16 of 16

29. Bajic D, Lyons K (2011) Leveraging social media to gather user feedbackfor software development. In: Proceedings of the 2nd InternationalWorkshop on Web 2.0 for Software Engineering. Web2SE ’11. ACM,New York, NY, USA. pp 1–6

30. UserVoice. https://www.uservoice.com. Accessed April 201531. Twitter. https://twitter.com. Accessed April 201532. 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). ACM, New York, NY, USA. pp 108–111

33. Guzman E, Maalej W (2014) How do users like this feature? A fine grainedsentiment analysis of app reviews. In: Proceedings IEEE 22nd InternationalRequirements Engineering Conference (RE). IEEE, Piscataway, NJ, USA.pp 153–162

34. Singer L, Figueira Filho F, Storey M-A (2014) Software engineering at thespeed of light: How developers stay current using twitter. In: Proceedingsof the 36th International Conference on Software Engineering. ICSE 2014.ACM, New York, NY, USA. pp 211–221

35. GitHub. https://github.com. Accessed April 201536. Kalliamvakou E, Gousios G, Blincoe K, Singer L, German DM, Damian D

(2014) The promises and perils of mining GitHub. In: Proceedings of the11th Working Conference on Mining Software Repositories. MSR 2014.ACM, New York, NY, USA. pp 92–101

37. LinkedIn. https://www.linkedin.com. Accessed April 201538. Google+. https://plus.google.com. Accessed April 201539. Alexa. http://www.alexa.com. Accessed April 201540. Lauesen S (2002) Software Requirements: Styles and Techniques.

Addison-Wesley, Glasgow, UK41. Volere Requirements Resources. http://www.volere.co.uk.

Accessed April 201542. 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 201544. Zowghi D, Coulin C (2005) Engineering and Managing Software

Requirements. In: Aurum A, Wohlin C (eds). Springer, Secaucus, NJ, USA.pp 19–46

45. Grünbacher P, Seyff N (2005) Engineering and Managing SoftwareRequirements. In: Aurum A, Wohlin C (eds). Springer, Secaucus, NJ, USA.pp 143–162

Submit your manuscript to a journal and benefi t from:

7 Convenient online submission

7 Rigorous peer review

7 Immediate publication on acceptance

7 Open access: articles freely available online

7 High visibility within the fi eld

7 Retaining the copyright to your article

Submit your next manuscript at 7 springeropen.com