Collaboration Engineering: Supporting the Collaborative Processes
Design for the Accessible and Usable Interactive Systems Design
César Collazos
1
, Andrés Solano
2
and Habib M. Fardoun
3
1
Systems Department, Universidad del Cauca, Popayán, Colombia
2
Operations and Systems Department, Universidad Autónoma de Occidente, Cali, Colombia
3
Ahlia University, Bahrain
Keywords: Usability, Collaboration, Thinklet, Usability and Accessibility Engineering Process Model, Moodle.
Abstract: From the Collaboration Engineering approach it is possible to design collaborative processes that could
ensure a collaborative effective work among participants of a working group integrating the available
resources and skills. This paper describes the use of Collaboration Engineering for the design of processes
that support collaborative activities raised by the Usability and Accessibility Engineering Process Model
(MPIu+a) for Requirements Analysis Phase in developing usable and accessible interactive systems.
1 INTRODUCTION
Software development is not an easy task and
involves different aspects that require expertise of
people of different backgrounds and with different
skills. One of the most valuable aspects that are
being considered is related with usability and
accessibility. The User Centered perspective is a
model that involves these aspects taking into account
the user perspective during the development process.
In order to involve collaborative aspects in the
software development, is very convenient to offer
members of the work group, some strategies that
allow them to work in a collaborative manner, using
resources, time and skills of the participants in an
effective and efficient way. The generation of
processes that involve collaborative aspects, could
be done through Collaboration Engineering
proposal, where “collaborative and repetitive
processes are designed, which could be transferred
to the groups using techniques and collaboration
technology” (De Vreede and Briggs, 2005).
There are many development software
methodologies whose objective is the design of
usable and accessible interactive systems. In this
paper the Usability and Accessibility Engineering
Process Model (MPIu+a) (Granollers, 2004) has
been selected since it raises a suitable integration
between the basic foundations of Software
Engineering and the principles of the User Centered
Design, additionally this Model proposes techniques
of requirements analyses, which are centered in the
user. The research presented in this paper support the
collaborative aspect, which is present in the group
dynamics of the activities raised by the MPIu+a in the
Requirements Analysis Phase, through design
collaborative processes, which can be applied in an
independent way of the geographic location of the
development team and system potential users.
Collaborative processes generated have been
obtained through the design methodology for
Collaboration Engineering (Kolfschoten and Vreede,
2007). The next section presents background
information on aspects that support this research.
Section 3 depicts a case study in order to validate the
collaborative process, and finally, some conclusions
and further work will be presented.
2 BACKGROUND
2.1 Usability and Accessibility
Engineering Process Model
(MPIu+a)
MPIu+a is the name of a methodology for the
development of usable and accessible interactive
systems based on User Center Design (UCD)
principles and Software Engineering. One of the
central keys of this methodology is the necessity and
786
Collazos, C., Solano, A. and Fardoun, H.
Collaboration Engineering: Supporting the Collaborative Processes Design for the Accessible and Usable Interactive Systems Design.
DOI: 10.5220/0006941407860793
In Proceedings of the 13th International Conference on Software Technologies (ICSOFT 2018), pages 786-793
ISBN: 978-989-758-320-9
Copyright © 2018 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

importance that the development software be
immersed in the work group perspective, where be
possible to include mechanisms that support groups
dynamics in an appropriate way, including people of
different knowledge disciplines and where the user
participation be the central point of the design
oriented actions (Granollers, 2004). In a multidiscipli-
nary team with diverse mental models and working
ways, it is possible to find difficulties associated with
communication and information sharing among these
persons (Sutcliffe, 2002), MPIu+a brings some
guidelines in order to support the sharing information
and therefore try to reach an effective work.
In the Requirements Analysis Phase proposed in
MPIu+a the necessity of participation as team mem-
bers as system representative users is evident, phase
in which is high-priority to identify suitably who will
be the users and system stakeholders, as well as to
establish an effective communication with them with
the purpose of determining their real necessities. For
this paper we have selected the activities Stakeholders
Identification, Stakeholders Meeting and Users
Classification of the Requirements Analysis Phase,
designing collaborative processes, because they are
activities that require a work team and contribution of
different people in order to reach the final goal.
Stakeholders identification: the objective of this
activity is to determine all the stakeholders of the
interactive system development. From base line, all
the “stakeholders network” is generated (Sharp et al.,
1999).
Stakeholders meeting: once the stakeholders
have been identified, it is necessary to know their
influence in the development project, for which a
meeting must be planned, the key points to be
treated are identified previously (they are related
with objectives, possible users, technological
restrictions, usability objectives, etc.).
User classification: the objective of this activity
is to classify to the users in user profiles and roles,
and to make an association between these profiles
and roles, with the purpose to identify clearly their
characteristics and their roles within the system.
2.1.1 Collaboration Engineering
Collaboration Engineering is defined as “an
approach to designing collaborative work practices
for high-value recurring tasks, and transferring
those designs to practitioners to execute for
themselves without the ongoing intervention of a
professional facilitator” (Kolfschoten et al., 2006).
Researchers over Collaboration Engineering have
determined some similar behaviors in the way
participants work in order to achieve group goals,
these behaviors have been called: collaboration
patterns, which are defined as “moving a group from
some initial state to some end state” (De Vreede and
Briggs, 2005). The collaboration patterns are
(Kolfschoten and Vreede, 2006): generate, reduce,
clarify, organize, evaluate, build consensus.
Once obtained the collaboration patterns, it is
necessary to identify the way to perform them. In
that way, the thinklets may be used to create
repeatable, predictable patterns of thinking among
people making an effort toward a goal (Briggs et al.,
2003, De Vreede et al., 2006). A thinklet is the
smallest unit of intellectual capital to create a known
pattern of collaboration her in order to achieve a
goal (De Vreede and Briggs, 2005).
2.1.2 Collaborative Processes Design
The collaborative process design was made based on
the design methodology for collaboration
engineering proposed by Kolfschoten et al. in the
HICSS-39 Workshop on Collaboration Engineering
(Kolfschoten and Vreede, 2007). The task
Stakeholders Identification has been selected as
example to show the application of the propose
methodology for the collaborative processes design,
next the results obtained in each phase are presented.
Step Task Diagnosis
In this step it is necessary to identify the objectives,
deliverables and requirements of the task from
which the respective collaborative process is
designed. The identification would be made with the
Table 1: Task diagnosis of the stakeholders identification.
Stakeholders Identification:
Objective: identify all the project stakeholders
(even those that could influence negatively)
(Granollers, 2004).
Deliverables:
List of Categories from which the stakeholders
will be identified.
Stakeholders classified in the identified categories.
Role Description of every identified stakeholder.
Requirements:
Knowledge on the Stakeholder concept.
General Description of the system to develop.
Information about the proposals to classify
stakeholders of an interactive system (Newman et
al., 1995).
Information about the methodology for the
classification of users, propose by authors of
Center HCI Design and Computer Science
Department (Sharp et al., 1999).
Collaboration Engineering: Supporting the Collaborative Processes Design for the Accessible and Usable Interactive Systems Design
787

continuous support of expert people in the grasp of
task application (Kolfschoten and Vreede, 2007).
Table 1 presents the result of this activity.
Step Task Assessment
The activities of the task are identified and
evaluated. The evaluation basically consists of
determining if a predefined way to execute the task
exist, in this case, will have to be evaluated if it can
be carried out of collaborative way (Kolfschoten and
Vreede, 2007). Table 2 presents the information
related to the activities identified for the task.
Table 2: Task assessment of the stakeholders
identification.
No Activities Collaborative
1
To generate a list of categories from
which the stakeholders will be
grouped.
Yes
2
To identify the system stakeholders
in the categories previously
generated.
Yes
3
To describe the stakeholder role in
the system
Yes
It is possible that some activities are identified
like non collaborative ones, the criterion in which
we have been based to define them of this way is
that the execution of these activities don't require
consensus on the matter or that different points of
view are considered. The non-collaborative activities
can be executed by a single person or they don't
imply a work in equipment.
The criterion that was considered to determine if
an activity is collaborative is that this activity can
imply a group work for its execution. In the
Stakeholders Identification task, it has been
considered that all the activities that conform it can
make of collaborative way.
Step Activity Decomposition
In this step the form in which the group would make
the collaborative activity is analyzed and this
behavior of work is associated with the identified
Collaboration Patterns in the Collaboration
Engineering. Result for one of the collaborative
activities of the Stakeholder Identification Task is
shown in Table 3.
Table 3: Activity decomposition of the stakeholders
identification.
Related activities: identification of system stakeholders
in the categories previously generated (Activity 2).
Description: for each one of the defined categories, the
members identify the system stakeholders that consider
belong to this category.
Inputs: list of categories.
Results: list of system stakeholders, below to each one of
the categories.
Observations: this activity is due to carry out for each
one of the categories that previously have been generated
that corresponds to some proposal of classification.
Group: group of people in charge of the Phase of
Analysis of Requirements.
Patterns Justification
Generate To generate a list of system stakeholders that
belongs to each one of the categories.
Evaluate The team members verify that the
stakeholder belong to the categories in which
they were assigned.
Step Thinklet Match
Once associated the Collaboration Patterns to the
different activities, each one of them is related with
the thinklet that is considered can support the
Table 4: Thinklet match of the stakeholders identification.
Description: the categories defined previously are
presented to the participants in different pages, so that
they identify in each one of them the project stakeholders
pertaining to this category. Later, the team members
must identify if there is some stakeholder that it does not
belong to the category in which is classified, in this case
the participant would have to propose the category where
considers that it must be classified and a discussion is
generated (other participants express their
commentaries).
Pattern Thinklet Reasons of selection of the
Thinklet
Generate LeafHopper
The team members can list
system stakeholders on the
categories in which they have
the most interest or the most
expertise.
Evaluate BucketWalk
It's pertinent to generate
discussion with respect to the
location of the stakeholders.
It's necessary to validate that
each one of the stakeholders
corresponds to the assigned
category.
IDEE 2018 - Special Session on Interaction Design in Educational Environments
788

execution of the activity. The thinklets identified for
the different activities, must be adapted to the
resources, the group and to the abilities of the people
involved in the execution of the collaborative
processes (Kolfschoten and Vreede, 2006). Result of
applying this step in the activity described in Table 3
is displayed in Table 4.
Step Design Documentation
From information obtained in the previous steps,
some documents defined in Collaboration
Engineering are generated, which are: Process
Description, Detailed Agenda and Facilitation
Process Model (Kolfschoten and Vreede, 2007).
Process Description is a document that presents
general information related to the collaborative
process design. Table 5 shows the Process
Description for the Stakeholder Identification.
Detail Agenda: The detailed agenda is a
document that contains parameters to define the
activities that comprise of the designed process, the
agenda should specify all information related to the
thinklet, which were identified in the designed
process. The Detailed Agenda of the Stakeholders
Identification is displayed in the Table 6.
Facilitation Process Model (FPM) is used to
display the process flow, and critical elements in this
flow. For each one of the activities that conform the
designed Collaborative Process, the number of
sequence (corresponding with the detailed agenda),
pattern of collaboration, thinklet name, description
of the activity and the suggested time to each
activity are presented (Kolfschoten and Vreede,
2007). A FPM of the Stakeholders Identification
task is displayed in Figure 1.
Figure. 1: FMP of the Stakeholders Identification Task.
Step Design Validation
There are four forms to validate the design: pilot
testing, walk-through, simulate and reviewing
(Kolfschoten and Vreede, 2007). The validation of
the designed collaborative process for the
Requirements Analysis Phase was made through the
test pilot, which is an implementation of the
collaborative process in order to evaluate the
effectiveness of the process. This validation will
reveal whether the process can be done with the
considered time and with the given group and
resources (Kolfschoten and Vreede, 2007).
Table 5: Process description for stakeholders identification.
Process description
The person in charge of the activity invites to each one of the participants to write in different pages the categories in
which they consider the system stakeholders must be grouped. Later, it is requested to the team members that make
commentaries on each category, whether or not they think is pertinent that this category be part of the final categories
list.
• Taking the propose categories list and the respective commentaries, the person in charge of the evaluation presents
to participants a categories list, from which they must identify.
• Similar categories. The participants are invited to present the similar categories to the rest of the group and explain
the reason for which they consider that these categories are similar, the group must decide if the categories are
combined or any of them is eliminated.
• Categories that present ambiguity, so that these are clarified by some other team member or alternating categories
names are suggested.
• Categories that must be eliminated of the list.
The categories defined previously are presented in different pages; the participants identify in each one the project
stakeholders. Later, it is requested to the team members to identify if some stakeholder does not belong to the category
in which is classified, in this case the participant would have to propose the category where he considers that the
stakeholder must be classified and a discussion is generated so that the other participants express their commentaries.
Finally, in different pages the stakeholders are displayed so that the members identify in each one of them the role that
carries out in the project.
Collaboration Engineering: Supporting the Collaborative Processes Design for the Accessible and Usable Interactive Systems Design
789

Table 6: Detailed Agenda for stakeholders identification.
# Task Deliverable Question/Assignment Thinklet Time
0 To provide to the team members
the daily routine and the points
to treat.
Knowledge of the
participants about
the activity.
1 day
1 To generate a list of categories,
in which, the participants
consider the stakeholders must
be grouped.
List of Categories to
group the
stakeholders.
Please, write the categories in which you
consider the system stakeholders must be
grouped.
Free-
Brainstorm
(Generate)
3 days
2 To eliminate redundancies and
ambiguities of the list of
categories.
List of categories,
neither redundancies
nor ambiguities.
Please, identify from list of categories
those that are similar, present ambiguity or
must be eliminated.
Concen-
tration
(Clarify)
3 days
3 To generate a list of system
stakeholders for each category
List of Stakeholders. Make your contributions with respect to
the system stakeholders that you consider
b
elong to the categories. Start working on
the topics in which you have the most
interest or the most expertise.
LeafHopper
(Generate)
4 days
4 To verify that the stakeholders
belong to the categories to
which they were assigned.
Set of stakeholders
in the respective
category.
Is there some stakeholder in the category
that does not belong to this?
BucketWalk
(Reduce)
3 days
5 To generate commentaries
about the role that each one of
the identified stakeholders
carries out in the system.
Role Description
that each one of the
stakeholders in the
system.
Make your contributions with respect to
the role that this stakeholder carries out in
the system. Start working on the
stakeholders in whom you have the most
interest or the most expertise.
Leaf-Hopper
(Generate)
7 days
3 CASE OF STUDY
The validation of collaborative process for
Requirements Analysis Phase, was made through
project “Virtual Learning Objects Repository -
LOR”, which consists of making an analysis and
design of Virtual Learning Objects Repository, to
support pedagogical process for the virtual education
in Universidad Abierta y a Distancia (UNAD),
Colombia.
General information about the project
The principal objective of the validation for the
Requirements Analysis Phase is to know system
users and their necessities. For which it is necessary:
• To identify all the LOR project stakeholders
(even those that could influence negatively).
• To determine the influence of each one of the
stakeholders in the development of the project.
• To identify user roles and profiles and to
determine the relations between these profiles
and roles.
Stakeholders information:
In the team for execution of Stakeholders
Identification, we have identified the stakeholders
and their respective roles (see Table 7).
Table 7: LOR Project Stakeholders and Roles.
Member Role
Geographic
location
Cauca University
Teacher
Evaluator
Popayán,
Colombia
Systems Engineering
Students
Evaluators
Popayán.
Colombia
UNAD Teacher
LOR Project
Management
Popayán,
Colombia
UNAD Teacher
LOR Project
adviser
Popayán,
Colombia
Three Systems
Engineering
Students, UNAD
People in charge of
Requirements
Analysis and
Developers
Popayán,
Colombia
Doctoral Program in
Computer Science
Student, Lleida
University.
Person in charge of
Requirements
Analysis
Lleida, Spain
Systems Engineering
Students, Cauca
University.
People in charge of
the activity
Bogotá,
Colombia
IDEE 2018 - Special Session on Interaction Design in Educational Environments
790

The initial criterion for the selection of the
members was to have interested people in to develop
of interactive systems supported under the
methodology proposed by the MPIu+a, as well as of
the initiative to motivate effective practices of
collaborative work within the team members.
Additionally, we looked for to involve people who
were dispersed geographically.
Technology
The tool selected for the validation of the designed
Collaborative Processes is Moodle, which is a
software package for the creation and handling of
courses in Internet. This tool presents some
advantages that are described next (Moodle, 2018):
• It is designed under the foundations of social
constructive pedagogy.
• It allows establishing access keys.
• The participants can create their own profile.
• The user can choose the language of Moodle
Graphic User Interface (Moodle is available in
more than 70 language).
• Moodle has a variety of resources and
activities for courses.
• The home page presents the changes since the
last user's income, which contributes to a
sense of community.
• The resources can be configured so that
whether or not visible to the participants.
Moodle was selected by the benefits mentioned
above, on the other side the resources offered by the
platform could be employed to implement the
collaborative processes designed. In addition, the
tool provides an opportunity for participants to
generate discussions, make contributions, analysis
and reflection on the contributions of other members
of the group, contributing to the construction of
shared knowledge and decision-making. The Table 8
presents the information related to the adequacy of
one of the Moodle forums (according to the options
available in the tool for configuring forums), to run
one of the activities of the task Stakeholders
Identification, which is to apply the thinklet
Concentration in order to deleting redundancies and
ambiguities in the proposed list of categories.
Results achieved
The results for the case study from the validation of
the collaborative processes designed is as follows:
The categories to group stakeholders and
stakeholders in each one of them were determined,
as well as their description and relationship with the
Project. Below the categories and their stakeholders
are presented:
End Users: In this category are all people who
interact directly with the system, the stakeholders of
this category are: External Visitor, Administrator,
Student, Assessor, Tutors and Teachers.
Table 8. Information Forum “Categories not redundant nor ambiguous”.
Type Forum: Forum for general use.
Procedure:
The list of categories that have been identified, as follows:
• End Users: This category comprising students, teachers, special users (those who will use the resources and
activities available on the website).
• Developers: it includes all people related to the design and development of website.
• Sponsors: This category includes people or entities that might sponsor or support with resources to the
development site.
Some categories may be similar, ambiguous or must be removed from the list. Please identify them and select them.
Suggestion
It is recommended to write each of the categories that are similar or ambiguous in a new item, with the category name
in the subject. You can use the body of the message the write the identified characteristics and contributions (depending
on the property identified) with respect to: (a) the reason that you think that the categories are similar, (b) aspect that is
not understood in that category and (c) the reason that you think that the category must be removed.
For each of the categories proposed by the other team members, you can make: (a) proposing the combination of the
categories or eliminating any of them, if you have noticed similarities between them, (b) explain a category where
information is not sufficiently clear and (c) arguments against or in favor of eliminating the category.
Allowing any participant opens new issues: allowing new topics and answers.
Collaboration Engineering: Supporting the Collaborative Processes Design for the Accessible and Usable Interactive Systems Design
791

Developers: refers to the people who are
involved with the system in its development stage,
such as: Project Manager, User Developer, Experts
Evaluators, Instructional designers, graphic
designers, responsible for Requirements Analysis,
Programmers, advisers Development.
Sponsors: these are involved in influencing the
development of the project in terms of financial
support and other resources, in this category are:
Managers UNAD, Semillero de Investigación en
Ambientes Virtuales de Aprendizaje SIUNAD,
System Research Unadista (Sistema de Investigación
Unadista).
The roles, user profiles, and the relationship
between them were determined, obtained the
following results:
Designing a Method of Collection of
Information for the purpose of obtaining information
from users of the system.
List of User Profiles System, which identified:
External Visitors, Students, Tutors, Teachers. List of
User Roles, the roles refer to the function that could
be played by users to interact with the system. The
roles are identified: Consultant (who will be
searched and downloaded of Virtual Objects),
Builder (who designs and builds Virtual Objects),
Evaluator (authorizing the issuance of Virtual
Object), Administrator (manages users and
privileges).
We performed an association between roles and
user profiles. It is important to mention that a role
can be associated with many profiles and vice versa.
The association is presented in Table 9.
Table 9: Association between user roles and profiles.
Profile Role
Extarnal Visitor Consultant
Student Consultant
Teacher Consultant, Builder, Evaluator
Tutor Consultant, Evaluator
Manager Manager
Other results were obtained like a description of the
user profile, their common needs and the definition
of usability and functional objectives.
Summary of results from thinklets
As the selection of each thinklet in the design of
collaborative processes was justified, we performed
an analysis based on the participation of the team
members in these processes to determine whether
the issues considered each thinklet met during the
execution of activities. Table 10 presents some of
the thinklets and comments respective.
Table 10: Results by Thinklet.
Thinklet Comments
LeafHopper In each case the complete list of issues were presented for which contributions were generated in each
one of them, so that the group could make their contributions on those areas in which they had more
experience and knowledge. Members of the group were able to generate insights into various aspects
and additionally had the opportunity to make comments regarding the contributions of their partners.
FreeBrainstorm This technique enabled the group could generate a wide range of ideas and contributions on the various
topics of discussion raised. Members of the group had a chance to comment on the contributions of
others, which in some cases are allowed to generate discussions and exchange of views among all. Each
contribution was argued by the author, this helped to generate shared information within the group.
Concentration Members of the group had the space available to indicate their concerns and findings when a concept
was not clear enough or when some contributions of the other members were redundant; also, could
clarify an idea, or make proposals for elimination or combination of ideas some approach redundant.
This was made possible thanks to everyone could freely express arguments to support a proposal, as
well as express opinions envelopes contributions of others. This thinklet made it possible to generate
clear and accurate information, to facilitate the development of subsequent activities.
Bucket-Walk Members of the group had the opportunity to express their comments respect the opinions of their
partners, this allowed generate a discussion and find an appropriate form of classification. The
discussion generated among members of the group made possible to reach agreements and shared views.
PopcornSort This thinklet allowed quickly organize a joint informal comments. The team had a chance to argue and
justify their proposals, which made possible to generate discussion with other members of the group,
motivating to generate new ideas and contributions.
IDEE 2018 - Special Session on Interaction Design in Educational Environments
792

4 CONCLUSIONS
Collaboration Engineering approach presents
fundamental support to the Computer Supported
Collaborative Work, since through this approach it is
possible to design processes that demonstrate the
presence of communication, coordination and
collaboration between the group members. The
methodology of design for the Collaboration
Engineering allows the collaborative processes
design in different environments, in a specific way
in the development of usable and accessible
interactive systems.
Collaboration Engineering approach makes
possible the generation of strategies that fortify the
collaborative aspects and the guidelines raised in the
MPIu+a for the suitable flow of the communication
and the information among the members of the
multidiscipline equipment, especially in those
environments of work where the actors are dispersed
geographically.
It is necessary to conform work teams by people
of different disciplines, teams should be present
spaces in which there is an interchange of
communication and information adapted among the
teams members. With Collaboration Engineering it
is possible design collaborative process that support
the implementation of the dynamic in the activities
of each one of these phases.
Collaborative processes design, constitute a
framework for the multidisciplinary team who try to
follow the principles of Design Centered User for
the development of interactive systems, which
represents a significant contribution to the propose
activities in the MPIu+a. The geographic dispersion
of the participants in a work group does not have to
be considered a weakness to structure, design and
handle processes that are carried out in a
collaborative way. It is possible to mention some
technological tools which can support the
synchronous and asynchronous work between the
participants through implementation and use of
suitable collaborative strategies.
The documentation obtained can be used by the
people in charge to make the activities for which the
collaborative processes were designed, they are no
need to have the continuous aid of the people in
charge of the processes design. The collaborative
processes design can be used in the development of
different interactive systems, since they were
designed independently of the Interactive System in
which they went away to apply.
The future work includes the design of
collaborative processes for the different activities
that comprise of the MPIu+a, as well as the
validation from all the designed processes in the
development of an Interactive System.
REFERENCES
Briggs, R. O., De Vreede, G. J. & Nunamaker J. R., J. F.
2003. Collaboration engineering with ThinkLets to
pursue sustained success with group support systems.
Journal of Management Information Systems, 19, 31-
64.
De Vreede, G. J. & Briggs, R. O. Year. Collaboration
engineering: designing repeatable processes for high-
value collaborative tasks. In: Proceedings of the 38th
Annual Hawaii International Conference on System
Sciences 2005. Published by the IEEE Computer
Society.
De Vreede, G. J., Koneri, P. G., Dean, D. L., Fruhling, A.
L. & Wolcott, P. 2006. A collaborative software code
inspection: the design and evaluation of a repeatable
collaboration process in the field. International
Journal of Cooperative Information Systems, 15, 205-
228.
Granollers, T. 2004. MPIu+a una metodología que integra
la ingeniería del software, la interacción persona-
ordenador y la accesibilidad en el contexto de equipos
de desarrollo multidisciplinares. Tesis Doctoral,
Universidad de Lleida.
Kolfschoten, G. & Vreede, G.-J. D. 2006. Thinklet Design
Support Booklet.
Kolfschoten, G. & Vreede, G.-J. D. Year. The
Collaboration Engineering Approach for Designing
Collaboration Processe. In: International Conference
on Groupware: Design, Implementation and Use,
2007.
Kolfschoten, G. L., Briggs, R. O. & Vreede, G. Year.
Definitions in Collaboration Engineering. In:
Proceedings of the 39 Hawaii International
Conference on System Sciences, 2006.
MOODLE. 2018. moodledocs [Online]. Available:
http://docs.moodle.org/es/ [Accessed January 2018].
Newman, W. M., Lamming, M. G. & Lamming, M. 1995.
Interactive system design, Addison-Wesley
Wokingham.
Sharp, H., Finkelstein, A. & Galal, G. Year. Stakeholder
identification in the requirements engineering process.
In: Database and expert systems applications, 1999.
proceedings. tenth international workshop on, 1999.
IEEE, 387-391.
SUTCLIFFE, A. 2002. User-centred requirements
engineering, Springer Science & Business Media.
Collaboration Engineering: Supporting the Collaborative Processes Design for the Accessible and Usable Interactive Systems Design
793