Entertainment Computing 5 (2014) 335345Contents lists available at ScienceDirect
journal homepage: ees .e lsevier .com/entcomGamifying requirement elicitation: Practical implications and outcomesin improving stakeholders collaborationqhttp://dx.doi.org/10.1016/j.entcom.2014.04.0021875-9521/ 2014 Elsevier B.V. All rights reserved.
q This paper has been recommended for acceptance by Matthias Rauterberg. Corresponding author.
E-mail address: email@example.com (C. Ribeiro).Claudia Ribeiro a,, Carla Farinha b, Joo Pereira a, Miguel Mira da Silva aa INESC-ID, Department of Information Systems and Computer Science, Technical University of Lisbon, Rua Alves Redol 9, Lisbon, PortugalbOpensoft, Lisbon, Portugal
a r t i c l e i n f o a b s t r a c tArticle history:Received 30 May 2013Revised 11 February 2014Accepted 1 April 2014Available online 11 July 2014
Keywords:Requirements elicitationCooperationCollaborationCommunicationSix Thinking HatsGamificationThe requirements engineering process is a key phase of the Information System development since itdetermines its functionalities and its operation. Before requirements can be analyzed, modeled, orspecified they must be gathered through an elicitation process. Requirements elicitation is non-trivialbecause you can never be sure you get all requirements from the user or stakeholder by just asking themwhat the system should do. Requirements elicitation practices include interviews, questionnaires, userobservation, workshops, brainstorming, use cases, role playing and prototyping. However, these commonprocedures are still prone to be ambiguous or incorrect which can lead the Information Systems to failure.It is consensual that one of the major problem of this activity relates to the communication andcollaboration between different and distant stakeholders. Thus, recent studies have been proposingweb collaborative tools to gather these stakeholders in order to elicit requirements. The paper aims toevaluate the effectiveness and acceptance of such a collaborative tool which was developed by using agamification approach and the Six Thinking Hats method. The document also makes a discussion ofthe implication and outcomes of improving stakeholders collaboration.
2014 Elsevier B.V. All rights reserved.1. Introduction
Today we live in an Information Age where people rely on com-puters and technology to work, socialize or live [1,2]. This technol-ogy quite often comes to us through Information Systems. Buildingsuch systems is usually a complex and difficult task, demanding asignificant effort on planning and managing their developmentprocess. Therefore, system designers and developers use the Sys-tem Development Life Cycle (SDLC) framework which breaks downthe development process into a pipeline of activities. Several SDLCmodels have been created (waterfall, fountain, rapid prototyping,incremental, etc.) but all of them have the requirements elicitationactivity as the earliest stage in the pipeline. Before requirementscan be analyzed, modeled, or specified they must be gatheredthrough an elicitation process. The aim here is to understand anddefine how the system will operate . Requirements elicitationis based on an intense communication between stakeholders andbetween stakeholders and analysts. Therefore, cooperation andcollaboration are vital in this process . Requirements elicitationis non-trivial because you can never be sure you get all require-ments from the user or stakeholder by just asking them what thesystem should do. Several studies have been conducted with thegoal of edifying common limitations in this process, mainly aimingat understanding the role of communication, collaboration andcooperation between stakeholders. Nevertheless, despite of theresearch efforts, it still remains unclear how to overcome limita-tions that can account for 6070% of projects that fail to deliveron time, on cost and with the scope originally promised , costingaround 80100 times more if discovered at the implementationstage and are very hard to fix .
Since communication is critical, requirement elicitation toolsmust ease this communication between stakeholders in order toarticulate their needs collaboratively, allowing their meetings evenat a different time and place to discuss those needs. In this context,game-based tools can bring numerous benefits to this processsince they typically provide immediate feedback, active participa-tion and the high motivation promoted by the competitive envi-ronment .
Recent research as proved the benefits of adding game mechan-ics to common tasks outside the traditional video games environ-ments , including motivational benefits to participate in onlinecommunities. This approach is commonly referred in the literature
336 C. Ribeiro et al. / Entertainment Computing 5 (2014) 335345as gamification, a concept that is already used in numerousapplications ranging across productivity, finance, health, educa-tion, sustainability, as well as news and entertainment media .
The paper aims to evaluate the effectiveness and acceptance ofiThink system , a RE tool, which was developed by using agamification approach and the Six Thinking Hats method. The doc-ument also makes a discussion of the implication and outcomes ofimproving stakeholders collaboration. The evaluation was basedon Action Research in real world organizations: Action Researchallowed us contributing with practical actions on the organizationand generating knowledge about its context on the real world sit-uations. We performed two Action Research cycles: we studied theproblematic situation of the first environment, applied an action,evaluated the results and extracted lessons learnt. In the secondcycle we also studied the situation taking into account the lessonslearnt from the first cycle, applied an action with iThink, evaluatedthe results and extracted other lessons [10,11].2. Requirements elicitation
As stated by Avison and Fitzgerald , the definition ofrequirements can be problematic, but in relation to informationsystems, it can be said to be everything that the set of relevantstakeholders want from a system. Requirements are, indeed, thekey information in Information Systems Development: they trans-late stakeholders needs, determining what and how the Informa-tion System will operate [12,13].
Despite many years of computing and research efforts in therequirements elicitation field, this activity is still not well under-stood. Errors still happen on the requirements elicitation activityand still represent major causes for the failure or even the suspen-sion of the entire information system project [12,13].2.1. Ineffectiveness
Many authors have been studying the reasons of the ineffective-ness of requirements elicitation activity. For example, Avison andFitzgerald  stated that analysts may not identify all the relevantstakeholders and just capture requirements from a small set ofusers, raising costly fixes when the time comes to identify forgot-ten requirements. They also state that stakeholders time con-straints to participate in the elicitation activity promote missedrequirements. Finally, they refer that analysts misinterpretrequirements because of the culture gap or may miss require-ments leaving the specification incomplete.
Zowghi and Coulin  categorized issues and pitfalls in therequirements elicitation activity based on their revision of the lit-erature and their empirical experience. Their categories of issueswere particularity and uniqueness of process and project; complexcommunication between stakeholders and analysts; quality ofidentified requirements; conflicts of interests; and experience ofthe analyst.
Davey and Cope  enumerated quite a few problems withrequirements, including incomplete, ambiguous, incorrect, exces-sive and inconsistent requirements. Also, they suggested otherproblems such as poor users collaboration, unnecessary designconsiderations, different views of different users or continuousacceptance of additional requirements.
Resuming, practitioners consider requirements as main reasonsfor project failures. Within this field of study, there are numerousauthors that believe that problems begin with the complex andintense communication between disparate communities involvedin the requirements elicitation activity [14,15]. On the one hand,stakeholders do not always know what they want or how toarticulate their needs. On the other hand, analysts may not entirelyunderstand business concepts, misinterpreting required needs .
2.2. Trends from social sciences
Requirements elicitation is based on communication. As such,the social nature of this activity is undeniable . Previous works,have tried to address the ineffectiveness of requirements elicita-tion activity that result form this social nature as described inthe previous section. Namely, recent trends have been studyingand using a range of methods derived from social sciences in orderto increase chances of success of requirements elicitation. Thesemethods include: ethnography, interviews and domain group work. Ethnography focuses the observation of people in their natu-ral environment, translating stakeholders activities and interac-tions. Some researchers claim that ethnography may havesatisfactory results eliciting requirements . Nevertheless, sev-eral limitations were also recognized, such as risk of incorrectinterpretations, impossibility of identifying new requirements ordifficulty of generalizing r