Computers in Industry 64 (2013) 798–812

Contents lists available at SciVerse ScienceDirect

Computers in Industry
journal homepage: www.elsevier.c om/locat e/co mpind

Applying collaborative process design to user requirements elicitation:

A case study
Aida Azadegan a,*, K. Nadia Papamichail b, Pedro Sampaio b
a
Sheffield Business School, Sheffield Hallam University, City Campus, Howard Street, Sheffield S1 1WB, UK
b
Manchester Business School, The University of Manchester, Booth Street West, Manchester M15 6PB, UK

ARTICLEINFO ABSTRACT

Article history: User requirements play a central role in software development processes by bridging the needs of
Received 11 October 2012 business to the software. In many cases stakeholders who have different perspectives and expectations
Received in revised form 14 April 2013 about the future system need to collaborate to clarify, capture and uncover user requirements in an
Accepted 1 May 2013 efficient and effective manner. Many industry experts have admitted that collaboration among
Available online 25 May 2013
stakeholders in a facilitated workshop, aimed at defining and articulating user requirements, is one of
the most difficult tasks in software development. The aim of the research described in this paper is to
Keywords: present a process that can address the challenges of collaborative user requirements elicitation
Collaboration Engineering
workshops. The process contains activities that correspond to a pattern of collaboration. Developed on a
ThinkLet
pattern-based architecture, the process is reusable and can be applied to similar user requirements
Requirements elicitation
Workshop elicitation workshops. To achieve this goal, the principles of Collaboration Engineering (CE) are applied
Group facilitation to design collaborative processes that consist of ThinkLets, a set of facilitation scripts and process-
building blocks, bundled together. The process is evaluated in practice by running facilitated workshops
as well as by collecting experts’ comments and opinions. The results indicate that the approach is usable
and useful. The paper concludes with further elaboration and discussions on research contribution and
potential future work in the field.
© 2013 Elsevier B.V. All rights reserved.

1. Introduction
Requirements Engineering (RE) is a discipline that describes the
tasks that define the requirements of a new or re-designed system
while taking into account the conflicting requirements of various
stakeholders [1]. During the first step of the requirements
engineering process, which is referred to as the requirements
elicitation phase, system requirements are discussed and agreed
by the stakeholders [1].
Requirements engineering is a complex technical, social and
cognitive process, which produces requirements for a software-
intensive system [2]. Requirements elicitation is an important
activity in the requirements engineering process as it involves
discovering and formalizing the system requirements. Require-
ments are the basis for every project, describing the needs of
stakeholders in a potential new system and also what the system
must do in order to satisfy that need. Requirements are discovered
* Corresponding author. Tel.: +44 79 6060 9328.
E-mail addresses: a.azadegan@shu.ac.uk, aida.azadegan@gmail.com
(A. Azadegan), nadia.papamichail@mbs.ac.uk (K.N. Papamichail),
p.sampaio@manchester.ac.uk (P. Sampaio).
not only in software development projects, but also in any other
processes that involves the construction of a new artefact [3–6].
In the last two decades, product design activities such as
requirements elicitation have been moving to a collaborative
environment across extended enterprises, due to the globalization
of markets, the advancement of technologies, the segregation of
customer demands, and the competition at home and abroad [67].
Requirements elicitation, is highly collaborative and involves
many stakeholders: the organizational decision makers who will
decide on the sourcing of the system and negotiate the functional
and non-functional requirements together with the price to be
paid, the user who interacts with it, the domain expert, sales and
marketing representatives and the developers who build it [1,7].
Each stakeholder has different needs, expectations along with their
own experience, prejudices and view points [8] that need to be
satisfied by the introduction and delivery of the future system.
Moreover It is fairly well known that up to 80% of product cost is
determined by the decisions made collaboratively by the
stakeholders in the early stages of requirements life cycle,
therefore, effective management of product design and the ability
of stakeholders to understand what they need and what other
stakeholders expect from the product play an important role in the
entire product lifecycle [67].

0166-3615/$ – see front matter © 2013 Elsevier B.V. All rights reserved.
http://dx.doi.org/10.1016/j.compind.2013.05.001
 A. Azadegan et al. / Computers in Industry 64 (2013) 798–812
Despite having alternative viewpoints about requirements,
collaborating stakeholders aim to reach consensus and agree on
the final list of system requirements [9].
Requirements elicitation is achieved through collaboration.
However, facilitating collaborative requirements elicitation is
often considered as one of the biggest bottlenecks in projects
for the collaborative development of different systems [10]. Expert
facilitators can draw from a repertoire of skills and knowledge to
guide and motivate a group to achieve a specific outcome.
Facilitators use a variety of methods and tools to intervene and
support groups in achieving their goals [11]. Expert facilitators in
teams guide the collaboration process and help stakeholders
combine their viewpoints and understandings to finally reach
agreement over the case in hand. However, this process is
considered to be expensive and can be time-consuming, if the
facilitators need to be trained in-house, and therefore many
organizations need to decrease their dependency on expert
facilitators [12].
Many researchers have studied collaborative requirements
elicitation. In addition to a number of facilitated group approaches
for requirements elicitation such as Joint Application Design (JAD)
[13], Quality Function Deployment (QFD) [14] and Cooperative
Requirements Capture (CRC) [16], several techniques and frame-
works have been proposed that seek to address the challenges of
collaborative requirements elicitation. Laporti et al. [15] present an
approach founded on collective knowledge to progressively build
the system requirements from a narrative of user stories to the
definition of use cases. The approach is a collaborative process to
elicit requirements. Mich et al. [17] describe the problem with
collaborating stakeholders who need to identify and enhance their
viewpoints and are involved with requirements elicitation
processes. They propose a creative technique based on a model
of the pragmatics of communication. The model defines a creative
process that consists of different steps. In each step the problem is
analyzed based on an elementary behaviour identified by the
model. Finally, Haruhiko et al. [18] discuss the problem of
requirements discordances among stakeholders and suggest a
collaborative goal-oriented requirements elicitation method to
address it. Although some of these approaches describe a detailed
procedure on how to discover and elicit requirements they offer
limited support on the issue of how to facilitate requirements
elicitation workshops without an expert facilitator while the
collaborating stakeholders reach consensus over system user
requirements.
In this paper, the authors advocate a different approach to
collaborative requirements elicitation. This approach describes a
step-by-step requirements elicitation collaborative process that:
(a) Supports a group of stakeholders to collaborate in facilitated
user requirements elicitation workshops in order to share their
various viewpoints and achieve a high-level understanding and
consensus of the user requirements of the future system.
(b) Guides non-expert or novice facilitators to achieve successful
delivery of facilitation services.
The approach introduced in this paper is suitable for a group of
stakeholders who need to reach consensus about user require-
ments in a collaborative facilitated workshop. The approach can
also be adopted in similar situations where requirements are to be
collaboratively discovered and agreed by a group of stakeholders.
The paper is organized as follows: Section 2 provides
background information about user requirements, Collaboration
Engineering (CE) and collaborative requirements elicitation work-
shops; in Section 3 the principles of Collaboration Engineering are
used and applied to the field of collaborative user requirements
799
elicitation workshops. We demonstrate the applicability of this
collaborative process using a case-study. Sections 4 and 5 analyze
both the evaluation process and the outcome, providing a critical
assessment of the key contributions of the proposed approach.
2. Background
Software artefacts are derived from user requirements. User
requirements span business and software requirements, thus
bridging the gap between business and the software. User
requirements define the basis of what should be developed in a
software system [19,36].
User requirements have always been difficult to clarify, capture
and articulate. Many industry experts have admitted that defining
them is the most difficult task in software development. For
example, one of the biggest problems is the gap in communication
between software and business people, which results in a low level
of consensus building between both sides. This problem also exists
for both external software development organizations and
software groups supporting internal organizations [36].
In this paper the authors focus on facilitated collaborative
‘‘user’’ requirements elicitation workshops. The authors use
Collaboration Engineering (CE) to deliver a process that satisfies
the recurring need of discovering and capturing the user
requirements in organizations.
2.1. Requirements workshops and facilitation
Requirements workshop is a generic term given to a number of
different types of group meeting where the emphasis is on
developing and discovering requirements for a software system
[10]. A requirements workshop is a structured meeting in which a
selected group of stakeholders collaborate to define the workshop
deliverables that represent user requirements. It is usually a
facilitated group meeting. The workshop deliverables can be in the
form of requirements models such as diagrams, lists or tables that
are used to document users’ needs [36].
There are three levels in user requirements elicitation work-
shops [36]: scoping, high-level and detailed workshops. Over these
three levels user requirements are refined, moving from a high
level of abstraction towards more detailed requirements. In the
scoping workshop a bird’s-eye view is taken to determine which
user requirements should be included. The deliverables from the
scoping workshop clarify the items to be elaborated in the high-
level workshop. The outcome of the high-level workshop is further
refined in the detailed workshop [36].
Different methods are used within requirements workshops
[10], including the cross-functional method, which involves
different types of stakeholders from various areas of the business;
Co-operative Requirements Capture (CRC) [37] and Creativity [38]
which encourage innovative thinking and expression.
Facilitation is the complex skill of enabling a group of people to
complete a task. Griffith et al. [47] describe the facilitator’s role as
one of ‘‘improving a group’s communication and information flow
to enhance the manner in which a group makes decisions without
making those decisions for the group’’. Facilitators help group
members to perform their collective task as a team and manage
relationships between people, tasks and technology. A facilitator
guides the group in reaching an effective decision using appropri-
ate group processes [58]. By helping a group improve its processes,
it can increase the quality of its decision-making processes,
increase group member commitment to the decisions which are
being made, and decrease time for effective implementation [39].
Professional facilitators, however, tend to be expensive to hire,
and the services they provide are not available to a large number of
groups that could benefit from their interventions. Recently
800 A. Azadegan et al. / Computers in Industry 64 (2013) 798–812
researchers have begun to focus on ways that groups can receive
the benefits of facilitation services without engaging with an
expensive facilitator or having facilitation services delivered by
novice or non-expert internal facilitators. This is the main research
idea underlying the literature of Collaboration Engineering [40].
2.2. Collaboration Engineering
Collaboration Engineering is a rapidly evolving design approach
that is used for modelling and deploying repeatable, predictable
and transferable collaboration processes for recurring high-value
collaborative tasks to be executed by the practitioners themselves
[11,41]. de Vreede and Briggs [26] define the scope and key
elements of Collaboration Engineering as follows:
Collaboration Engineering is an approach to create sustained
collaboration support by designing collaborative work practices
for high-value recurring tasks, and deploying those as
collaboration process prescriptions for practitioners to execute
for themselves without ongoing support from professionals.
The collaboration engineer is able to create designs in the form
of a standard, repeatable procedure that can be followed to ensure
a predictable success within a team development effort. Collabo-
ration Engineering offers guidelines to decrease the challenges of
facilitation interventions within a team [42].
It is important for organizations not to be dependent on skilled
facilitators, who may either need to be trained inside the
organization or be hired as expensive external consultants. Instead,
organizations need to leverage effective collaborative processes, and
train ‘‘practitioners’’ to run them [43]. A practitioner is a domain
expert who learns to execute a particular work practice designed by
a collaboration engineer. Practitioners do not need to have the skills
to design or conduct collaborative processes; they execute tasks that
are transferred to them [43,44]. The practitioners are the novice
facilitators, individuals that possess the potential to act as facilitators
by learning the techniques transferred to them using the processes
developed by a collaboration engineer [40].
2.3. Facilitated collaboration using ThinkLets
To design a predictable, transferable, reusable collaboration
process, the Collaboration Engineering approach uses design
patterns called ThinkLets, which can be combined to create a
sequence of steps for a group to execute in order to achieve
collaborative goals [55].
ThinkLets are facilitation building blocks and describe how a
certain task should be performed using pre-defined scripts [45],
that is a set of atomic collaborative activities. Any individual
ThinkLet comprises a named, packaged, thinking activity that is
able to create predictable, repeatable patterns of collaboration, the
approaches that groups use during collaboration [26].
ThinkLets are codified scripts of key facilitation intervention
techniques, used by the collaboration engineer to design standard-
ized and routine collaborative processes that are easily transferred
to practitioners. The ThinkLets enable practitioners to become
independent, through learning the configurations for execution of
the processes. Consequently, practitioners only need to know the
skills that are specific to the process they have in hand, which are
well described and embedded inside Thinklet scripts [53].
ThinkLets are classified according to the patterns of collabora-
tion they create.
Six basic patterns of collaboration have been identified by
Briggs et al. [44]:
(1) Generate: Move from having fewer concepts to having more
concepts, e.g. the directed FreeBrainstorm ThinkLet that
generates a broad and diverse set of highly creative ideas in
response to prompts from a moderator and the ideas
contributed by team mates [60].
(2) Clarify: Move from less to more shared meanings of the
concept(s) under consideration, e.g. the FastFocus ThinkLet
that generates ideas in depth on a focused set of topics [60].
(3) Reduce: Move from having many concepts to a focus on fewer
concepts deemed worthy of further attention, e.g. the
FastHarvest ThinkLet that extracts a list of key ideas from a
raw set of brainstorming comments and assures that team
members agree on the meaning and phrasing of the items on
the resulting list [60].
(4) Organize: Move from less to more understanding of the
relationship among concepts, e.g. the PopcornSort ThinkLet
that is used to quickly organize a large set of ideas into
categories [60].
(5) Evaluate: Increase understanding of the utility or priority of the
concepts in relation to goal attainment, e.g. the StrawPoll
ThinkLet that is used to evaluate a number of concepts with
respect to one or more criteria [60].
(6) Build-consensus: Move from having more disagreement to
having less disagreement on courses of action, e.g. the CrowBar
ThinkLet that is used to discover and discuss the reasons
behind disagreement on certain issues [60].
The original conceptualization of ThinkLets frames them as
having three components: a tool, a configuration of that tool, and
the facilitation script [45].
● The tool concerns the specific technology used to create the
pattern of collaboration: anything from post-it notes and pencils
to highly sophisticated collaboration technologies such as Group
Support Systems (GSS).
● The configuration defines how the tool is prepared (e.g. projected
on a public screen), set up (e.g. configured to allow anonymous or
non-anonymous communication), and loaded with data (e.g. a
set of questions to which people must respond).
● The script concerns everything a facilitator would have to do and
say to a group to create the required pattern of collaboration
[26,42].
Many practitioners have been trained to use ThinkLets to
support collaborative efforts, as they are easy to learn because their
documentation is structured to contain the essential information
and keeps complexity to a minimum. Furthermore, since they have
mnemonics they are easy to memorize and use as a shared
language in communities of practice. Therefore, ThinkLets offer a
good basis for the training of practitioners to become skilled and
independent in their ability to support the collaborative work
practice [55].
3. The design of the collaborative process: background and key
steps
The design of collaborative processes has many similarities
with work breakdown structure approaches, workflow manage-
ment [59], and Business Process Reengineering/Change [48]. Each
of these approaches offers methods to plan, decompose and
sequence collaborative activities. However, they do not offer tools
to prescribe the exact method a group can employ to execute these
activities, or how they can be supported with collaboration
technology [54].
To model and improve the design practices it is important and
essential to know how to classify, formulate, and represent the
various kinds of information in a design problem. Zeng and his
collaborators indicated that design is such a problem that its initial
 A. Azadegan et al. / Computers in Industry 64 (2013) 798–812
and goal states are not clearly defined [64,65]. Zeng and Cheng
proposed the recursive logic of design [64]. This logic indicates that
design is a process recursively generating design solutions and the
knowledge to evaluate the solutions. Based on this logic, a formal
design process model is developed where a design problem is not
completely defined until the design solutions are found [63].
The goal of this section is to illustrate the design stages of the
collaborative process used in this research and also highlight the
key steps followed to complete the design of the process. In this
research the Collaboration Engineering (CE) Design Approach [52]
is used to develop the collaborative process for user requirements
elicitation. CE design approach is a feedback-based recursive
process that addresses team collaboration design solutions.
In the CE Design Approach the steps are not sequential but
iterative and incremental in nature. Decisions made at each step
affect the past and future steps and choices. The CE Design
Approach is based on the Design Science research method in
information systems [49]. The approach has been developed and
tested over several years. Over 40 novice collaboration process
designers used different versions of the approach, and their
feedback was used for further improvements [54]. Different
researchers have described the successful use of this design
approach in their collaboration studies [46,51]. DSR helps design
corresponding process programmers with the subjects requiring
research and verifying or evaluating those subjects by using case
scenarios. It is objective and rational to adopt DSR because of its
three main stages: problem identification, solution design and
conformation between scheme evaluation and research model
[66].
The CE design approach suggests the five sequential steps
described below:
Step-1: task diagnosis: determining the tangible or intangible
goal, deliverables, and objectives of a collaboration process. The
groups or individuals, their stakes, roles and concerns are also
determined.
Step-2: task decomposition: determining the basic activities of
the entire task. For a new approach, activities should be
logically sequenced and their deliverables determined.
Step-3: ThinkLet choice: matching each activity with a ThinkLet.
Step-4: agenda building: describing what participants should do
at each stage of the process and the specifications for each
ThinkLet.
Step-5: design validation: information required to validate and
evaluate the process is determined.
Step-6: design documentation: during the design of the
collaborative process some information needs to be documen-
ted for later transfer to the practitioners to help them execute
the task. This stage happens in parallel with other steps [56].
Table 1
Overview of the main steps in the CE Design approach for collaborative process development.
CE design steps
Design documentation: Information from each step Step-1: task diagnosis
was documented to be transferred to the practitioners
(see Section 3.6)
Step-2: task decomposition
Step-3: choice of ThinkLet
Step-4: agenda building
Step-5: design validation
801
Table 1 describes each of the steps, its goal, and a brief
description of what has been achieved in this research regarding
the step. Further description of activities performed in each step is
given in Sections 3.1–3.6.
Task analysis and the choice of ThinkLets are described in the
next sections. The collaborative process for user requirements
elicitation is illustrated in Fig. 2 in Section 3.3. Section 3.4 delivers
the agenda to be used within the collaborative process. Section 3.5
describes the validation methods for the collaborative process for
user requirements elicitation. Section 3.6 describes the design
documentation.
3.1. Step-1: task diagnosis
User requirements workshops are held with the purpose of
consensus building among a number of stakeholders in order to
compile an agreed list of user requirements. At the task diagnosis
stage, the goal of the workshop and other factors such as the
cognitive load, the available technology, and the practitioner are
defined and recognized by the collaboration engineer. The overall
purpose of designing the collaborative process is to provide a script
to help facilitation of collaborating stakeholders who have joined a
user requirements elicitation workshop without an on-going need
for expert facilitators. In this research the stakeholders are
representing bodies of those groups or individuals who are
affected by the introduction or the use of the system. The use of
the appropriate technology or Group Support System (GSS) was also
decided in this step. A GSS is an interactive computer-based system
that facilitates the solution of semi-structured and unstructured
tasks by a group of people who have joint responsibility for
performing it. In this research, ThinkTank was employed as a tool
for collaboration. It creates a clear, customized output of the
content for immediate use or for future reference. ThinkTank has
been used a number of times for facilitating collaborative
processes designed using Collaboration Engineering and has been
found an easy tool for facilitators and practitioners [27].
3.2. Step-2: task decomposition
By the stage of task decomposition the goal of the session is
sufficiently clear. The collaboration engineer next needs to
determine the basic collaboration process, by further analyzing
and decomposing the task into activities. At this stage, the
collaboration process activities are directly matched to a pattern of
collaboration, or are further decomposed into sub-activities that
can then be matched; requirements and deliverables of each
activity are also identified. Based on the CE literature, the authors
propose the following tasks for stakeholders to complete in a user
requirements elicitation:
Overview of collaborative process within each step
User requirements elicitation is thoroughly investigated, following three
user models. Potential stakeholders to be represented in the user
requirements workshop are investigated (see Section 3.1)
Five different activities are identified for inclusion in the workshop
(see Section 3.2)
The process is illustrated using ThinkLets. Patterns of collaboration
for each activity are identified and appropriate ThinkLets are selected
(see Section 3.3)
The agenda for participants’ action at each stage is drawn up.
(See section 3.4)
The collaborative process is evaluated in workshops and through
expert interviews (see Section 4)
802 A. Azadegan et al. / Computers in Industry 64 (2013) 798–812
Table 2
Tasks for collaborative user requirements elicitation and the associated patterns.
Activity description
Activity-1: Identify relevant user requirements
Activity-2: Analyze features for each group of users and categorize user requirements
Activity-3: Identify user requirements within each category
Activity-4: Discuss to ensure correct categorization
Activity-5: Vote for user requirements in the lists, based on priority and discussion to find agreement about those
requirements with little consensus
Activity-6: Discuss to confirm overall agreement
1. Activity-1: identify relevant user requirements. The result of this
step is a list of user requirements.
2. Activity-2: analyze features for each group of users and categorize
user requirements into groups of users. In this step features are
identified and assigned to the different groups of users. Three
groups of users have been proposed by Human Factors Experts
at the HUSAT research centre at Loughborough University, UK
[16]:
Primary Users: the most frequent hands-on users of the
proposed system.
Secondary Users: occasional users or those who use the
system through an intermediary.
Tertiary Users: those who are unlikely to be hands-on users
but will be affected by the introduction of the system or will
be influenced by its purchase.
The user requirements are categorized according to the type
of user.
3. Activity-3: identify user requirements within each category. The
result of this step is the lists of user requirements within the
specific categories.
4. Activity-4: discuss to ensure correct categorization. The delivery of
this step is an overview of the categorized users.
5. Activity-5: voting for user requirements within each category
based on priority and discussion to reach an agreement on those
user requirements where a low level of consensus is achieved:
The result of this step is users with all features prioritized
according to business value and feasibility.
6. Activity-6: confirming that overall group understanding about
the categorized and prioritized user requirements lists is
achieved: the result of this step is an agreed list of evaluated
and categorized user requirements.
Table 2 describes each of the above activities with respect to the
pattern of collaboration required for achieving each task in a
collaborative manner.
3.3. Step-3: ThinkLet choice
Choosing the right ThinkLet is a critical task, which is done by
the collaboration engineer, with reference to the client goal,
the stakes, practitioner skills as well as the allocated results [28].
The ThinkLet choice map [11] was used in this research to find the
appropriate combination of ThinkLets that can pursue the
objective of each task according to the pattern of collaboration.
In the ThinkLet choice map, possible combinations of ThinkLets are
illustrated in a table. ThinkLets that are displayed as column
headings follow those that are displayed as row headings. The
ThinkLet choice map is used by the collaboration engineers to
understand ThinkLet combinations that are categorized as
‘‘excellent combination’’, ‘‘tricky combination’’ or ‘‘impossible’’
to be combined. In Fig. 1 the table cell marked with X indicates the
combination of FreeBrainstorm followed by OnePage. Light-grey
Associated collaboration pattern
Generate
Organize
Generate
Evaluate
Evaluate, build consensus
Build consensus
cells indicate excellent combinations, grey cells indicate problem-
atic combinations and black cells indicate impossible combina-
tions.
The activities that are supported by ThinkLets are now
illustrated using a requirement elicitation workshop as an
example. The workshop starts by participants generating user
requirements (Activity-1). Free-BrainStorm is the ThinkLet chosen
for activity-1, with participants’ ideas diverging quickly in
response to the question of identifying the user requirements.
Next the participants are encouraged to categorize the
requirements (Activity-2), using the PopcornSort ThinkLet. Nor-
mally after a divergence activity like FreeBrainstorm, PopcornSort
is used to converge and organize the ideas into related clusters or
categories.
The LeafHopper ThinkLet is appropriate to collect team
members’ ideas about each of the categories, brainstorming
within all the categories at once (Activity-3).
The BucketWalk ThinkLet is used to validate the results of
PopcornSort or LeafHopper; participants are encouraged to review
the contents of each category to make sure they are correct
(Activity-4). If any participant questions the content of a category,
the group starts a moderate discussion to make further decision
about the issue before going on to the next stage of the process. The
BucketWalk ThinkLet is used to remove redundancy and consoli-
date the features for each domain. Therefore, at this stage of the
process the collaborating stakeholders have the opportunity to
raise any issues related to interdependencies between require-
ments including aspects such as conflicting and recursive
dependencies between requirements in the list. In response, the
facilitator would provide an opportunity for the group to discuss
about the identified issues and proposed alternatives to facilitate
the agreement on the final decision.
In Activity-5, participants evaluate the requirements inside
each category based on their priority, in a voting session. StrawPoll
helps to measure consensus and to reveal the patterns of
agreement or disagreement with the group. Using the chosen
voting method (e.g. a 1–5 scale), participants decide which
requirements are more important (have priority) than others.
Also in Activity-5, the CrowBar thinkLet is used to survey and
examine assumptions and to share unshared information, provok-
ing a focused discussion about issues on which the group has a low
consensus.
Participants are encouraged to repeat Activity-5 until an
acceptable level of consensus is achieved.
Finally, MoodRing is used to track patterns of consensus on a
single issue in real time, and to indicate when it is time to stop
talking and make a decision. MoodRing ensures agreement and
Fig. 1. Partial illustration of ThinkLet choice map [11].
 A. Azadegan et al. / Computers in Industry 64 (2013) 798–812 803

Fig. 2. Collaborative process for user requirements elicitation.

consensus among participants about the overall outcome of the
session (Activity-6). Fig. 2 illustrates the collaborative process for
user requirements elicitation.
The script of each ThinkLet contains rules for a participant in a
defined role for creating the required pattern of collaboration.
These rules describe the actions a participant must execute, under
a given set of constraints [29]. The scripts for all the ThinkLets are
derived from papers [12,29,30] and can be found in Appendix to
this paper.
3.4. Step-4: agenda building
In this section the agenda proposed for the designed
collaborative process is described (see Table 3).
3.5. Step-5: design validation
In order to validate the designed collaborative process, record
what was happening at each stage and describe the intervention

Table 3
The session agenda.

Task Question/assignment ThinkLet Time

Introduction. Explain goal of session, Goal: get insight into high-level understanding 10.00
GSS and exercise. Introduce participants of the user requirements
Brainstorming goal Please add any potential user requirements you have Free Brainstorm 10:30
in mind to the brainstorming list
Categorizing goals Please drag and drop user requirements from the list PopcornSort 10:50
into the relevant category. Each category relates to
a different group of users classified as primary,
secondary and tertiary
Brainstorm inside each category Please insert any user requirements you have in mind LeafHopper 11:00
into the related category
Build consensus on selection of users Please comment on user requirements you entered BucketWalk 11:15
in each category and discuss any you believe can
be inserted in other categories
Break 11:45
Prioritize selection of users through voting Please indicate the priority user requirements on StrawPoll 12:00
a scale of 5
Structured discussion about the items on Despite what you voted, for those whose priority Crowbar 12:20
which stakeholders have the least consensus we disagree on, suggest arguments for including or
excluding them from the list or changing the level
of priority
Consensus on the final set of requirements Are you happy with the classified requirements? MoodRing 12:30
Please select Yes or No
804 A. Azadegan et al. / Computers in Industry 64 (2013) 798–812
needed and the context in which the process can be applied to we
used a case-study approach. A case study is used to contribute to
our knowledge of individuals’ collaboration in a form of a group.
The distinctive need for case study arises out of the desire to
understand complex social phenomenon. Case studies help
investigators to retain the holistic and meaningful events such
as small group behaviour [31].
We particularly need to study the application of the collabora-
tive process to the group of collaborating participants. The goal of
the case study is to present data regarding the effectiveness of the
process and to report on practical experiences in conducting it.
Using a case study allows us to understand why and under what
circumstances certain results are delivered at each stage of the
process; theoretical assumptions about applying Collaboration
Engineering principles to collaborative requirements elicitation
can be validated once results are documented.
In order to validate the design, three groups of five third-year
Information Systems PhD students in the Manchester Business
School (MBS), i.e. 15 participants in total, were invited to join a
facilitated evaluation workshop. A novice practitioner, who was
also a third year PhD student in MBS, facilitated the teams. The
participants were selected from students who had similar back-
grounds in terms of team collaboration and facilitation; most had
limited knowledge or experience of Collaboration Engineering or
Requirements Engineering, although some were familiar with
decision-making processes. Only one participant had taken a
Requirements Engineering module during her previous degree
programme, and was quite familiar with the area of Collaboration
Engineering; her current research was in Collaboration Psychology.
One participant had a background in engineering.
The participants, as well as the facilitator, were given an
induction handbook as a user manual, which contained informa-
tion about the collaborative process structure and application
process. It supported them in the training and prescription of the
collaboration process prescription and in understanding whether
the process could be executed according to the predictable
patterns of collaboration and results at each stage, from the
participants’ point of view.
The facilitator was provided with an induction session of
30 min before the collaboration session started, ensuring familiar-
ization with the collaboration tool ThinkTank [27], ThinkLets and
the agenda for the workshop. All participants were given roles as
stakeholders in the case study used for collaboration. The roles as
well as the case study were described to them face-to-face before
the session. The subject of the case study was chosen as being easy
for the workshop participants to understand. After the training
session, the facilitator and the participants began the case study,
which presented a problem that concerned them, even though they
were role playing. As a result, they were all engaged in the
workshop activities. Each workshop took about 2 h and was held in
Group Systems lab in MBS.
At the end of the process the participants’ opinions and
perceptions was used for evaluation purposes. Participants were
asked to evaluate the collaborative process induction handbook,
and to comment on their experience and describe how easy it was
for them to follow the collaborative process during the workshop.
They were also asked whether they believed the process could help
them reach agreement over user requirements. The questionnaire
on the collaborative process application focused on usability,
usefulness, suitability and adoptability as criteria for evaluation.
3.5.1. Case study: requirements for a university website
The Postgraduate Administration Department of a UK universi-
ty has submitted a proposal to the Director of the School. The
proposal suggests a need for change in the design and structure of
the School’s website that can satisfy the needs of any user of the
Table 4
Stakeholders and their roles.
Stakeholder Rationale for inclusion
Marketing staff To provide clear brand leadership
Academic staff Academically led activities in teaching
and research
IT support staff IT service would add expertise and advice to
ensure proposed developments were fit for
purpose and sustainable in operation
World-wide affairs staff To facilitate students world-wide
Admissions staff To explore opportunities to attract/market
to students
website. The stakeholders need to consider all requirements for
change, categorize and prioritize them. Requirements with higher
priority should be defined by stakeholders since changes to the
website should be made in a way that it can satisfy those high-
priority requirements first. Stakeholder representatives from the
Marketing, Academic, IT support, World-Wide Affairs and Admis-
sions staff were invited to join the workshop (Table 4).
In each workshop the participants completed the stages of
collaboration using the agenda described in Section 3. The
facilitator used the instructions for each ThinkLet to guide
participants through each activity (see Appendix).
In order to illustrate the applicability of our proposed method,
we describe the steps and the outcome of each one. The case study
described above was presented. All three workshops organized at
MBS were similar in terms of the steps followed and their
outcomes, and we discuss one of them as representative.
3.5.2. Activity-1: identify relevant user requirements. The result of this
step is a list of user requirements (allocated time: 10 min)
First the facilitator directed the participants to brainstorm their
ideas about user requirements for the university website.
According to the agenda (see Section 3.4), 10 min was allocated
for the brainstorming activity. The Free BrainStorm ThinkLet was
used to facilitate the activity. Each participant’s ideas were added
to the brainstorming list and shared with other participants in the
group. The facilitator had to make sure each participant was able to
access and read the contributions of others for inspiration. After
the brainstorming the participants produced a long list of user
requirements. The outcome of the brainstorming activity produced
by the ThinkTank groupware is displayed in Fig. 3.
3.5.3. Activity-2: Analyze features for each group of users and
categorize user requirements by groups of users (allocated time:
5 min)
Since the brainstorming list normally contains a large number
of uncategorized ideas, the facilitator asked the participants to
categorize the user requirements that emerged. Using the
collaborative process designed in this paper, the requirements
were divided into the needs of primary, secondary and tertiary
users (see Section 3.2), so that the needs of users who are most
affected by the introduction of the new website can be satisfied
first. The facilitator used the PopcornSort ThinkLet instructions to
guide the group, asking participants to read the list of generated
requirements and place each one under the category they think it
belongs to (see Section 3.2). Participants were encouraged to see
the contributions of others. A sample of the categorized
brainstormed list of user requirements is displayed in Fig. 4. For
primary users, certain types of identity and time tags were left and
displayed next to each requirement. It was clear from these tags
that the collaborating participants required very little time to
categorize the requirements. ThinkTank appeared very efficient in
this respect. Also, the participants could understand the topics in
each category and the reason why they needed to categorize the
brainstormed list.
 A. Azadegan et al. / Computers in Industry 64 (2013) 798–812 805

Fig. 3. Sample of brainstormed list of user requirements.

Fig. 4. Sample of categorized list of user requirements.

3.5.4. Activity-3: identify user requirements within each category
(allocated time: 5 min)
Once the participants had completed the categorization session,
the facilitator guided them through the instructions for LeafHop-
per by asking them to add a number of contributions to each
category in parallel, in order to find inspiration from other
members’ ideas.
3.5.5. Activity-4: discuss to ensure correct categorization
Next, the facilitator had to make sure that there were no unclear
contributions in the brainstormed results in each category. The
BucketWalk instructions helped the facilitator to direct the team
through the process of identifying ambiguous or unclear ideas in
the categories. Participants were given time to reflect on their
contribution in each category. If there was any uncertainty about
806 A. Azadegan et al. / Computers in Industry 64 (2013) 798–812

Table 5
Votes allocated to prioritize requirements for primary users.

Primary users Average STD N votes

1.1 Publications link 3.00 1.87 5

1.2 We should divide the issues into categories with an introductory page for each area 3.00 0.71 5
1.3 Create a Facebook group to encourage people to collaborate and keep in touch 3.00 0.71 5
1.4 Having videos and audio systems to illustrate programmes and instructions 4.60 0.89 5
1.5 A good system for accessing electronic resources in the Library 4.40 1.35 5
1.6 Enabling staff to communicate their research projects and allow PhD students and other staff to 4.20 1.10 5
see these projects and collaborate
1.7 New pages regarding the achievements of the School and University 4.40 0.89 5
...
1.28 They need to encourage students to use this website to read and study through linking them with 4.80 0.45 5
published articles and journals
1.29 Different online communities can be developed for the different groups of users 4.20 1.30 5

an idea, participants had a short face-to-face discussion. Once the
ideas had been exchanged, decisions were made about which
category the idea belonged in, resulting in clear and comprehen-
sive lists or requirements.
3.5.6. Activity-5: voting for user requirements within each category
based on priority and holding discussions for consensus building
The facilitator started the voting session by asking the
participants to vote for requirements in categories. The group
prioritized the requirements by using the ThinkTank collaborative
voting tool. The requirements were prioritized based on necessity
(effectiveness) of implementation on a scale of 1–5 (5 highest). The
criteria of prioritization and the ranking process using the
ThinkTank voting tool were well explained to the participants
by the facilitator before the start of the voting session. All five
participants voted for each requirement in the lists and they casted
their votes privately.
ThinkTank provided the facilitator with exact information
about the standard deviation for each requirement, in order to
select those requirements achieving a high rate of standard
deviation, representing overall disagreement on the voting result.
These requirements were then discussed by the participants for
consensus building purposes. Using the instructions for Crowbar,
the facilitator let participants engage in a moderated discussion
about those requirements with high disagreement, and asked them
to revote. The facilitator could then decide whether the disagree-
ment was resolved or the issue should be parked.
The collaborative process used in this case study could
accommodate the expression of preferences and prioritization
by stakeholders. All areas of sufficient and insufficient consensus
were observed so that it could be determined by the facilitator the
requirements in the list that needed more clarification and
consensus building through further discussions. The process
resulted in an agreed upon prioritized and categorized lists of
user requirements.
The actual outcome of the collaborative process described in
this paper is reflected in the sample displayed in Tables 9–10.
According to the data displayed in Table 5, a list of 29 user
requirements was prioritized under the category of Primary Users,
and ranked by priority. For example, requirement number 1.5 has
reached the average point of 4.40 and has therefore greater priority
for inclusion than requirement 1.1, which averaged 3.00. Table 6
shows some of the requirements prioritized for the Secondary
Users, and Table 7 the prioritized requirements for Tertiary Users.
In Tables 5–9, STD stands for Standard Deviation.
3.5.7. Activity-6: confirming that overall group understanding about
the categorized and prioritized lists of user requirements is achieved
Finally the facilitator used MoodRing to ask the participants to
confirm whether or not they would agree with the outcome of the
workshop. All five users voted Yes, reaching consensus over the
outcome (see Table 8).
3.6. Design documentation
Information was documented at certain stages of the design
process, acting as a template to offer the practitioner complete
information in support of the training and execution of the
designed collaborative process [25].
In this study the collaborative process model (see Fig. 2) was
documented, showing all the sequential activities and the relation-
ship between them. All ThinkLets and scripts were documented so
that the practitioners could easily read, understand and execute the
instructions. Tasks, objectives, activities, and design agenda were
documented as well. A series of cards containing brief information
regarding what each ThinkLet does and how it should be used were
prepared to simplify the process of knowledge transfer to
practitioners. Finally, all data collected from participants during
the workshop and interviews were documented.
4. Evaluation of results
In this section we evaluate the results of applying the
collaborative process to the case study during the workshops. The

Table 6
Votes allocated to prioritize requirements for secondary users.

Secondary users Average STD N votes

2.1 Having videos and audio systems to illustrate programmes and instructions 3.00 1.22 5
2.2 A good system for accessing electronic resources in the Library 2.60 1.34 5
2.3 Enabling staff to communicate their research projects and allow PhD students and other staff to 3.80 1.79 5
see these projects and collaborate
2.4 New pages regarding the achievements of the School and University 4.80 0.45 5
2.5 They need to encourage students to use this website to read and study through linking them with 4.60 0.55 5
published articles and journals
...
2.26 Different online communities can be developed for different groups of users 3.00 1.41 5
2.27 A map of the university campus and the city would be useful for new students 3.40 1.14 5
2.28 A good system for accessing e-mails from everywhere 4.80 0.45 5
 A. Azadegan et al. / Computers in Industry 64 (2013) 798–812 807

Table 7
Votes allocated to prioritize requirements for tertiary users.

Tertiary users Average STD N votes

3.1 Information on family matters for mature students 4.00 1.22 5

3.2 The website should include interviews with current students about their experience in 4.80 0.45 5
the University, to attract new students
3.3 A description of the area’s cultural and social background, to ease in students and prevent 4.40 0.89 5
‘‘culture shock’’
3.4 Provide profiles of academic staff and their research 3.50 1.29 5
...
3.21 Standard profile for each member of staff, including photograph, e-mail address, brief 3.40 1.67 5
background, research area(s), important publications, ‘‘mission statement’’
3.22 Provide information about research being conducted by the University 4.40 1.34 5
...
3.26 Database requirements: use the DBMS we already have, e.g. Oracle 4.40 1.34 5
3.27 Separate sections of the website for separate academic departments 4.60 0.89 5
3.28 Download brochures for each study programme (.pdf) 4.60 0.89 5

Table 8
Consensus among the stakeholders.

# N Y Average score Total STD Votes

1 Do you agree with the outcome of the session? 0 5 1 5.00 0.00 5

interviews withtwo expert professionalsinthefield of Collaboration
Engineering and requirements elicitation are described.
4.1. Evaluation of the application of the collaborative process to the
case study
As our focus was on the contribution of the collaborative
process in the context of user requirements elicitation, we aimed to
evaluate the usefulness of the collaborative process from the
participants’ point of view. In order to evaluate its usability we
asked the participants to assess its understandability, operability
and learnability [50]. They were also asked to judge its suitability
chosen domain, and its adoptability to similar situations.
The criteria used for evaluation were derived from the results of
the European project ELEKTRA [57] and the SQA Definition in the
ISO 9126 Quality Model [50]. The sets of criteria described in these
two models were merged to produce a list of criteria for evaluating
the collaborative process presented in this research (see Table 9).
The measurement of other criteria depends on the nature of the
collaborative process and can be decided by the researcher.
All 15 participants in the three workshops ranked the criteria on
a scale of 1–5 (5 is highest).
The process learnability received a score of 4.6 from the
problem-related expert and an average of 4.0 from the partici-
pants, who agreed that they would use the collaborative process in
future to solve similar problems.
Understandability and learnability for the novice user
achieved the lowest score of 3.1, and a comparably high score
of 0.884 for standard deviation. This means that novice
Table 9
Evaluation by participants attending the three workshops.
Criteria Average score
(5 is highest)
Usefulness 3.9
Suitability 3.9
Understandability 3.9
Operability 4.0
Learnability (novice user) 3.1
Learnability (general user) 3.6
Learnability (expert user) 4.6
Learnability (problem-related expert) 4.4
Adoptability 3.9
participants might face problems in learning the collaborative
process and therefore they need to be trained well in advance
before being asked to use it. Extensive training sessions and
feedback from more experienced users can overcome the problem
of learnability for novice users.
The participants agreed that the process is easier to learn for a
general user, and much easier for a pattern expert (score of 4.4), but
the high standard deviation means that other participants
disagreed. However, the process achieved a high score of 3.9 for
adoptability, so is likely to be widely used to solve similar problems
in the future.
Participants also gave their general opinion about the
collaborative pattern process and commented on their experience
during the workshop. Almost all of them believed that they could
easily understand the case study; however, one pointed out that
the case study was not understandable at the start; although after a
brief initial description before the session started she could easily
understand it. One of the participants stated that the case study
would require more and better explanation on the roles the
participants are supposed to take.
Almost all participants agreed that the process was easy to
follow and that they could apply it to the case study. One
participant mentioned that more explanation was needed to
understand the case study.
Most of the participants believed that the process could help
them to collaborate and reach agreement about user requirements.
One suggested that the process might fail to achieve a consensus
because not all the stakeholders in a team might be able to
understand each other’s brainstormed requirements at the initial
point of collaboration, and she believed that early discussion in the
group was required to eliminate misunderstandings.
The participants were asked to provide their free comments
on the process. One of the participants mentioned that novice
STD users might need training to use the software. Another
commented on the vocabulary used in the booklet, finding
0.442 the terms and the concept difficult to understand until the pre-
0.573 workshop training.
0.442
0.534
0.884 4.2. Evaluation from interviews with experts
0.711
0.611 In addition to the workshops, we carried out interviews with
0.618
two experts to evaluate the collaborative process. The first is a
0.573
distinguished professor and the director of a university Centre for
808 A. Azadegan et al. / Computers in Industry 64 (2013) 798–812
Collaboration Science. His research focuses on field applications of
e-collaboration technologies, the theoretical foundations of (e)-
collaboration, Collaboration Engineering, and the facilitation of
group meetings. He was named the most productive Group
Support Systems researcher worldwide from 2000 to 2005. The
second evaluator is an assistant professor in Collaboration
Engineering. Her expertise is the design and deployment of
collaboration support for group processes in organizations. She is
an experienced facilitator of ThinkLet-based Group Support
Systems workshops. She has worked with numerous public and
private organizations, supporting their group processes. Her
research focuses on the quality of ThinkLet-based collaboration
process design for complex tasks. The evaluators are also actively
participating in different industrial projects and are familiar with a
range of collaboration methods.
Both evaluators agreed that the case study used for evaluating
the collaborative process is easy to understand. The first evaluator
believed that the process is not necessarily linked to a particular
situation, stating that ‘‘It can be used for system requirements,
product requirements, etc. . . . or it can be used for a service. The
best result using the pattern is achieved when the process is run by
the users of the system as stakeholders.’’
Asked if they found the collaborative process easy to follow, the
evaluators agreed that all the stages are clearly designed and
defined. However, the first evaluator suggested some adjustments
to the categorization stage: ‘‘The categories need to be unique. The
target should be that the least amount of overlap exists between
categories. For example, in case the requirements are sorted based
on the type of the users then it should be clear that a certain
requirement is not used by more than one user which means a
certain requirement does not belong to more than one category.’’
The second evaluator believed that if the facilitator finds a larger
number of ideas in some categories than others, then in the later
stages of collaboration this unbalanced situation should be
covered. Using a Bucket-Walk ThinkLet after the Popcorn-sort
might be a useful approach in this situation.
The evaluators strongly believed that it is very important to
establish that all requirements have been generated and fully
understood by stakeholders before reaching the voting stage. The
second evaluator referred to the first feedback loop positioned in
the collaborative process structure and made a number of
suggestions about how to reach a better-refined set of require-
ments before the stage where participants do the voting tasks. She
advised using Mood-Ring instead of a feedback loop in the first half
of the process, to help participants reach agreement and resolve
uncertainties more quickly. She added: ‘‘It should be known which
requirements can be described as ‘need to have’ or which one of
requirements are described as ‘nice to have’. In the voting list those
that score higher are obviously the ‘need to have’ ones.’’
The expert evaluators commented on the concept of require-
ments. The first evaluator said: ‘‘It is very important for the
developers to have a clear view of the requirements.’’ He elaborated
by describing that at some point in the process, the facilitator needs
to do the clustering and check the completeness to clarify which
requirementsneedtobeimplemented inthe future. He alsobelieved
that in orderfor stakeholders toreach a consensus, they need to have
a clear idea about the scope of the process. He added that this
clarification can be made before brainstorming or after the Bucket-
Walk stage. Overall, the evaluators agreed that the project’s core
issues and refined list of requirements should be clarified before the
voting stage so that the possibility of getting the stakeholders to
reach agreement could be increased.
Regarding the comprehensiveness of the project, the first
evaluator believed that it would possible to talk about the scope
with the project owner and then present it to the group of
stakeholders to understand if they wished to contribute their ideas
to the project’s scope. The second evaluator mentioned an
alternative approach. She believed in building the project’s scope
from scratch. In order to do that the facilitator should split the group
into pairs and ask them to define the scope of the project in four or
five sentences. The facilitator would progressively merge these
results in order to come up with a joint scope for final discussion.
The evaluators commented on the second feedback loop. The
first said that when stakeholders reach it and re-vote for those
requirements with a low level of consensus or high standard
deviation, the facilitator should encourage a moderated discussion
and use Mood-Ring as a consensus building ThinkLet after the
discussion on each disagreed requirement. Using Mood-Ring helps
participants to remember the conversation and make sure the
result is agreed and documented. The second evaluator argued that
the collaborative process would make it difficult to manage large
groups of diverse stakeholders on a complex project; organizing a
free brainstorming session on the whole scope of the project is
probably too much. She suggested that the facilitator split the
brainstorming session into smaller ones. She added that in large
projects requirements are sometimes found that are not directly
involved in the project, and for these requirements the facilitator
needs to have a richer input to clarify what these requirements are
and focus on the more relevant and important ones.
5. Discussions
In this paper the authors have discussed user requirements and
proposed a collaborative process for user requirements elicitation
in facilitated workshops. Collaborative requirements elicitation
[22,23] by applying Collaboration Engineering (CE) [19–21] has
already been discussed. In line with this work, the authors of this
paper have also demonstrated how to apply CE principles to deliver
a repeatable collaborative process for user requirements elicita-
tion. According to CE principles [24–26]:
1. Collaborations need to be supported by a designed step-by-step
process that leads group efforts towards a specific goal.
2. The processes also need a facilitator to intervene and guide the
group to predictably follow the collaborative process and
behave with respect to the goal.
The collaborative process designed in this paper satisfies both
these objectives. It consists of ThinkLets as facilitation script and
building blocks, and satisfies the aim of transferring facilitation
knowledge to novice facilitators in organizations by defining the
steps and guidelines for non-expert facilitators. Having non-expert
facilitators to facilitate collaborations provides substantial benefits
in terms of time and expense.
In this research we used ThinkTank as the groupware tool [27].
However, it is important to stress that CE and ThinkLets do not rely
on software tools. ThinkLets can also be enacted using conven-
tional facilitation techniques such as flipcharts and cards. [12]
describe the technology-independent nature of ThinkLets and
argue that instead of prescribing a concrete tool and its
configuration ThinkLets should just define the capabilities
required for later execution. While ThinkLets might appear to be
process-centric and tool-centric at first sight, they should rather be
seen as facilitation techniques described in a very compact form
that allow the structuring of high-value group tasks with a focus on
triggering the interaction of individuals and teams. ThinkLets can
be combined flexibly to achieve the desired results in collabora-
tion. For instance, different brainstorming and prioritization
techniques can be concisely described using ThinkLets to allow
the rapid composition of collaborative activities later on.
The relative importance and urgency of different requirements
should be addressed in order to understand how to cope with
 A. Azadegan et al. / Computers in Industry 64 (2013) 798–812
Table 10
Examples of requirements levels within the category of primary users.
Primary user requirement
Having videos and audio systems to illustrate programmes and instructions
Enabling staff to communicate their research projects and allow PhD students and other staff to
see these projects and collaborate
Create a Facebook group to encourage people to collaborate and keep in touch
different limited resources of the project. Requirements prioriti-
zation ensures that the most critical requirements are addressed
immediately in case time or budgets run out. Our approach of
requirements prioritization is complementary to Chen and Zeng
[61] model of requirements categorization. Chen and Zeng [61]
describe an eight-level pyramid-like model of requirements that
facilitate ranking all the requirements in a way to help designers
understand which requirement has higher priority. In this model
those requirements at the lower level refer to non-functional
requirements which are having a lower priority compared to the
top four levels of the pyramid that refer to high priority
requirements. Using this model, higher-level requirements can
be considered after lower-level requirements are satisfied [62].
Using the collaborative process described in this paper the
facilitator provides an introduction to requirements prioritization
at the stage where Crowbar ThinkLet is used to guide the
collaborating stakeholders through the requirements ranking
process. Similar to what described in Cheng and Zeng [61], the
facilitator uses the verbal communication method and provides
stakeholders with an overview description of priority levels related
to functional and non-functional requirements and the priority
levels according to which those requirements are categorized.
Voting by stakeholders also takes place to rank the requirements.
The collaborative process designed in this paper was evaluated in
three workshops from the participants’ point of view. Learnability
for novice users received a lower score than that for general and
expert users. However, the high rate of standard deviation means
that not all participants evaluated the collaborative process as being
less learnable for novice users than for experts and general users.
According to the comments received from participants, once the
collaborative process has been carefully explained to the novice
users then it becomes easier to understand and learn. Most
participants believed that the collaborative process is usable and
useful, and suitable to be applied to user requirements elicitation in
workshops; it is also adoptable to similar situations where
requirements need to be collected collaboratively.
The analysis of the data received from the workshop
participants suggests that the collaborative process introduced
in this paper is a promising approach for user requirements
elicitation.
The set of requirements obtained as output to the collaborative
design process discussed in this paper can be assessed for
completeness and can be explained according to eight-level
pyramid-like model of requirements proposed by Wang and Zeng
[62]: the list of requirements achieved can be defined and
assessed from two perspectives: the partition of the environment
in terms of the product life cycle as well as the partition of the
environment into the human environment, natural environment
and built environment. The environment here refers to all the
components with which the product interacts [61]. The group in
our case identified prioritized requirements that are categorized
in three lists, which can be explained using the eight-level
pyramid-like model of requirements [62]. Some examples of the
levels from the prioritized primary users’ requirements list are
identified in Table 10:
The above mapping of requirements to the categories of eight-
level pyramid-like model of requirements [62] shows that the set
809
Average STD Requirements level
4.60 0.89 Technical limitations
4.20 1.10 Basic functions
3.00 0.71 Extended functions
of categorized and prioritized requirements achieved in this
research covers the dimensions of the eight levels of requirements
model therefore can be classified as complete based on the model
criteria. Other completeness related factors depend on the
collective knowledge of the participants concerning the universe
of discourse so the overall completeness of the set of requirements
also depend on the collective knowledge of the collaborating
participants involved in the process.
According to Jim Johnson, the founder and chairman of the
Standish Group [32], 40% of decisions made by stakeholders will
have a very high impact on a project. 14% of the decisions are made
on the concept of user requirements and functions. However, about
40% of the total decisions get reversed as a result of failing
processes used by an incorrect mix of involving stakeholders who
are the main decision makers. As a result, the Standish Group
research shows that latency between decisions is a major
contributor to project delays and failures. Moreover, according
to the Chaos report published in the year 2003 only 31% of the
projects reported to be successful [70]. Based on the same report
13.1% of project failures are caused by accessing an incomplete list
of requirements by the stakeholders [33]. Among the main reasons
for poor user requirements is an inadequate understanding of the
intended users, as well as a vague understanding about the context
of use [34]. The facilitated collaborative process described in this
paper is an approach that can result in successful decisions made
by groups of stakeholders collaborating in a user requirements
elicitation workshop. According to the results the process can be
re-used by different groups of stakeholders and result in
consensus.
Feedback was received through expert interviews. Both
evaluators believed that the process is easy to follow, but some
adjustments should be made to the structure of the process
especially to the categorization phase. They stressed that the
collaborative process would need to be refined before it reached
the voting stage. The refined process would help stakeholders to
access a fine-tuned list of requirements at the voting stage. The
evaluators commented on consensus building and the scope of the
project, proposing that stakeholders agree about the project scope
before the actual process starts, and suggesting relevant
approaches to achieve this aim.
6. Related work
The research described in this paper contributes to the body of
knowledge on requirements elicitation represented by den Hengst
et al. [20], Noor et al. [21] and Fruhling et al. [35], who presented
examples of frequently recurring collaborative processes in
different sectors.
den Hengst et al. [20] presented a collaborative approach to
requirements elicitation, applied to cases where stakeholders need
to discover requirements for a mobile information system. The
collaborative process described in this paper delivers a collabora-
tive process similar to the work of den Hengst et al. [20] in the
sense that they both focus on a collaborative requirements
elicitation process using Collaboration Engineering principles.
However, den Hengst et al.’s [20] work focuses on capturing
requirements for mobile information systems only. The research
 A. Azadegan et al. / Computers in Industry 64 (2013) 798–812
presented in this paper extends den Hengst et al.’s [20] work by Appendix
developing an artefact in the form of a step-by-step collaborative
process that can be generically applied to any context where ThinkLet scripts used in the collaborative process designed in this
stakeholders seek user requirements elicitation in a workshop. paper are as follows [25,29,30]:
This research has also added to the work of Noor et al. [21] by
FreeBrainstorm
presenting a complete collaborative process, which contains a Role:
detailed agenda for the application of the process. Noor et al. [21] Capabilities:
presented a relatively long and elaborate process that did not
include an agenda for the application of the process and a rationale
behind the introduction and inclusion of selected ThinkLets in the
process. Rules:
Similarly, Fruhling et al. [35] have used Collaboration Engi-
neering theories to deliver a collaborative process for requirements
elicitation. The collaborative process introduced in this paper
presents an approach to be used by the stakeholders to produce
requirements from scratch and finally reach consensus on a list of
agreed categorized and prioritized user requirements in a one-day
PopcornSort
workshop. However, Fruhling et al. [35] present a process that
Role:
needs to be executed in two different workshops and is used for Capability:
elaboration of pre-existing requirements, validating the require-
ments and discovering new ones. Rules:
This research presents a group elicitation technique that can be
applied to facilitated requirements elicitation workshops. The
collaborative process discussed in this paper aims to foster LeafHopper
stakeholder agreement, while exploiting team dynamics to bring Role:
Capability:
out a better understanding of needs. This research provides an
additional portfolio of techniques that can be combined with the
general modelling techniques used for requirements elicitation Rules:
such as scenario-based requirements elicitation methods [69].
Modelling techniques aid in the understanding of the problem
rather than initiating the design of the solution, and according to
some experts formal modelling methods distance the stakeholder
from the process [68]. What we are proposing is a group-based
approach helping stakeholders to identify the set off requirements
relating to an IT project through a step-by-step process under the
guidance of the facilitator. User requirements are generated
sequentially by following facilitation scripts i.e. Thinklets. More- BucketWalk
Role:
over, the collaborative process designed and discussed in this
Capabilities:
paper creates a generic set of requirements while scenario-based
approaches focus on generating requirements relevant to the scope Rules:
of to the scenarios identified.
7. Limitations and future work
Further research can focus on evaluating the process in
particular commercial settings or within a larger-scale project.
Future work could also seek to explore the possible variations of
the collaborative process and testing it with alternative ThinkLets. StrawPoll
An approach to further incremental development of the structure Role:
Capability:
and application of the collaborative process is to evaluate it against
more ‘‘worked’’ examples. By introducing criteria for evaluation, Rules:
the results could be compared to the worked examples. The
evaluation would facilitate our understanding of how effective and
efficient the collaborative process is against similar worked
examples. The underlying assumption however is that it is CrowBar
possible to replicate a similar setting with comparable groups of Role:
participants/stakeholders, which is a rather challenging task. Capability:
The collaborative process designed in this paper was developed
Rules:
for use by stakeholders during the scoping level of the require-
ments elicitation workshops, so it would help them to achieve a
very abstract and high-level understanding of the user require-
ments. Future work can be focused on using Collaboration
Engineering principles to design a collaborative process to be
applied to the second or third stages of user requirements
workshops.
811
Participants.
Set of pages. Each participant can add ideas to the page assigned to
him; after contributions, pages are randomly swapped among
participants.
ThinkTank does not yet automatically swap pages, but might create
this in the future as it was part of the old system.
Allow participants to add one contribution that matches the
contribution specification to each page they receive, one at a time,
in parallel.
Ensure that participants randomly swap pages after each
contribution.
Ensure that participants read the contributions of others for
inspiration.
Participants.
Categories, ideas that can be moved (categorizer tool, flip-over and
post-it or pin wand).
Allow participants to move ideas into the category they belong to.
Ensure that participants do not move ideas that are already
categorized.
Participants.
A page for each category visible to all participants, to which all
participants can add ideas to all pages (categorizer, flip-over
sheets).
Allow participants to add any number of contributions to any
category in parallel.
Allow participants to add only contributions that are relevant to
the categories in which they are placed.
Allow participants to add only contributions that match the
contribution specification.
Let participants shift focus from category to category as interest
and inspiration dictate.
Ensure that participants read the contributions of others for
inspiration.
Participants, Facilitator.
Participants: view clustering, suggest changes; Facilitator: check
agreement.
Let participants identify unclear contributions in brainstorming
results.
Ask the group to clarify the unclear contribution.
Edit the contribution to reflect the result.
Let participants identify contributions that do not reflect the
category in which they are placed.
Ask the group to suggest alternative classification.
Re-classify the contribution to reflect the result.
Let participants identify overlapping contributions.
Merge overlapping contributions with consent of the group.
Participants.
A list of ballot items with the ability to rate each on a specified
criterion (voting tool or ballot papers).
Allow participants to rate each item on the scale privately.
Calculate the resulting mean and standard deviation.
Display the voting result on the central screen and/or participants’
screens and present top, bottom and standard deviation.
Participants.
Preferably face-to-face discussion, overview of standard deviation
of vote.
Focus on the items with high disagreement.
Ask a group member to formulate an argument to rate the idea
high on the criterion, despite his own vote.
Ask a group member to formulate an argument to rate the idea low
on the criterion, despite his own vote.
Participants are allowed to reveal their vote, but are not forced to.
Determine the source of disagreement with disconsensus
diagnostics.
Resolve disagreement or park the issue.
810 A. Azadegan et al. / Computers in Industry 64 (2013) 798–812
Appendix (Continued)
MoodRing
Role: Participants
Capability: A reusable scaled discriminator for the issue.
Rules: Indicate your opinion on issue (X) on criterion (Y) using the scaled
discriminator (Z).
Discuss the issue.
Indicate any change in opinion.
Continue until there is sufficient consensus.
References
[1] B. Nuseibeh, S. Easterbrook, Requirements engineering: a roadmap, in: Proceed-
ings of the Conference on the Future of Software Engineering, ACM, New York,
2000, pp. 35–46.
[2] N.A.M. Maiden, M. Hare, Problem domain categories in requirements engineering,
International Journal of Human–Computer Studies 3 (1998) 281–304.
[3] M. Kans, An approach for determining the requirements of computerized main-
tenance management systems, Computers in Industry 59 (2008) 32–40.
[4] N. Gronau, J. Frö ming, S. Schmid, U. Rü ssbü ldt, Approach for requirement oriented
team building in industrial processes, Computers in Industry 58 (2007) 179–187.
[5] V. Nilsson, B. Fagerström, Managing stakeholder requirements in a product
modelling system, Computers in Industry 57 (2006) 167–177.
[6] H. Shen, B. Wall, M. Zaremba, Y. Chen, J. Browne, Integration of business modelling
methods for enterprise information system analysis and user requirements
gathering, Computers in Industry 54 (2004) 307–323.
[7] A. Katasonov, M. Sakkinen, Requirements quality control: a unifying framework,
Requirements Engineering 11 (2005) 42–57.
[8] S. Robertson, Requirements trawling techniques for discovering requirements,
International Journal of Human–Computer Studies 55 (2001) 405–421.
[9] S. Robertson, J. Robertson, Mastering the Requirements Process, Pearson Educa-
tion, Boston, MA, 2006.
[10] D. Zowghi, C. Coulin, Requirements elicitation: a survey of techniques, approaches
and tools, in: A. Aurum, C. Wohlim (Eds.), Engineering and Managing Software
Requirements, Springer, Heidelberg, 2005, pp. 19–46.
[11] G.L. Kolfschoten, G.J. de Vreede, The collaboration engineering approach for design-
ing collaboration processes, in: J.M. Haake, S.F. Ochoa, A. Cechich (Eds.), Lecture
Notes in Computer Science (LNCS 4715), Springer, Heidelberg, 2007, pp. 95–110.
[12] G.L. Kolfschoten, R.O. Briggs, G.J. Vreede, P. Jacobs, J. Appelman, A conceptual
foundation of the ThinkLet concept for Collaboration Engineering, International
Journal of Human–Computer Studies 64 (2006) 611–621.
[13] J. Wood, D. Silver, Joint Application Development, John Wiley, New York, 1995.
[14] E. Duggan, Generating systems requirements with facilitated group techniques,
Human–Computer Interaction 18 (2003) 373–394.
[15] V. Laporti, M.R.S. Borges, V. Braganholo, Athena A collaborative approach to
requirements elicitation, Computers in Industry 60 (2009) 367–380.
[16] L.A. Macaulay, Human Computer Interaction for Software Designers, Interna-
tional Thomson Computer Press, London, 1995.
[17] L. Mich, C. Anesi, D.M. Berry, Applying a pragmatics-based creativity-fostering
technique to requirements elicitation, Requirements Engineering 10 (2005) 262–
275.
[18] K. Haruhiko, D. Shinbara, J. Kawano, M. Saeki, Improving the detection of
requirements discordances among stakeholders, Requirements Engineering 10
(2005) 289–303.
[19] C. Acosta, L. Guerrero, Supporting the collaborative collection of user’s
requirements, 2006 http://www.sqa.net/iso9126.html (accessed 07.10.12).
[20] M. den Hengst, E. van de Kar, J. Appelman, Designing mobile information services:
user requirements elicitation with GSS design and application of a repeatable
process, in: Proceedings of the 37th Hawaii International Conference on System
Sciences, IEEE Computer Society, Los Alamitos, CA, 2004.
[21] M.A. Noor, R. Rabiser, P. Grünbacher, A product line planning: a collaborative
approach and a case study, Journal of Systems and Software 81 (2008) 868–882.
[22] B. Boehm, H. Kitapci, The WinWin approach: using a requirements negotiation
tool for rationale capture and use, in: A. Dutoit, R. McCall, I. Mistrik, B. Paech
(Eds.), Rationale Management in Software Engineering, Springer-Verlag, Heidel-
berg, 2006, pp. 173–190.
[23] R.O. Briggs, R. Gruenbacher, EasyWinWin: managing complexity in requirements
negotiation with GSS, in: Proceedings of the 35th Annual Hawaii International
Conference, IEEE Computer Society, Los Alamitos, CA, 2002.
[24] G.L. Kolfschoten, R.O. R.O. Briggs, J.H. Appelman, G.J. de Vreede, ThinkLets as
building blocks for collaboration processes: a further conceptualization, in: G.J.
de Vreede, L.A. Guerrero, G.M. Raventos (Eds.), CRIWG, Springer, Berlin, 2004, pp.
137–152.
[25] G.L. Kolfschoten, S. Van der Hulst, Collaboration process design transition to
practitioners: requirements from a cognitive load perspective, in: S. Seifert, C.
Weinhardt (Eds.), GDN Conference, Universtatsverlag Karlsruhe, Karlsruhe, 2006.
[26] G.J. de Vreede, R.O. Briggs, Collaboration engineering: designing repeatable
processes for high-value collaborative tasks, in: Proceedings of the 38th Hawaii
International Conference on System Sciences, IEEE Computer Society, Los Ala-
mitos, CA, 2005, pp. 17–27.
[27] Group Systems ThinkTank: Better, Faster, Cheaper, Pick any Three, 2011 http://
www3.groupsystems.com/l/6912/2011-05-23/38W3 (accessed 07.10.12).
[28]
G.L. Kolfschoten, E. E. Rouwette, Choice criteria for facilitation techniques:
a preliminary classification, in: Proceedings of the Group Decision and Nego-
tiation Conference, Universtatsverlag Karlsruhe, Karlsruhe, 2006 , pp. 1–8.
[29] S.W. Knoll, M. Hörning, G. Horton, A design approach for a universal group
support system using ThinkLets and ThinXels, in: Proceedings of the Group
Decision and Negotiation, 2008, Coimbra, Portugal, Faculdade de Economia da
Universidade de Coimbra, Portugal, 2008, pp. 119–120.
[30] G.L. Kolfschoten, E.L. Santanen, Re-conceptualizing generate ThinkLets: the role of
the modifier, in: Hawaii International Conference on System Science, IEEE Com-
puter Society Press, Los Alamitos, CA, 2007.
[31] R.K. Yin, Case Study Research: Design and Methods, 4th ed., Sage Publications
Inc., Los Angeles, USA, 2009.
[32] The Standish Group, Decision times: Part 6, 2012 http://blog.standishgroup.com/
(accessed 07.10.12).
[33] The Standish Group, Quarterly Reports, 2006 http://standishgroup.com/quarter-
ly_reports/ (accessed 07.10.12).
[34] R. Pew, A. Mavor, Human–Systems Integration in the System Development
Process: A New Look, National Academy Press, Washington, DC, 2007.
[35] A.L. Fruhling, L. Steinhauser, G. Hoff, C. Dunbar, Designing and evaluating collab-
orative processes for requirements elicitation and validation, in: Proceedings of
the 39th Hawaii International Conference on System Sciences, IEEE Computer
Society, Los Alamitos, CA, 2007.
[36] E. Gottesdiener, Requirements by Collaboration: Workshops for Defining Needs,
Addison-Wesley Professional, London, 2002.
[37] L.A. L.A. Macaulay, Requirements as a cooperative activity, in: Proceedings of the
IEEE Symposium on Requirements Engineering, IEEE Computer Society, Los
Alamitos, CA, 1993, pp. 174–181.
[38] N. Maiden, A. Gizikis, S. Robertson, Provoking creativity: imagine what your
requirements could be like, IEEE Software 21 (2004) 68–75.
[39] M. Adkins, J. Kruse, R. Younger, A language technology toolset for development of
a large group augmented facilitation system, in: Proceedings of 37th Hawaii
International Conference on System Sciences, IEEE Computer Society, Los Ala-
mitos, CA, 2004.
[40] G.J. de Vreede, R.O. Briggs, A.P. Massey, Collaboration engineering: foundations
and opportunities editorial to the special issue, Journal of the Association for
Information Systems 10 (2009) 121–137.
[41] G.J. de Vreede, A. Fruhling, A. Chakrapani, A repeatable collaboration process for
usability testing, in: Proceedings of the 38th Hawaii International Conference on
System Sciences, IEEE Computer Society, Los Alamitos, CA, 2005, pp. 46–56.
[42] R.O. Briggs, G.J. de Vreede, J.F. Nunamaker, Collaboration engineering with
ThinkLets to pursue sustained success with group support systems, Journal of
MIS Quarterly 19 (2003) 31–63.
[43] L.D. Douglas, D. Amit, R.T. Bush, Making the collaboration engineering investment
decision, in: Proceedings of the 39th Hawaii International Conference on System
Sciences, IEEE Computer Society, Los Alamitos, CA, 2006.
[44] R.O. Briggs, G.L. Kolfschoten, G.J. de Vreede, D.L. Dean, Defining key concepts for
collaboration engineering, in: Proceedings of the 12th Americas Conference on
Information Systems, AIS Electronic Library, Acapulco, Mexico, 2006, pp. 121–128.
[45] R.O. Briggs, G.J. de Vreede, J.F. Nunamaker, D. Tobey, ThinkLets: achieving
predictable, repeatable patterns of group interaction with group support systems
(GSS), in: Proceedings of the 34th Hawaii International Conference on System
Sciences, IEEE Computer Society, Los Alamitos, 2001.
[46] J. Bragge, H. Merisalo-Rantanen, P. Hallikainen, Gathering innovative end-user
feedback for continuous development of information systems: a repeatable and
transferable e-collaboration process, IEEE Transactions on Professional Commu-
nication 48 (2005) 55–67.
[47] T. Griffith, M. Fuller, G. Northcraft, Facilitator influence in group support systems:
intended and unintended effects, Information Systems Research 9 (1998) 20–36.
[48] V. Grover, W.J. Kettinger, Business Process Change: Reengineering Concepts,
Methods and Technologies, Idea Group Publishing, Harrisburg, 1995.
[49] A.R. Hevner, S.T. March, J. Park, S. Ram, Design science in information systems
research, MIS Quarterly. 28 (2004) 75–105.
[50] ISO 9126, Software Quality Characteristics, http://www.sqa.net/iso9126.html
(accessed 07.10.12).
[51] M. Kamal, A.J. Davis, J. Nabukenya, T.V. Schoonover, L.R. Pietron, G.J. de Vreede,
Collaboration engineering for incident response planning: process development
and validation, in: Proceedings of the 40th Hawaii International Conference on
System Sciences, IEEE Computer Society, Los Alamitos, CA, 2007.
[52] G.L. Kolfschoten, G.J. de Vreede, A design approach for collaboration processes: a
multi-method design science study in collaboration engineering, Journal of
Management Information System 26 (2009) 225–256.
[53] G.L. Kolfschoten, S. Lukosch, A. Verbraeck, E. Valentin, G.J. de Vreede, Cognitive
learning efficiency through the use of design patterns in teaching, Journal of
Computers and Education 54 (2010) 652–660.
[54] G.L. Kolfschoten, G.J. de Vreede, R.O. Briggs, H.G. Sol, Collaboration engineer-
ability, Group Decision and Negotiation Journal 19 (2010) 301–321.
[55] G.L. Kolfschoten, G.J. de Vreede, R.O. Briggs, Collaboration engineering advances
in group decision and negotiation, in: Handbook of Group Decision and Negotia-
tion, Springer Dordrecht Heidelberg, London, New York, 2010, pp. 339–357.
[56] A. Nakakawa, Collaboration engineering approach to enterprise architecture
design evaluation and selection, in: Proceedings of the 20th International Con-
ference on Advanced Information Systems Engineering (CAiSE’08), Montpellier,
France, Springer, Berlin, 2008, pp. 1–26.
[57] C. Rolland, J. Stirna, N. Prekas, P. Loucopoulos, A. Persson, G. Grosz, Evaluating a
pattern approach as an aid for the development of organizational knowledge: an
empirical study, in: Proceedings of the 12th International Conference on Ad-
 A. Azadegan et al. / Computers in Industry 64 (2013) 798–812
vanced Information System Engineering (CAiSE), LNCS 1789, Springer, Berlin,
2000, pp. 176–191.
[58] R.M. Schwarz, The skilled facilitator: Practical wisdom for developing effective
groups, London, Jossey-Bass Publishers, 1994.
[59] W.M.P. Van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, A.P. Barros, Workflow
patterns, Distributed and Parallel Databases 14 (2003) 5–51.
[60] G.J. de Vreede, G.L. Kolfschoten, R.O. Briggs, ThinkLets: a collaboration engineer-
ing pattern language, International Journal of Computer Applications in Technol-
ogy 25 (2006) 140–154.
[61] Z.Y. Chen, Y. Zeng, Classification of product requirements based on product
environment, Concurrent Engineering 14 (2006) 219–230.
[62] M. Wang, Y. Zeng, Asking the right questions to elicit product requirements,
International Journal of Computer Integrated Manufacturing 22 (2009) 283–298.
[63] Y. Zeng, Environment-based formulation of design problem, Transactions of the
SDPS: Journal of Integrated Design and Process Science 8 (2004) 45–63.
[64] Y. Zeng, G. Cheng, On the logic of design, Design Studies 12 (1991) 137–141.
[65] Y. Zeng, P. Gu, General design governing equation, in: NSFC Grantee’s Conference
on Design and Manufacturing Engineering, Vancouver, BC, Canada, 2000.
[66] P. Offermann, O. Levina, M. Schö nherr, U. Bub, Outline of a design science research
process, in: Proceedings of the 4th International Conference on Design Science
Research in Information Systems and Technology, 2009, pp. 1–11.
[67] X. Sun, Y. Zeng, W. Liu, Formalization of design chain management using envi-
ronment-based design (EBD) theory, Journal of Intelligent Manufacturing (2011),
http://dx.doi.org/10.1007/s10845-011-0607-4, Accepted.
[68] A.M. Hickey, A.M. Davis, Elicitation technique selection: how do experts do it? in:
Proceedings of the 11th IEEE International Requirements Engineering Conference,
2003.
[69] A.G. Sutcliffe, M. Ryan, Experience with SCRAM, a scenario requirements analysis
method, in: Proceedings of IEEE International Symposium on Requirements
Engineering, 1998, pp. 164–171.
[70] J. Xiong, New Software Engineering Paradigm Based on Complexity Science: An
Introduction to NSE, Springer, New York, 2011.
Aida Azadegan is a Senior Lecturer in Sheffield Business
School, UK. She received her PhD degree in Information
Systems Design from Manchester Business School, UK
in 2010. Prior to her current position, she was a
postdoctoral research fellow in Nottingham University
Business School, UK where she worked on European
research projects. She has published several papers and
served in Program Committees of International Con-
ferences and as a reviewer of academic journals. Her
current research interests include Facilitated Collabora-
tions, Decision Making, Human Computer Interaction,
User Experience and Serious Gaming.
811
K. Nadia Papamichail is an Associate Professor in
Information and Decision Systems at Manchester
Business School. Her publications have appeared in
books and journals including Decision Support Systems,
Omega, Journal of the Operational Research Society,
Expert Systems with Applications and Artificial Intelli-
gence. She recently co-authored a Cambridge Universi-
ty Press book on ‘Decision Behaviour, Analysis and
Support’. She is Chair of the Decision Analysis special
interest group (DASIG), a network of academics and
practitioners who role is to promote Decision Analysis
in the UK and abroad.
Dr. Pedro Sampaio is a Lecturer in Business Technology
and Information Systems and a former business
technology consultant of McKinsey & Company. He
has published extensively in the topics of Service-
Oriented Systems Engineering, Requirements Engineer-
ing, Fraud Management Processes and Technologies,
Business Process Management, Business/IT Alignment,
Data Quality, CRM, Agile Software Processes, Deductive
Database Systems and Query Processing. He has also
developed Knowledge Reports for McKinsey & Com-
pany’s Internal CRM Practice Knowledge Base. He has
led and participated in research/consulting projects
involving academic and business organizations in the
United Kingdom, Continental Europe, Latin America
and the United States in the Telecom, Banking and IT
industries in topics relating to Services Science, Engineering and Management
(SSME), Security Engineering, Requirements Engineering, Business Process
Management, Customer Relationship Management, Risk Management and Stream-
Based Data Mining. His research has been funded by EPSRC (Case Award), SMEs
in the United Kingdom and by Brazil’s National Research Council (CNPq),
Brazil’s Special Training Programme (PET/CAPES) and Sao Paulo’s State Research
Council (FAPESP). He has acted as an academic partner to IBM/UK developing joint
teaching initiatives between IBM/UK and the University of Manchester. He has also
given invited seminars at Cambridge University’s Security Engineering Group
(January, 2010) and at IBM/UK Smarter Planet Events (Royal Academy of
Engineering, March, 2010). He has published several international peer-reviewed
journal and conference papers and supervised 5 successful PhD students. He holds a
Doctor of Philosophy degree in Computer Science from The University of
Manchester.