Content uploaded by Rosa Alarcón
Author content
All content in this area was uploaded by Rosa Alarcón
Content may be subject to copyright.
J.A. Jacko (Ed.): Human-Computer Interaction, Part III, HCII 2009, LNCS 5612, pp. 67–76, 2009.
© Springer-Verlag Berlin Heidelberg 2009
Understanding the Relationship between Requirements
and Context Elements in Mobile Collaboration
Sergio Ochoa1, Rosa Alarcon2, and Luis Guerrero1
1 Universidad de Chile, Computer Science Department
{sochoa,luguerre}@dcc.uchile.cl
2 Pontificia Universidad Catolica de Chile, Computer Science Department
ralarcon@ing.puc.cl
Abstract. The development of mobile collaborative applications involves
several challenges, and one of the most important is to deal with the always
changing work context. This paper describes the relationship between these
applications requirements and the typically context elements that are present
in mobile collaborative work. This article presents a house of quality which
illustrates this relationship and shows the trade-off involved in several design
decisions.
Keywords: Context Elements, Software Requirement, Mobile Collaboration,
House of Quality.
1 Introduction
One of the most challenging activities when developing software applications is to
understand how user needs are satisfied by the application’s functionality. Groupware
applications are not an exception, and although determining groupware users' needs in
advance and creating the correspondent software may seem uncomplicated, the ex-
perience proves that it is not the case and that groupware users will refuse to use col-
laborative systems that do not support their needs in a wider context [Gru94; Luf00;
Orl92; Suc83].
In addition, typical groupware applications have been criticized for being decon-
textualized, they do not consider the complex conditions (e.g., social, motivational,
political or economic factors), where software will be executed causing users to reject
the system [Gru94, Lju96, Bar97]. The problem is that most groupware developers
usually focus almost exclusively on the analysis and specification of functional re-
quirements neglecting the non-functional ones. Furthermore, users may be unaware of
their needs in a wider context (e.g. social, physical, etc.), so that, by simply asking
them to identify their requirements, software developers may not obtain the appropri-
ate information [Ack00].
User’s needs are translated into functional requirements and some functions are im-
plemented to satisfy such requirements. However, the appropriateness of such function-
ality is mostly evaluated later, when the software has been built. Misconceptions at that
68 S. Ochoa, R. Alarcon, and L. Guerrero
point in the software life cycle are costly, which adds to the costs of groupware testing.
Hence, new techniques are required in order to understand in advance the impact of the
intended functionality on user’s needs in a wider context.
One of such techniques is the Software Quality Function Deployment (QFD). QFD
can be considered as a set of methods that allows contrasting the customer require-
ments with the product functionality and can be applied at each product development
stage [Cha03, Haa96]. QFD aims to understand how users’ needs are intended to be
satisfied; it is a consumer-driven process. Typically, QFD is applied in four stages:
product planning, parts deployment, process and control planning and production
planning. Each step produces a matrix that serves as an input to the subsequent steps.
Due to its shape, the matrix is called a House of Quality (HOQ) [Kus99].
A HOQ relates customer requirements with technical descriptions of the product,
including design activities. That is to say, the HOQ captures the essentially non-linear
relationships between functions offered by the system and customers needs. Conflic-
tive features become apparent and trade-offs are identified early in the design process.
QFD has been used successfully for identifying customers and their needs [Mar98]
considering user satisfaction as a measure of product quality.
The use of formal tools that accompanies software development has been proven to
be significant in various industries and some researches had accounted the usefulness
of QFD for the design of groupware applications [Ant05, Gle04]. However, due to the
complexity of groupware design, we believe that technical descriptions are not
enough for analyzing whether user’s requirements are met or not. As stated by Grudin
[Gru94] and Ackerman [Ack00], among others, groupware users needs go beyond
technical functionality and involves various contexts of analysis, such as social, tech-
nological, and physical context.
Based on a framework for contextual design derived by the authors [Ala06], the
QFD technique and the authors’ experience, we present a correspondence matrix that
shows the relationship between typical mobile groupware requirements and context
elements inclusion. The analysis shows that trade-offs appear early during design, and
some context have up to 9 relationships. Our aim is to provide groupware developers
with formal software techniques that help them to reduce software costs while enrich-
ing its quality. We believe that such quality is strongly related with the contextualiza-
tion degree of the application.
Section 2 presents the context elements that typically are involved in mobile
groupware applications. Section 3 describes the groupware requirements involved in
the development of these tools. Section 4 presents the derived HOQ as well as an
analysis of the relationships between user’s requirements and context elements. Fi-
nally, section 5 presents the conclusions and future work.
2 Context Elements
The authors defined a set of context elements that are briefly explained below. Con-
text elements should be considered during the development of collaborative mobile
applications and are represented in the columns of the HOQ shown in figure 1.
Understanding the Relationship between Requirements and Context Elements 69
Readiness to use IT. This context element allows determining the group members’
preparation for using Information Technology tools. Users’ experience, readiness to
use technology and learning will influence the kind of interaction dialogues, inter-
faces, protocol design options and even the project feasibility.
Previous formal context (e.g., rules and regulations). This context element assists on
characterizing users’ information needs, as well as the actions the group should per-
form in order to conform to such regulations.
Previous informal context (e.g., social conventions and protocols). Unlike formal
contexts, social conventions naturally emerge during everyday users’ interactions.
They cannot be imposed and they constitute a frame for understanding each other
behavior and purposes.
Work practice tools. Every work practice community usually develops its own
tools. These tools are not necessarily supported by technology. Provided they mediate
social interactions, they can assist the analyst to understand the current underlying
workflow.
Group members interaction. This context element helps identify general interaction
scenarios among group members in order to determine which of them require mobile
support. Such interaction must consider users’ communication needs for data and/or
voice transfer.
Mobility Type: mobile coupled. This context element represents a type of mobility
that can be present in a collaboration scenario. Group members performing mobile
collaboration activities in a synchronous way are considered as carrying out mobile
coupled activities.
Mobility Type: mobile uncoupled. This context element represents to the asynchro-
nous work carried out by mobile workers during a collaboration process.
Communication requirements. Communication can be direct or mediated; public,
private or a mixture; broadcast or multicast. This context element represents the
communication requirements of a mobile collaboration activity. Communication
strategies constrain the coordination strategies that can be applied.
Coordination requirements. Coordination elements and policies are contextual
element that needs to be identified. Some of these elements are: support for session
management; floor control administration; user roles support; shared information
handling.
Activity criticality. It is important to determine the urgency of achieving the activity
goals and the activity importance for the user. These criteria may influence the choice
of communication and coordination strategies.
Activity duration. Except for the case of mobile phones, activity duration in mobile
collaboration based on PDAs, notebooks or Tablet PCs can be critical as it could be
restricted by battery life. This context element identifies the activity duration and the
requirement of power supply.
70 S. Ochoa, R. Alarcon, and L. Guerrero
Organizational structure (rigid/flexible). The organizational structure will influence
the group needs for coordination and control policies. A rigid organization requires
formal coordination with strict control, but flexible organizations must quickly react
to environmental changes. This context element represents the type structure of the
organization that host mobile workers.
Collaboration policies/rules/norms/conventions. Every organization develops a series
of social protocols, policies, rules and norms that regulate its workflow. It is impor-
tant to identify which are the social rules that may be relevant for the intended col-
laborative application.
Group size. Group size matters. Research in groupware has pointed out the impor-
tance of group size for the success of the coordination, communication and collabora-
tion strategies. Most groupware design elements will be affected by the group size.
Roles. An appropriate identification of roles will help developers to design useful
applications. Otherwise, the collaborative mediation process could not be well sup-
ported. Clearly it may have a meaningful impact on the group performance.
Group structure. The relationships among roles will define the group structure.
An understanding of the group structure and the relationship between it and the organ-
izational structure could be useful to design the interaction policies to support
collaboration.
Demographics. It is also important to take into account the users’ characteristics, e.g.,
their age, gender, race, and language may influence the application design. Usability
of the application will probably be improved when considering this context element.
Physical space. This element represents the available space for deploying and operat-
ing the collaborative mobile application. The smaller/less comfortable/less stable the
physical available space is, the less likely is to use large or heavy computing devices.
Adverse environmental conditions. This context element represents physical condi-
tions such as noise, light, number of people around and distracting factors. These
factors impose restrictions over the type of user interface to be used for interacting
with the collaborative application.
Safety and privacy. These are two important context elements to consider during the
application design in case of mobile applications being used in public spaces. Hand-
held devices are especially appropriate for use in public spaces.
User location (positioning). Traditionally in groupware, it refers to users’ location
within the virtual environment and is known as location awareness. Current technol-
ogy lets users locate the partners in the physical world.
Power supply. The activity duration is in direct relation with this context element. The
analysis of this element helps developers to identify if the power autonomy of the
selected mobile device is enough to support each activity.
Understanding the Relationship between Requirements and Context Elements 71
Communication capability. This context element represents the availability of net-
working infrastructure in the work scenario. This element also includes the communi-
cation bandwidth that is possible to get in the physical scenario for supporting the
mobile collaboration activity.
Uptime effort. A mobile device may need short start-up time, e.g., when users have
little time periods to carry out work or when quick reactions are required. This ele-
ment represents the effort to leave available the mobile application.
Transportability. It is important to identify those activities requiring mobility and to
estimate the effort the users are able to spend while transporting the devices.
Computing power. This element represents the processing and storage capacities re-
quired for a mobile computing device. Based on that, more than one device type can
be selected to support activities with different requirements.
3 Computer Supported Mobile Collaboration Requirements
Based on a literature review and the authors’ experience, this section describes gen-
eral requirements of collaborative mobile solutions. These issues will be useful to
help understand the type of applications and capabilities required to work in a specific
scenario. Next, a brief explanation of each requirement is presented.
Interoperability. The interoperability of a collaborative mobile application has two
faces: communication capability and interaction services of the mobile units. Com-
munication capability involves the threshold, protocols and infrastructure used to
support the communication process among mobile units [Ald06, Kor01, Tsc03]. The
structure and meaning of all information shared among the applications should be
standardized in order to support any kind of interoperability.
Multimedia support. If the application requires capturing, managing and/or transmit-
ting heavyweight data types, such as image, video or audio, smaller the device size
more limited will be the solution. The features of each device limit the quality and
quantity of data that is able to capture, store and transmit.
All road. Typically the nomadic work makes the work context changes periodically,
therefore the groupware application has to be context-aware, and also it has to con-
sider as much work scenarios as possible.
Robustness. Nomadic work requires an important effort of the persons that use the
computer-based applications. Several distracting events and interruptions are happen-
ing around them. Therefore, if the mobile groupware application is not robust and
able to consider these distracting factors, then the users could not utilize the applica-
tion to support the nomadic work.
Autonomy. Typically, the nomadic workers carry out loosely-coupled work. It means
they work autonomously and collaborate on-demand. Such autonomy must be pro-
vided by the software tool; therefore it must avoid using centralized resources.
72 S. Ochoa, R. Alarcon, and L. Guerrero
Usable or usefulness. The functionality provided by the tool, the design of the user’s
interfaces, and mobile computing device utilized to perform a mobile collaborative
activity, influence the usability of the solution in the work field. These three elements
must be considered during the application design in order to improve the impact of
the solution.
Synchronous/asynchronous work. Mobile collaborative applications require syn-
chronous/asynchronous communication capabilities depending on the type of
activity to be supported (synchronous or asynchronous). If asynchronous commu-
nication is required, every mobile computing machine is able to provide such sup-
port based on minimal network availability. On the other hand, if synchronous
communications is required, a permanent and stable communication service should
be provided independently of the environment the user is located [Sar03]. Mobile
phones supported by cellular networks are typically the best option for synchro-
nous communication provided their large coverage range and good signal stability
[Mal02]. However, these networks have a limited bandwidth. Another option is to
provide synchronous communication capabilities to mobile applications using a
Wi-Fi communication infrastructure [Rot01, Kor01]. Although the bandwidth is
better than cellular networks, Wi-Fi signal stability depends on the physical envi-
ronment where it is deployed [Ald06]. Furthermore, this type of networks has a
limited coverage range [Mal02].
Portability (transportability). If the application requires to be used on the move,
transportability is a strong requirement. Typically, the way to address this issue is
through the mobile computing device chose to support the collaborative work.
Smaller the device size the more transportable is the device. However, the device size
reduction implies restrictions at least on the screen size and input capability [Kor01].
Privacy. If the privacy is an important requirement, mobile computing devices usually
have small screens, and thus, they provide better privacy protection than notebooks
and tablet PCs if data displayed on screen needs to be hidden from other people in
public spaces. Furthermore, the physical distance between the user and the handheld
device during the interactions is shorter than the distance between a user and his/her
notebook or tablet PC. Another privacy consideration in mobile collaboration is the
visibility of the users and users’ actions in MANETs or public networks [Kor01].
Ensuring accuracy of location information and users’ identities, and establishing pri-
vate communication could be a critical issue in some cases [Che00].
Long time support (battery life). Activity duration in mobile collaboration provide a
strong requirement on the type of device can be used to support it. Many researchers
have identified the battery life as critical to support mobile collaboration [Kor01,
Gue06]. However, the use of context-information provides a way to optimize the use
of power supply resulting in a longer lasting battery life [Che00, Hak05]. On the other
hand, it is always possible to carry extra batteries when PDAs, notebooks or Tablet
PCs are used. Activity duration is not so critical in the case of mobile phones because
these devices are able to work for many hours without being re-charged [Hak05].
Understanding the Relationship between Requirements and Context Elements 73
Capability to be deployed. Handheld devices are easy to deploy and carry, and also
they require low user’s attention and have short start-up time. These features allow
fast reaction from the users; such speed could be critically needed in these physical
environments.
Mobility. Users’ mobility on a physical environment depends on the features of the
physical environment where the users are located and the current environmental con-
ditions. A user equipped with a mobile computing device can be traveling, wandering
and visiting [Kri00]. Traveling is defined as the process of going from one place to
another in a vehicle. Wandering, in turn, refers to a form of extensive local mobility
where an individual may spend considerable time walking around. Finally, visiting
refers to stopping at some location and spending time there, before moving on to
another location. Sarker and Wells report that “the optimal size of a device associated
with wandering was necessarily lower than an acceptable device size when visiting or
traveling” [Sar03].
Performance. The processing power needed for certain mobile applications can ex-
ceed what handheld devices can currently offer [Kor01, Gue06]. However, in case of
PDAs, it is possible to find commercial devices with CPU speeds higher than 500
Mhz. The processing power limitation of these devices becomes visible, e.g., while
processing multimedia information. Although every mobile computing device is able
to address basic multimedia needs, just notebooks and tablet PCs are able to handle
strong multimedia requirements, such as support for 3D games.
Storage. Storage restrictions have been reported in the literature, especially related to
handheld devices [Kor01]. However, these devices keep improving their storage and
memory capacities. Last versions of these devices allow mobile applications to man-
age and store complex data types, even simple multimedia information.
Data input. A possible requirement for a mobile collaborative application is the need
for massive data entry. Typically, the mobile computing device used to support the
solution will play a key role. PDAs and mobile phones use pen-based data input,
which is slow, but also useful to support short annotations [Buy00, Sar03]. On the
other hand, notebooks and tablet PCs are the most appropriate devices to support data
intensive processes using the keyboard.
4 House of Quality
The correspondence matrix, also called House of Quality (HOQ), has typically three
parts (Fig. 1): customer requirements (leftmost rectangle), technical descriptions (up-
per rectangle), and relationships between customer requirements and technical de-
scriptions (centered rectangle). In addition, the grey line shows the direction in which
each relationship should be enhanced in order to improve the application’s capability
to support the mobile work.
74 S. Ochoa, R. Alarcon, and L. Guerrero
Fig. 1. House of Quality
Analyzing the matrix it is possible to see that around a 30% of the intersections be-
tween rows and columns have some kind of relationship. It means each design deci-
sions should be made carefully. The positive relationships must be increased and
enhanced, and the negative ones should be minimized and neutralized. In addition,
applications with high degree of interoperability among various software tools as well
as coupled interaction pose the major challenges as they consume several resources
(storage, bandwidth, battery) and may compromise application’s robustness, mobility,
and performance.
Authors expect this matrix helps developers to make fast and accurate decisions
during the development process. When a design decision has to be made, the designer
will evaluate their alternatives, against the HOQ, in order to determine which is the
most appropriate. Therefore, the proposed tool not only systematizes and facilitates
the decision making process, but also it makes it cheaper and expedite.
5 Conclusions and Future Work
The article presents the typical users’ requirements and work contexts that are present
in the development of mobile groupware applications. The paper also presents and
analyzes the relationship among these two set of components.
Understanding the Relationship between Requirements and Context Elements 75
The analysis shows that trade-offs appear early during the application design. In
addition, such analysis allows designers to easily identify the context variables that
should be monitored in order to detect a work context change, or improve the users’
interaction paradigm. Our aim was to provide a tool (the HOQ) that allows mobile
groupware developers to improve software quality, in term of usability and effective-
ness, through the improvement of the decision making process at the design time. We
believe that product’s quality is strongly related with the contextualization degree of
the mobile application.
As a next step, we are analyzing in detail three mobile groupware applications, in
order to show how the HOQ can be used to support particular design decisions, and
also to show the impact these decisions have in the products’ usefulness. If the au-
thors assumptions becomes true, this proposal could have an important impact in the
development of mobile groupware applications.
Acknowledgements
This work was partially supported by Fondecyt (Chile), grant Nº 11060467, and
LACCIR grants No. R0308LAC001 and No. R0308LAC005.
References
1. Ackerman, M.S.: The Intellectual Challenge of CSCW: The Gap Between Social Re-
quirements and Technical Feasibility. Human Computer Interaction 15(2/3), 179–204
(2000)
2. Alarcón, R., Guerrero, L., Ochoa, S., Pino, J.: Analysis And Design of Mobile Collabora-
tive Applications Using Contextual Elements. Computers and Informatics 25(6), 469–496
(2006)
3. Aldunate, R., Ochoa, S., Pena-Mora, F., Nussbaum, M.: Robust Mobile Ad-hoc Space for
Collaboration to Support Disaster Relief Efforts Involving Critical Physical Infrastructure.
ASCE Journal of Computing in Civil Engineering. American Society of Civil Engineers
(ASCE) 20(1), 13–27 (2006)
4. Ramirez, J., Antunes, P., Respício, A.: Software Requirements Negotiation Using the
Software Quality Function Deployment. In: Fukś, H., Lukosch, S., Salgado, A.C. (eds.)
CRIWG 2005. LNCS, vol. 3706, pp. 308–324. Springer, Heidelberg (2005)
5. Bardram, J.: I Love the System -I just don’t use it! In: Proc. of International ACM SIG-
GROUP Conf. on Supporting Group Work, Phoenix, US, pp. 251–260 (1997)
6. Buyukkokten, O., Garcia-Molina, H., Paepcke, A.: Focused Web Searching with PDAs.
Computer Networks. International Journal of Computer and Telecommunications Net-
working 33(1-6), 213–230 (2000)
7. Chan, L.K.V., Wu, M.L.V.: Quality Function Deployment: A Comprehensive Review of
Its Concepts and Methods. Quality Engineering 15(1), 23–36 (2003)
8. Chen, G., Kotz, D.: A Survey of Context-aware Mobile Computing Research. Dept. of
Computer Science, Dartmouth College, Tech. Rep. TR2000-381 (2000),
ftp://ftp.cs.dartmouth.edu/TR/TR2000-381.ps.Z
76 S. Ochoa, R. Alarcon, and L. Guerrero
9. Glew, P., Vavoula, G.N., Baber, C., Sharples, M.: A ‘learning space’ Model to Examine
the Suitability for Learning of Mobile Technologies. In: Attewell, J., Savill-Smith, C.
(eds.) Learning with Mobile Devices: Research and Development, London, pp. 21–25.
Learning and Skills Development Agency (2004)
10. Grudin, J.: Groupware and social dynamics: Eight challenges for developers. Communica-
tions of the ACM 37(1), 92–105 (1994)
11. Guerrero, L., Ochoa, S., Pino, J., Collazos, C.: Selecting Devices to Support Mobile Col-
laboration. Group Decision and Negotiation 15(3), 243–271 (2006)
12. Haag, S., Raja, M.K., Schkade, L.L.: Quality Function Deployment: Usage in Software
Development. Communications of the ACM 39(1), 41–49 (1996)
13. Hakkila, J., Mantyjarvi, J.: Collaboration in Context-Aware Mobile Phone Applications.
In: Proc. of HICSS 2005. IEEE Computer Society Press, Los Alamitos (2005)
14. Kortuem, G., Schneider, J., Preuitt, D., Thompson, T., Fickas, S., Segall, Z.: When peer-
to-peer comes face-to-face: collaborative peer-to-peer computing in mobile ad-hoc net-
works. In: Proc. of First Int. Conf. on Peer-to-Peer Computing, pp. 75–91 (2001)
15. Kristoffersen, S., Ljungberg, F.: Mobility: From stationary to mobile work. In: Braa, K.,
Sorensen, C., Dahlbom, B. (eds.), Planet Internet, Lund, Sweden, pp. 137–156 (2000)
16. Kusiak, A.: Engineering Design: Products, Processes, and Systems. Academic Press, San
Diego (1999)
17. Ljungberg, J., Holm, P.: Speech acts on trial. Scandinavian Journal of Information Sys-
tems 8(1), 29–52 (1996)
18. Luff, P., Hindmarsh, J., Heath, C.: Workplace studies: Recovering work practice and in-
forming system design. Cambridge University Press, Cambridge (2000)
19. Malladi, R., Agrawal, D.: Current and future applications of mobile and wireless networks.
Communications of the ACM 45(10), 144–146 (2002)
20. Martin, M.V., Kmenta, S., Ishii, K.: QFD and the Designer: Lessons from 200+ Houses of
Quality. In: Proc. of World Innovation and Strategy Conference (WISC 1998), Sydney,
Australia (1998)
21. Orlikowski, W.: Learning from notes: Organizational issues in groupware implementation.
In: Proceedings of the ACM Conference on Computer-Supported Cooperative Work,
CSCW 1992, pp. 362–369. ACM Press, New York (1992)
22. Roth, J., Claus Unger, C.: Using Handheld Devices in Synchronous Collaborative Scenar-
ios. Personal and Ubiquitous Computing 5(4), 243–252 (2001)
23. Sarker, S., Wells, J.: Understanding Mobile Handheld Device Use and Adoption. Commu-
nications of the ACM 46(12), 35–40 (2003)
24. Suchman, L.A.: Office Procedures as Practical Action: Models of Work and System De-
sign. ACM Transactions on Office Information Systems 1(4), 320–328 (1983)
25. Tschudin, C., Lundgren, H., Nordström, E.: Embedding MANETs in the Real World. In:
Conti, M., Giordano, S., Gregori, E., Olariu, S. (eds.) PWC 2003. LNCS, vol. 2775, pp.
578–589. Springer, Heidelberg (2003)
