Distributed Requirements Elicitation Using A Spatial Hypertext Wiki

Carlos Solı́sLero, the Irish Software Engineering Research Centre

University of LimerickLimerick, Ireland

Email:Carlos.Solis@lero.ie

Nour AliLero, the Irish Software Engineering Research Centre

University of LimerickLimerick, Ireland

Email:Nour.Ali@lero.ie

Abstract—In Global Software Development (GSD), dis-tributed stakeholders (e.g. team members, customers, etc) haveto collaborate and communicate in an efficient and effectiveway to share, create and discuss knowledge. Nowadays, achallenge is to provide integrated collaborative tools thatimplement creativity techniques which allow distributed stake-holders to externalize their knowledge through brainstormingand share and store knowledge in a common repository. TheRequirements Elicitation (RE) process is a clear example wherethis kind of support is needed in the software developmentprocess. This paper presents the Spatial Hypertext Wiki as acollaborative tool for supporting creativity in the RE process.The Spatial Hypertext characteristics of the wiki providea virtual board where distributed stakeholders can share,brainstorm, negotiate, or prioritize the knowledge involved inRE.

Keywords-Requirements elicitation, spatial hypertext wiki,ShyWiki, global software development

I. INTRODUCTION

In the current competitive and dynamic economy, softwarecompanies are becoming virtual organizations that distributetheir projects on multi-sites seeking for specific skills orexpertise, or to reduce costs [1]. However, many challengesexist in this kind of software development, essentially theones related to coordination over distance [2].

In any project, Requirements Elicitation (RE) is a criticalphase due to the fact that most software project failures arecaused from inadequate requirements [3]. The RE phaseis the first step in the requirements engineering process,in which the requirements or needs that a system has tosatisfy are discovered [4]. Requirements elicitation is acreative process in which all stakeholders collaborate inthe creation of the needs that describe a new system [5].The stakeholders involved in the requirements elicitationprocess must understand a domain, and the problems thatthe different stakeholders want to solve using a softwaresystem. Some of the proposed needs will become systemrequirements after their negotiation and prioritization [4]. Inrequirements elicitation, diverse methods are used such asinterviews, workshops, brainstorming, and protocol analysis[6].

In a global software development context, the distributionof the stakeholders adds additional difficulties to the require-

ments elicitation. When collocated software development isfollowed, requirements elicitation is a face to face activitythat can be performed using interviews or requirementsworkshops. However, in the case of geographically dis-tributed teams, face to face communication cannot be pos-sible due to distance or time differences. Teams have usedasynchronous communications such as emails to overcomethese problems. However, interchanging huge volume ofemails is difficult to track [7]. Requirements negotiationin global software development is an essential challengeto be overcome [2]. Tools have to be provided in order tosupport distributed RE in a similar way to the traditional REmethods in collocated environments such as brainstorming,and workshops.

Wikis are tools for distributed and collaborative work,and they can be used to solve problems behind distributedrequirements elicitation [8]. A wiki is a web based softwarethat allows the collaborative and incremental creation of hy-perlinked web pages [9]. Wikis are based on the principles ofeasy of use, incremental content creation, open structure forediting and evolution, and self organized structure [10]. Thecontent in a wiki page is defined by using a simple mark-up language, which allows the user to format the contentand create hyperlinks. In this way, users do not have to betechnical experts in the edition and design of hypertext. Thecreation of new wiki pages is achieved simply by navigatingthrough a link. In addition, most wikis provide versioningfacilities, which permit reviewing previous versions of wikipages or the roll-back of unwanted changes. A good exampleof the success of the wiki concept in the web is Wikipedia[11].

Wikis have been used in global software developmentprojects to communicate, coordinate, track, discuss, test anddocument the work [7], [12], [13]. For example, in OpenSource Software (OSS) projects where the developmentis performed by a community which is often distributed,wikis and forums are becoming the most used tools forrequirements elicitation [14]. Wikis permit requirements anddomain languages to be captured. According to Asmariand Yu, wikis are easier to use, more reliable and cheaperthan other tools for communication and coordination indistributed development [12].

2010 International Conference on Global Software Engineering

978-0-7695-4122-8/10 $26.00 © 2010 IEEE

DOI 10.1109/ICGSE.2010.35

237

A basic technique in the elicitation process is brainstorm-ing. However, wikis are not well suited for supporting col-laborative brainstorming because they lack of a virtual black-board. An essential feature to be provided for brainstormingis the capability of allowing participants to collaborate byreorganizing spatially notes (which contain ideas, or certainknowledge). Without this characteristic, the emergence ofideas and creativity is limited [15].

This paper presents a spatial hypertext wiki (ShyWiki)for requirements elicitation. The wiki principles providesto ShyWiki easy to use characteristics. Spatial hypertext[16] facilitates the externalization of tacit knowledge andpermits to manipulate the requirements in a spatial black-board. Thus, each wiki page can be seen as a virtual boardwhere distributed stakeholders can add, move, or groupnotes. The requirements elicitation process supported byShyWiki is based on the KJ externalization method [17], andEasyWinWin [18] elicitation process which provides supportto the negotiation and prioritization of requirements.

This paper is structured as follows: section II presentsthe background consisting of an explanation of what spatialhypertext is, and a brief description of the WinWin [19] andEasyWinWin [18] requirements elicitation methods. SectionIII explains why the spatial manipulation of the requirementsis important in brainstorming elicitation. Section IV gives anoverview of the Spatial Hypertext Wiki. Section V explainsShyWiki support to requirements elicitation. Section VIpresents the related works. Section VII discusses someproperties of ShyWiki, and how the requirements elicitationprocess is supported by ShyWiki in comparison to theEasyWinWin tool. Finally section VIII gives the conclusionsand future work.

II. BACKGROUND

A. Spatial Hypertext

In 1968, Engelbart implemented the first hypertext system[20] called the “oN-Line System” (NLS) which providedhyperlinks that connected documents. This kind of hypertextis called document centred. However, using this kind ofnavigation in large networks of documents, users can getlost in the hyperspace [21]. A way to solve such problem isby using map based hypertext, which shows explicitly therelations among hypertext documents [22]. Another way, isby using implicit relations.

Spatial hypertext [16] is a kind of hypermedia that is basedon using visual and spatial characteristics to define relationsamong hypertext elements, which are seen as “sticky notes”or bibliographic cards that can hold hypermedia content(text, images, hyperlinks, etc.). Spatial hypertext can rep-resent implicit hypertext structures, which are interpreteddepending on the note’s spatial context [23]. In this way,the relations that are explicit in the map based approach arerepresented implicitly by using visual and spatial character-istics, therefore, hyperlinks become implicit.

The relations of elements in spatial hypertext can berepresented in several ways: the notes in the document canbe positioned to form lists, stacks or only being near eachother. Also, notes of the same type can be represented bysharing the same visual and spatial characteristics: colour,borders, font types, adornments, layout, position, proximity,geometric relations, etc. The notes can be contained insideother notes, creating collections.

Spatial hypertext systems have special facilities in theiruser interface [16]. For example, users can handle and movenotes from one place to another in a hypertext document, orcan change their visual properties or their size. This way oforganizing the information allows users to describe complexrelations among notes.

B. WinWin and EasyWinWin

The WinWin Method [19] is a requirements negotiationapproach where each stakeholder expresses her or his systemneeds as a list of winning conditions. When a winningcondition has conflicts with the winning conditions proposedby other stakeholders, a win-lose situation happens [24].WinWin provides principles and practices for finding win-win conditions shared among stakeholders of the project.

In WinWin, a conflict among winning conditions of dif-ferent stakeholders is called an issue. An issue is associatedwith the conflicting winning conditions, and has a descrip-tion of the conflict. For solving an issue, the stakeholderspropose alternative solutions which are called options. Then,the stakeholders have to evaluate the options and selector reject some of them. After several iterations over theoptions list, the stakeholders can have an agreement aboutthe solution adopted. During the negotiation process, domainterms appear in the descriptions of the winning conditions,issues, options and agreements. These domain terms have tobe defined in a glossary, and structured in domain taxonomy.

EasyWinWin [18] is a lightweight WinWin method thathas lower entry barriers for all the stakeholders. In EasyWin-Win stakeholders define their winning conditions throughbrainstorming. The stakeholders collaboratively define theirwinning conditions in an electronic brainstorming tool. Inthis way, they can share and view the different availablewinning conditions. The win conditions that are similar toothers can be merged. As a result, a new win condition iscreated. The previous brainstorming statements are attachedto the winning condition in order to preserve the rationale.In addition, the winning conditions can be organized ina taxonomy. For instance, a winning condition can be arefinement of others.

In the next step, the stakeholders prioritize the winningconditions in order to define their importance. The priori-tization has two perspectives, the business perspective, andthe ease of realization. The first one defines the importancefor the business organization, and the second the perceiveddifficulty of achievement. Both perspectives are measured in

238

the scale from 1 to 10, being 1 unimportant and difficult,and 10 very important and easy. After, the prioritization stepit can be observed which tasks are important and easy toaccomplish, which are important and hard, which are easyto do but without importance, and which tasks will not beperformed for being difficult and without importance.

The EasyWinWin tool is a collaborative groupware sys-tem, which has been used in more than 50 projects [25],and it has succeeded in capturing the initial requirementsof those projects. However, EasyWinWin lacks flexibilitywhen the requirements evolve, cannot link other informationresources in a local or distributed repository, is difficult toshare relevant information for the requirements, and is notas easy to use as wikis [26].

III. THE IMPORTANCE OF SPACE IN BRAINSTORMING

The concept of tacit knowledge was defined by Polanyias knowledge that cannot be easily shared. Tacit knowledgeis composed of intuitions, unarticulated mental models, ortechnical skills [27], [28]. Tacit knowledge is personal,context specific, and hard to communicate to others. Tacitknowledge has individual cognitive elements such as mentalmaps, beliefs, paradigms and viewpoints, and concrete tech-nical elements know-how, and context specific skills [29].Tacit knowledge in organizations is related to undocumentedwork practices that workers use to take decisions. In addi-tion, much of the knowledge about a future system is tacit[28].

On the other hand, explicit knowledge is articulated,codified, and can be communicated in natural or symboliclanguages [28]. When the stakeholders try to express theirrequirements, they are converting part of their tacit knowl-edge of the system into explicit. Requirements have tocapture this undocumented knowledge in order to have acomplete specification of the system.

The use of creativity techniques is indispensable in the re-quirements elicitation process, because creative stakeholderscan think in an innovative way [30]. Creative stakeholdersare an important factor in the innovation of the companies[31]. That fact has been confirmed by researches that haveapplied the creativity techniques during the elicitation pro-cess [32]. According to Mich et.al. [33], brainstorming ismost the used creativity technique for requirements elicita-tion.

Externalization is the process in which tacit knowledgeof an expert is transformed into explicit [28]. A techniquecommonly used for externalization is the Kawakita Jiro(KJ) method [17] which is used by Japanese companiesto evaluate and organize information [34]. The KJ methodconsists of the following phases: In the first phase, ideas aregenerated and written on adhesive notes without any eval-uation or critique. In the second phase, ideas are grouped.If the ideas are related, they create a spatial group of ideas,which is created by moving related notes to the same space.

In the third phase, the goal is to create a consensus about thesolution to be adopted. In this phase, the groups of ideas arecategorized, i.e., ideas of a group are considered to be thebest solution, then the second, and so on. For example, whenan idea on an adhesive note describes a better solution thanthe others, it can be put over the other notes. The nominalgroup technique [35] adds a voting step to the brainstorming,where each participant votes about the risks in the realizationof the ideas.

Cox and Greenberg define collaborative interpretationas the activity of transforming information fragments intocoherent descriptions, and where emergence of ideas hap-pens [15]. Externalization is a collaborative interpretationtask. Software tools that support emergence of ideas andcollaborative interpretation need to satisfy the followingrequirements [15]: provide a spatial visual workspace, letpeople express relations among data using spatial proximity,allow free-form annotation of the underlying space, andallow the free creation and movement of data in the space.

None of the above mentioned requirements are supportedby current wiki technologies. On the other hand, collabora-tive interpretation tools such as Gungen DX II [36] do notprovide wiki features. Wikis can be adapted to the specificneeds of the business, provide a common information repos-itory and can use hyperlinks for structuring information. Anintegrative collaborative tool which combines the featuresof collaborative interpretation tools and wikis can improvecollaboration in global software development.

IV. OVERVIEW OF SHYWIKI

ShyWiki [37], [38] is a wiki which uses spatial hypertextfor representing its content. On a ShyWiki page, eachelement is similar to an adhesive note. The content of thewiki pages is spatially organized: notes may be placed indifferent regions, moved around, and can be of differentsizes and colors (see Figure 1). Each of these notes cancontain elements of formatted text, images or other types ofmedia. The purpose of the notes is to define the attributesthat characterize the concept represented by a wiki page.Properties of notes such as their colors or positions are usedfor relating them.

Figure 2 summarizes the ShyWiki Hypertext Model. TheShyWikiWeb is composed of information and knowledgestored in WikiPages connected by hyperlinks. WikiPages areidentified by a unique name and are composed of notes.The AbstractNote class includes the properties which arecommon to other kinds of notes: position (x,y), width,height, color, etc. ContentNotes hold content of differenthypermedia types and can be composed of other Content-Notes. A TranscludedNote is a note whose content is definedby another note, it is a reference to another note.

ShyWiki can represent structured data by means of tem-plates, and labeled hyperlinks [39]. A template is a wikipage that can be instantiated into many wiki pages, hence

239

Figure 1. A wiki page in ShyWiki

Figure 2. ShyWiki Model

providing reusability. Notes defined in a template, are alsocreated in its wiki page instances. In addition, during thedefinition of a template, the associations that instances canhave with other concepts can be indicated as well as theircardinalities. A labeled hyperlink is a link with a type. Inthis way, users can define the semantics of the associationrepresented by a hyperlink.

ShyWiki supports the model in Figure 2 by providingbasic operations to create or modify wiki pages. In theedition mode, a user can perform the following actions:creating wiki pages, creating, editing, moving, grouping andtranscluding notes, and creating and instantiating templates.In addition, ShyWiki has a versioning component that per-mits previous versions of a wiki page to be tracked, as wellas a search component for locating text or phrases.

V. REQUIREMENTS ELICITATION IN SHYWIKI

The elicitation process supported by ShyWiki is based onthe KJ method [17], the Nominal Group Technique [35], andEasyWinWin [18]. Figure 3 presents the activities flow inthe ShyWiki elicitation process: initial setup, requirements

generation, grouping, capturing domain language, prioriti-zation, and refinement. Although Figure 3 shows that theprocess ends after refinement, ShyWiki does not restrict this.Brainstorming can be performed many times before the REprocess ends. These activities are explained in the following.

A. Initial setup

The initial setup consists of identifying the initial stake-holders, and requirements categories (in EasyWinWin theyare called win categories). The identification of stakehold-ers helps participants to understand the social context inwhich the project will take place. In the initial session, thesoftware system is divided into categories of negotiationtopics. For example, if WinWin method is followed, thefive requirement categories can be included [19]: projectwin condition, capability win condition, system interface wincondition, level of service win condition, and evolutionarywin condition. The categories to include in a project can benegotiated in a previous brainstorming session.

ShyWiki provides a setup page that builds a wiki pagefor the project, a wiki page with the stakeholders list,

240

Figure 3. ShyWiki Elicitation Activitities

Figure 4. Project setup interface

a wiki page for each stakeholder, a wiki page with theinitial requirements categories, and a glossary wiki page (seeFigure 4). The wikipage of each stakeholder is an instanceof a template called stakeholder. The stakeholder templateincludes the following information: name, email, phone, androle in the project.

B. Requirements Generation

ShyWiki supports externalizing stakeholders’ interestthrough the brainstorming technique. A brainstorming ses-sion has to be performed for each requirement category. Inthis step, the system to develop can be seen as a problem tosolve, and the requirements are the solution to that problem.A brainstorming has a divergent phase where the possibleideas are expressed without criticism. The goal of this phaseis to collect as many ideas as possible.

ShyWiki has many advantages over traditional brainstorm-ing and brainwriting. By using ShyWiki, there is no need

for a room with a blackboard or paper notes. The sessionparticipants can be geographically distributed. ShyWiki cansupport different brainstorming sessions in parallel, one foreach team working on a particular problem or category.In addition, an idea in a brainstorming session can beexpanded in other brainstorming sessions in order to reducethe complexity and produce ideas with better quality [40].Therefore, if there are many complex requirements, theproblems related to them can be analyzed using nestedbrainstorming sessions.

The participants can easily enrich other notes, by addingnew content to the original ones, or by adding annotations tothem. The drag and drop facilities aid in grouping ideas. Inaddition, ideas can be classified using background or bordercolours. As a result, the relations that can be expressedamong ShyWikis’ notes are richer and easier to manipulatethan the blackboard or paper based techniques. ShyWiki canautomatically preserve a brainstorming session, which canbe reconstructed if required later on. Furthermore, the use ofthe versioning facility of a ShyWiki page can enable usersto track the path followed by a team to make a decision. Forexample, Figure 1 shows a brainstorming session about thesecurity requirements of a web application.

Figure 5. Adding a requirement note

Any wiki page in ShyWiki can be a blackboard usedfor brainstorming. If a new requirement has to be addedto the board, the stakeholders have to add a new note oftype requirement (see figure 5), and define the name anddescription of the requirement.

C. Grouping

In this step, the stakeholders that participate in the brain-storming session, have to eliminate redundant and ambigu-ous requirements. With the remaining requirements, groupsof related requirements are made by finding out whether arequirement can be part of another one and merging similarrequirements together. Each group of requirements has toreceive a name. If a new requirement occurs to someone,then it can also be added to a group. Stakeholders can usethe grouping and spatial properties of ShyWiki in order toorganize the clusters and hierarchies of requirements.

241

D. Capturing domain language

The project wiki page includes a hyperlink to the glossaryof terms that will be used in the communication process ofthe stakeholders. Stakeholders might use the same word withdifferent meanings. This is an essential step to be taken sinceunderstanding the accurate meaning of terms helps in re-ducing ambiguity and thus reducing misunderstandings andmiscommunication. In this way, the different stakeholderscan be aware of the terms, and can speak a common domainlanguage.

The first step is to add the new terms to the projectglossary. The definition of the new terms is explained withdetail in the wiki page corresponding to the term name. Theopen nature of wikis permits any stakeholder to participatein the definition of a term. In addition, the versioningcapability of the wiki allows the stakeholders to observethe evolution of the definition. The definition of the termscan be performed incrementally during the grouping step. Inthe post-it notes of the brainstorming sessions, some termsof the domain language are mentioned. For each term in thedomain language, a wiki link could be added to the postit note to allow the users to navigate to the definition andcheck the meaning of the terms. For example, in Figure 1the note about secure coding has hyperlinks to the termsSQL injection and stack overflow.

E. Prioritization

ShyWiki allows stakeholders to vote about the importanceand difficulty of a requirement. A stakeholder can assign avalue from 1 to 10 to them. The voting action can only beperformed in wiki pages that are instances of the requirementtemplate. The voting interface is shown in Figure 6.

Figure 6. Voting the priority of a requirement

In ShyWiki, any wiki page that includes notes which rep-resent requirements (instance of the requirement template)has a hyperlink that permits visualizing their priority. Asa result, a web page that shows the list of requirementscontained in the wiki page ordered by priority is available(see Figure 7). The list is ordered according to the require-ments importance to the business, and by their difficulty. Ifthe importance or difficulty is greater than 5, then they areshown in green colour. Otherwise, they are shown in red.

Figure 7. Prioritization of a set of requirements

F. Refinement

The refinement of a requirement represented by a note,can be performed in the wiki page associated to a note. Inthis step, the requirements are defined with more precisionand detail, which is often called requirements modeling [3].We have defined a set of templates for refining requirements.Figure 8 shows the UML model of the templates definedand their relations. The templates are: requirement, project,stakeholder, option, and agreement, and the empty templatesstatus, priority and difficulty. The status template has theinstances accepted, rejected, and pending. The priority anddifficulty templates have the instances low, medium and high.

Figure 8. UML model of the RE templates and their relations

Figure 9 shows the requirement template, which includesthe following properties: name, number, description, andcomments. The name property indicates a very short descrip-tion of the requirement. The number property is to providea requirement identifier. In the description property the userhas to indicate a detailed explanation of the requirement pro-viding its rationale, concerns, and conditions to satisfy. Thecomments property is used to indicate relevant issues aboutthe requirement. The template also shows the followingrelations: status, priority, difficulty, stakeholder, options, andagreements. The relations status, priority, difficulty are 1 to0..1, while the relations stakeholder, options, and agreementsare 1 to 0..N.

Instances creation is associated with users navigation.For example, Figure 5 shows how the user added the datavalidation requirement to the security requirements wiki

242

Figure 9. Requirement Template

page in Figure 1. When the hyperlink that points to thedata validation wiki page is navigated for the first time,the wiki page is created as an instance of the requirementtemplate. Figure 10 shows the instance of the requirementdata validation. It can also be observed that the require-ment instances show the average importance, and difficultyresulting of stakeholders’ votes. The stakeholders involvedin this requirement, Cristobal and John, were selected fromthe stakeholders list, which is shown to the user when a noterepresenting the stakeholder relationship is edited.

Figure 10. Requirement instance

VI. RELATED WORK

In this section, other tools that have been used for globaland distributed requirements elicitation are presented, focus-ing on wikis.

RequisitePro [41], Doors [42], CaliberRM [43] are elicita-tion tools that provide support to capturing requirements andtraceability, and provide a desktop and a web interface. Ac-cording to Sinha et.al. [44], they lack “deep integration be-tween the requirements and communication environments”.EGRET (Eclipsebased global requirements tool) [44] is aneclipse plug-in for distributed requirements management.It allows distributed stakeholders to share a repository of

requirements and include contextual communication aroundthe requirements.

Many wikis have been adapted for capturing softwareengineering requirements. The viability of wikis for require-ments elicitation has been demonstrated by their use inindustrial and academic projects [8], [26], [45].

WikiWinWin [26] is a wiki that implements the WinWinmethod. It is based on web forms. Therefore, WikiWinWindoes not support the main characteristic of ShyWiki whichare facilitates for supporting the emergence of ideas and thecollaborative interpretation.

SOP-wiki [8] uses semantic media wiki to capture re-quirements. In addition, SOP-wiki has an especial exten-sion for presenting links to the wiki pages that representrequirements documents (requirements, use case, actor, etc.).SOP-wiki permits the creation of release versions, and theexportation of the requirements to open office. SOP-wiki hasbeen used in several academic and industrial projects.

SoftWiki Ontology for Requirements Engineering(SWORE) [46] is an ontology for representing requirementsdefined in the Web Ontology Language (OWL). Theinstances of the ontology are managed and captured usingthe semantic wiki OntoWiki [47].

SmartWiki for requirements engineering [45], is based onsemantic media wiki with templates for requirements engi-neering. Their templates are based on the use case templatesof Cockburn. In addition, it provides functions for projectmanagement. ProjectIT-Enterprise [48] is another semanticwiki with templates, and project management support.

In general, wikis used for requirements engineering pro-vide wiki templates, and typed relationships that permit todefine the semantics of objects and relations in the domainof requirements engineering. They provide templates forstakeholders, uses cases, user stories, projects, etc. ShyWikican define templates and relations, and it is possible to definea conceptual model for requirement engineering in eachproject. Complex ontologies for requirements elicitation,such as the one provided by SoftWiki, have the problem ofcognitive overhead due to the fact that it imposes a structureto stakeholders argumentation.

Although, requirements elicitation uses brainstorming forcapturing and prioritizing requirements, all the mentionedwikis do not have adequate support for this activity. EvenWikiWinWin, which uses brainstorming as a central element,does not provide support for collaborative interpretation i.e.a virtual board. The main difference between ShyWiki andthe other wikis is that ShyWiki satisfies the requirementsthat a tool has to comply in order to facilitate collaborativeinterpretation tasks.

VII. DISCUSSION

This section presents how the requirements elicitationprocess is supported by ShyWiki in comparison to the Easy-

243

Table IEVALUATION OF SHYWIKI FOR RE

EasyWinWin tool WikiWinWin ShyWikiSupport of WinWin approach *** *** ***Easy exchange of ideas and knowledge ** *** ***Easy to update and preserve the revision history * *** ***Easy to extend ** *** ***Easy to incorporate boundary objects ** *** ***Support synchronous collaboration *** * *Release and baseline requirements *** *** ***Automation of content management *** ** **Exporting the content *** ** ***Collaborative interpretation *** * ***Support to structured information * * ***Hypermedia support *** ***

WinWin tool [18] and the WikiWinWin and also discussessome of ShyWikis properties.

Table I shows the comparison. The evaluated points (withexception of the last three) and rating scale used in TableI were proposed by Yang et.al [26] for comparing Wikis,WikiWinWin and the EasyWinWin tool. The rating scale isthe following: (.) not supported, (*) marginal, (**) accept-able, and (***) excellent. In addition, the values assignedto EasyWinWin and WikiWinWin are the result of theevaluation performed in [26].

ShyWiki supports the EasyWinWin process well, and pro-vides easy ways to exchange ideas and knowledge among thestakeholders in the project. The version module of ShyWikipreserves the history of the requirements, and brainstormingsessions. ShyWiki can be extended by means of the templatemechanism. Users can add new templates and alter thestructure of the existent ones. Boundary objects can be addedby means of new wiki pages, and hyperlinks. ShyWiki doesnot support synchronous collaboration. However, we havean alpha version of the synchronous collaborative editionwhich is based on HTTP Streaming technology.

ShyWiki templates can partially provide consistency tothe structure of the wiki. However, ShyWiki does not havea mechanism to enforce the consistency of the whole wiki.To support release and baseline requirements, a datetimeparameter is added to the hyperlinks, and it is used to getthe version of the target wiki page that was alive in thatmoment of time. The information stored in the wiki can beread by other applications by using the RDF projections ofthe wiki pages as described in [39].

ShyWiki can implement lightweight knowledge sharingworkspaces for architecture knowledge management [49].ShyWiki facilitates the annotation of architectures, providesproject activity awareness through transclusion and implicitspatial semantics, and gives decisions support using brain-storming. In this way, it is possible to trace the requirementswith the architecture, and with other software engineeringartifacts using the shared information repository that permitsdistributed access, and asynchronous collaboration.

The use of cards for user stories, and the definition of

tasks is essential in many agile methods. When a projectis distributed, teams need tools to support iteration planningand management. Wikis have been used successfully in agileplanning. However, it has been observed that they do notprovide spatial features which are needed to organize post-it notes in a similar way to a collocated meeting [50]. InShyWiki, teams can share a single blackboard or each teamcan have its own one depending on the distribution of thedevelopment tasks and the skills needed to solve them.

ShyWiki provides a board that can be used for planningand managing software tasks which is another issue thathas to be solved by global software development tools. Forexample, it can be used in agile development methods suchas Scrum [51] or Extreme Programming [52] for performinga distributed planning game. Experiences in implementingagile practices in a distributed setting have shown that anessential factor is to have tools that allow a team to shareand collaborate using a board among distributed teams [53],[54].

VIII. CONCLUSIONS AND FUTURE WORK

The requirements elicitation process can take advantageof wikis because they provide support for the open collab-oration among stakeholders, and low entry barriers. Wikisfacilitate the collaborative exchange of ideas, information,and can trace changes by means of versioning.

ShyWiki provides support for distributed and collaborativerequirements elicitation process based on the KJ methodand EasyWinWin. ShyWiki allows the stakeholders to ma-nipulate spatially the requirements. They can group, relateor merge them easily. In this way, the negotiation andprioritization process can be done through the wiki pageswhich are virtual blackboards that hold hypertext card notes.ShyWiki also provides stakeholders with a virtual envi-ronment that supports the emergence of ideas. This factoris relevant for the definition of innovative requirements,and for facilitating the transfer of tacit knowledge to therequirements definitions.

ShyWiki is an Integrated Collaborative tool for globalsoftware development. It provides features for viewing

244

and discussing software artifacts, as well as collaborationthrough the virtual boards. According to Laredo and Ra-jan [7]: “tools should fill the vacuum left by traditionalconference room and the white board and get the team tocollaborate in a given context”. ShyWiki can be this kind oftool.

We are currently performing several experiments to vali-date the usability of ShyWiki in requirements engineeringand software architecture design. We are also extendingsome of ShyWikis groupware support such as providingsynchronous communication. In addition, we are workingon using ShyWiki in global software development projects.

ACKNOWLEDGMENTS

This work has been funded by Science Foundation Irelandgrant 03/CE2/I303 1 to LERO - the Irish Software Engineer-ing Research Centre (http://www.lero.ie).

REFERENCES

[1] J. D. Herbsleb and D. Moitra, “Global software development,”IEEE Software, vol. 18, no. 2, 2001.

[2] J. D. Herbsleb, “Global software engineering: The future ofsocio-technical coordination,” in Workshop on the Future ofSoftware Engineering, FOSE 2007, 2007, pp. 188–198.

[3] H. Hofmann and F. Lehner, “Requirements engineering as asuccess factor in software projects,” Software, IEEE, vol. 18,no. 4, pp. 58–66, Jul/Aug 2001.

[4] I. Sommerville and P. Sawyer, Requirements Engineering: AGood Practice Guide. John Wiley & Sons, June 2004.

[5] S. Robertson, “Requirements trawling: techniques for dis-covering requirements,” International Journal of Human-Computer Studies, vol. 55, no. 4, pp. 405–421, 2001.

[6] A. Davis, O. Dieste, A. Hickey, N. Juristo, and A. Moreno,“Effectiveness of requirements elicitation techniques: Empir-ical results derived from a systematic review,” in , 14th IEEEInternational Conference of Requirements Engineering, 2006,pp. 179–188.

[7] J. A. Laredo and R. Ranjan, “Continuous improvementthrough iterative development in a multi-geography,” inICGSE ’08: Proceedings of the 2008 IEEE InternationalConference on Global Software Engineering. Washington,DC, USA: IEEE Computer Society, 2008, pp. 232–236.

[8] B. Decker, E. Ras, J. Rech, P. Jaubert, and M. Rieth, “Wiki-based stakeholder participation in requirements engineering,”IEEE Software, vol. 24, no. 2, pp. 28–35, 2007.

[9] B. Leuf and W. Cunningham, The Wiki way: quick collabora-tion on the Web. Boston, USA: Addison-Wesley Longman,2001.

[10] W. Cunningham, “Design principles of wiki: how can solittle do so much?” in WikiSym ’06: Proceedings of the 2006international symposium on Wikis. New York, NY, USA:ACM, 2006, pp. 13–14.

[11] “Wikipedia, the free encyclopedia,”http://www.wikipedia.org.

[12] K. Al-Asmari and L. Yu, “Experiences in distributed softwaredevelopment with wiki,” in Software Engineering Researchand Practice. CSREA Press, 2006, pp. 389–293.

[13] P. Louridas, “Using wikis in software development,” Software,IEEE, vol. 23, no. 2, pp. 88–91, March-April 2006.

[14] P. Laurent and J. Cleland-Huang, “Lessons learned from opensource projects for facilitating online requirements processes,”in REFSQ ’09: Proceedings of the 15th International WorkingConference on Requirements Engineering: Foundation forSoftware Quality. Berlin, Heidelberg: Springer-Verlag, 2009,pp. 240–255.

[15] D. Cox and S. Greenberg, “Supporting collaborative interpre-tation in distributed groupware,” in CSCW ’00: Proceedingsof the 2000 ACM conference on Computer supported cooper-ative work. New York, NY, USA: ACM, 2000, pp. 289–298.

[16] C. C. Marshall and F. M. Shipman, “Spatial hypertext: de-signing for change,” Communications of ACM, vol. 38, no. 8,pp. 88–97, 1995.

[17] J. Kawakita, The original KJ-method. Kawakita ResearchInstitute, 1982.

[18] P. Gruenbacher, “Collaborative requirements negotiation witheasywinwin,” in DEXA ’00: Proceedings of the 11th Inter-national Workshop on Database and Expert Systems Appli-cations. Washington, DC, USA: IEEE Computer Society,2000, p. 954.

[19] B. Boehm and H. In, “Identifying quality-requirement con-flicts,” IEEE Software, vol. 13, no. 2, pp. 25–35, 1996.

[20] D. C. Engelbart, “Authorship provisions in augment (reprint),”Computer-supported cooperative work: a book of readings,pp. 107–126, 1988.

[21] M. Bernstein, P. J. Brown, M. Frisse, R. Glushko, P. Zell-weger, and G. Landow, “Structure, navigation, and hypertext:the status of the navigation problem,” in HYPERTEXT ’91:Proceedings of the third annual ACM conference on Hyper-text. New York, NY, USA: ACM, 1991, pp. 363–366.

[22] H. J. Strauss, “Hypermaps: telling your users where to go,”in SIGUCCS ’90: Proceedings of the 18th annual ACMSIGUCCS conference on User services. New York, NY,USA: ACM, 1990, pp. 377–390.

[23] C. C. Marshall and F. M. Shipman, “Searching for the missinglink: Discovering implicit structure in spatial hypertext,” inHypertext’93: Proceedings of the fifth ACM conference onHypertext. ACM, 1993, pp. 217–230.

[24] B. W. Boehm and R. Ross, “Theory-w software projectmanagement principles and examples,” IEEE Trans. Softw.Eng., vol. 15, no. 7, pp. 902–916, 1989.

[25] R. Briggs and P. Gruenbacher, “Easywinwin: managing com-plexity in requirements negotiation with gss,” in Proceedingsof the 35th Annual Hawaii International Conference onSystem Sciences, 2002.

245

[26] D. Yang, D. Wu, S. Koolmanojwong, A. W. Brown, and B. W.Boehm, “Wikiwinwin: A wiki based system for collabora-tive requirements negotiation,” in Proceedings of the AnnualHawaii International Conference on System Sciences, 2008.

[27] M. Polanyi, The Tacit Dimmension. Anchor Books, 1967.

[28] I. Nonaka and H. Takeuchi, The Knowledge-Creating Com-pany. New York: Oxford University Press, 1995.

[29] L. D. Alavi, M., “Review: Knowledge management andknowledge management systems: Conceptual foundations andresearch issues,” MIS Quarterly: Management InformationSystems, vol. 25, no. 1, pp. 107–136, 2001.

[30] N. Maiden, A. Gizikis, and S. Robertson, “Provoking cre-ativity: Imagine what your requirements could be like,” IEEESoftware, vol. 21, pp. 68–75, 2004.

[31] S. Ya and T. Rui, “The influence of stakeholders on technol-ogy innovation: A case study from china,” in Management ofInnovation and Technology, 2006 IEEE International Confer-ence on, vol. 1, June 2006, pp. 295–299.

[32] N. Maiden, S. Manning, S. Robertson, and J. Greenwood,“Integrating creativity workshops into structured requirementsprocesses,” in DIS ’04: Proceedings of the 5th conference onDesigning interactive systems. New York, NY, USA: ACM,2004, pp. 113–122.

[33] L. Mich, C. Anesi, and D. Berry, “Applying a pragmatics-based creativity-fostering technique to requirements elicita-tion,” Requirements Engineering, vol. 10, no. 4, pp. 262–75,2005.

[34] I. Nonaka, K. Umemoto, and D. Senoo, “From informationprocessing to knowledge creation: A paradigm shift in busi-ness management,” Technology in Society, vol. 18, no. 2, pp.203–218, 1996.

[35] A. Delbecq and A. Van de Ven, “A group process modelfor problem identification and program planning,” Journal ofApplied Behavioral Science, vol. 7, no. 4, pp. 466–492, 1971.

[36] T. Shigenobu, T. Yoshino, and J. Munemori, “Evaluation andapplication of creativity collaboration support system gungendx ii for consensus-building among users,” InternationalJournal of Information Technology and Decision Making,vol. 6, no. 3, pp. 475–490, 2007.

[37] C. Solis and N. Ali, “ShyWiki-a spatial hypertext wiki,” inWikiSym ’08: Proceedings of the 2008 international sympo-sium on Wikis. New York, NY, USA: ACM, 2008.

[38] C. Solis and N. Ali, “ShyWiki-a spatial hypertext wikiprototype (demo),” in WikiSym ’08: Proceedings of the 2008international symposium on Wikis. New York, NY, USA:ACM, 2008.

[39] C. Solis and N. Ali, “A spatial hypertext wiki for knowledgemanagement,” in IEEE 2010 International Symposium onCollaborative Technologies and Systems (CTS 2010). IEEEComputer Society, 2010.

[40] A. R. Dennis, J. S. Valacich, T. A. Carte, M. J. Garfield, B. J.Haley, and J. E. Aronson, “Research report: The effectivenessof multiple dialogues in electronic brainstorming.” Informa-tion Systems Research, vol. 8, no. 2, pp. 203 –, 1997.

[41] IBM, “Rational RequisitePro,”http://www-01.ibm.com/software/awdtools/reqpro/ last ac-cesed on February 2010.

[42] IBM , “Rational Doors,”http://www-01.ibm.com/software/awdtools/doors/ lastaccesed on February 2010.

[43] Borland, “CaliberRM,”http://www.borland.com/us/products/caliber/index.html lastaccesed on February 2010.

[44] V. Sinha, B. Sengupta, and S. Chandra, “Enabling collabora-tion in distributed requirements management,” IEEE Softw.,vol. 23, no. 5, pp. 52–61, 2006.

[45] E. Knauss, O. Brill, I. Kitzmann, and T. Flohr, “Smartwiki:Support for high-quality requirements engineering in a collab-orative setting,” in 2009 ICSE Workshop on Wikis for SoftwareEngineering (Wikis4SE 2009), 2009.

[46] T. Riechert and T. Berger, “Leveraging semantic data wikisfor distributed requirements elicitation,” in 2009 ICSE Work-shop on Wikis for Software Engineering (Wikis4SE 2009),2009, pp. 7 – 13.

[47] M. Hepp, D. Bachlechner, and K. Siorpaes, “Ontowiki:community-driven ontology engineering and ontology usagebased on wikis,” in WikiSym ’06: Proceedings of the 2006international symposium on Wikis. New York, NY, USA:ACM, 2006, pp. 143–144.

[48] D. Ferreira and A. Silva, “An enhanced wiki for requirementsengineering,” in Proceedings of the 2009 35th EuromicroConference on Software Engineering and Advanced Applica-tions (SEAA 2009), Piscataway, NJ, USA, 2009, pp. 87–94.

[49] C. Solis, N. Ali, and A. Babar, “A spatial hypertext wikifor architectural knowledge management,” in InternationalWorkshop on Wikis for Software Engineering. ACM/IEEE,2009.

[50] M. J. Rees, “A feasible user story tool for agile software de-velopment?” Asia-Pacific Software Engineering Conference,vol. 0, p. 22, 2002.

[51] K. Schwaber and M. Beedle, Agile Software Developmentwith Scrum. Upper Saddle River, NJ, USA: Prentice HallPTR, 2001.

[52] K. Beck and C. Andres, Extreme Programming Explained:Embrace Change (2nd Edition). Addison-Wesley Profes-sional, 2004.

[53] H. Smits and G. Pshigoda, “Implementing scrum in a dis-tributed software development organization,” Piscataway, NJ,USA, 2007, pp. 349 – 53.

[54] S. Berczuk, “Back to basics: The role of agile principlesin success with an distributed scrum team,” in AGILE ’07:Proceedings of the AGILE 2007. Washington, DC, USA:IEEE Computer Society, 2007, pp. 382–388.

246