Informatica 31 (2007) 71-104 93
Usable Collaborative Email Requirements Using Activity Theory
Lorna Uden and Aravind Kumaresan
Staffordshire University Faculty of Computing, Engineering and Technology
The Octagon Beaconside, Stafford, ST18 OAD. UK
E-mail: l.uden@staffs.ac.uk
Kimmo Salmenjoki
University of Vaasa, Department of Computer Science, Box 700, 65101 Vaasa, Finland
E-mail: ksa@uwasa.fi
Keywords: requirement analysis, email, interface design, context, activity theory
Received: November 24, 2006
Email is the most common collaborative tool in use today. Although originally designed as an asynchronous communication tool, it is being used increasingly for information management, coordination and collaboration tasks. For effective collaborative work, email must be designed that meets users' needs and their experience. The traditional approach to designing interfaces has been increasingly criticised because of the gaps between research results and practical design, especially concerning requirements. Requirements elicitation is a key to the success of the development of all email applications. Activity theory incorporates the notions of intentionality, history, mediation, motivation, understanding, culture and community into design. In particular, it provides a framework in which the critical issue of context can be taken into account. This paper describes the use of activity theory for the requirements analysis of a collaborative email system for a manufacturing company, XBC Ltd. Povzetek: Predstavljena je uporaba elektronske pošte za skupne aktivnosti.
1 Introduction
Among collaborative tools such as List servers, Newsgroups, Web Conferencing, Internet Relay Chat (IRC), Internet Phone, Internet Radio, and Desktop Video Conferencing, email is the most commonly used tool for electronic collaboration because of its asynchronous information sharing capability. Another reason is, virtually everyone who has ever touched a computer understands email. Email has become an important tool for communication in our modern life. Although email was originally designed as a tool for asynchronous communication, it has become more like a habitat than an application (Ducheneuaut & Bellotti 2001). Email today is being used for tasks such as information management, coordination and collaboration in organisations. It is also increasingly being used as a portal for access to online publications and information services, thus making email a personal information management tool for many purposes. Research from Ducheneuaut and Bellotti (2001) found that email is used for many information management features such as 'todos' (by marking up or resending oneself messages) and contact management (by sorting-by-name and filtering). According to Khoussainov & Kushmerick (2005), emails are still designed mainly to manipulate individual messages. Their features in automated email management are confined to filtering individual messages and simple message threading. Email has been increasingly used as a time management tool (Gwizdka 2001; Whittaker & Sidner 1996). In-boxes
are often used to keep messages referring to future events that cannot be dealt with on arrival. Messages are also used as reminders about non email tasks and events. Microsoft Outlook provides a number of features supporting various aspects of managing pending tasks (e.g. a to-do list, a calendar, general email flags, specialised remainder flags along with a type of action required). It also has temporal information organisation (e.g. Journal). Despite the provision of these features, very few users actually use them. The reason is being a lack of integration of email along with other software applications or media (Gwizdka 2004) leading to usability problems for users.
Usability is concerned with how easy it is to use and learn to use the system as well as how efficient and effective is the application. Users would only use the system if it is easy to use and allows them to carry out their tasks effectively and efficiently. The flow of tasks by the users in collaboration should be easily managed, shared and monitored. Another role of email is task management. However, current email systems are not effective in managing tasks (Whittaker & Sidner 1996). Central to the design of usable email applications that meet users' needs is requirements analysis. Effective and efficient requirements elicitation is absolutely essential if software systems are to meet the expectations of their customers and users, and are to be delivered on time and within budget (Al-Rawas & Easterbrook 1996).
72 Informatica 31 (2007) 71-83
L. Uden et al.
Goguen and Linde (1993) have provided a comprehensive survey of techniques for requirements elicitation, focusing on how these techniques can deal with the social aspects of this activity. They raise the important concept of social order in requirements elicitation and conclude that the requirements elicitation problem is fundamentally social and, thus, unsolvable if we use methods that are based entirely around individual cognition and ignore organisational requirements. Organisational requirements are those requirements that are captured when a system is being viewed in a social context rather than from a purely technical, administrative or procedural view of the functions to be performed. Sources of such requirements could be power structures, roles, obligations, responsibilities, control and autonomy issues, values and ethics (Avison & Wood-Harper 1990). These types of requirements are so much embedded in organisational structure and policies that often they cannot easily be directly observed or articulated.
Most established techniques, however, do not adequately address the critical organisational and 'softer', people-related issues of software systems. From the above discussion, it would seem that current models could not provide a theoretical basis for understanding 'regularly patterned' human activity (Probert 1999). In order to overcome the above mentioned problems, it is necessary to have a methodology and tools that can support the continuous evaluation of a statement of requirements as these evolve against a highly complex and dynamic problem situation. What is needed is to shift the focus from fixed and final requirements to those of a more dynamic nature. In particular, it is necessary to consider human information which, in social terms, does not have a physical reality and is not objective like physical information. Instead, it is based on individual, group or organisational needs. Such information informs action in organisations and is thus closely related to organisational activity and organisational form.
Organisational activity is itself a function of the social purposes of individuals, groups and organisations and is affected by issues outside the boundary of the organisation. Human information is subjected to change and is ongoing. One reconceptualisation of human information that allows for social organisation processes is Activity Theory (McGrath & Uden 2000). Activity Theory has increasingly been suggested by researchers in recent years as an ideal candidate for system design, and Human Computer Interaction (HCI) design ( Kuutti 1991; Nardi 1996). We believe that activity theory can be used as a framework for understanding the totality of human work and praxis and the deliberate processes changing this, i.e. a totality encompassing organisational development, design and use of computer artefacts (Bodker 1991).
Besides the requirements problems facing designers with the design of collaborative email, there is also the issue of interface of the application. Researchers in recent years have criticised the gap between research results and practical design in HCI. Bannon (1991) lists several limitations of the traditional cognitive psychology approach. Firstly, in the traditional approach, the human actors are simply passive elements in a system, not an autonomous agent that has the capacity to regulate and co-ordinate his or her behaviour. Secondly, the problem of using predetermined fixed requirements for product design. Instead of considering only a single individual, features of co-operation, communication, and coordination are often vital in the successful performance of tasks. Thirdly, restricted and artificial laboratory experiments have been the trend rather than work practices. Finally, there is a growing recognition that the actual use of a system is a long-term process that cannot be adequately understood by studying just the initial steps of usage. There is an emerging consensus among researchers that the cognitive approach to HCI may be limited. It does not provide an appropriate conceptual basis for studies of computer use in its social, organisational and authorial context, in relation to the goals, plans and values of the user or in the context of development.
Activity theory offers the possibility of seeing use and system design as a multitude of change cycles, where computer applications as well as other parts of the work activity are constantly reconstructed using more or less well-known materials, design tools and techniques, with a more or less clear understanding of the product. An explicit awareness of these cycles may change our way of doing design (Floyd 1987). Also in activity theory, conflicts can be acknowledged and taken seriously in design. This paper argues that activity theory provides an appropriate framework for elucidating requirements. It focuses on the interaction of human activity and consciousness within its relevant environmental context. In this paper, we present a case study involving the use of activity theory in requirements elicitation for the design of a collaborative email application for the XBC organisation. This paper begins with a brief review of activity theory and its implications for collaborative email design. This is followed by the description of the requirements analysis of the XBC collaborative email application using activity theory. The paper concludes with further research suggestions.
USABLE COLLABORATIVE EMAIL REQUIREMENTS.
Informática 31 (2007) 71-83 73
2 Activity theory
Activity theory has evolved through three generations of research (Engestrom 2001). The first generation of activity theory drew heavily on the work of Vygotsky's conception of mediation (Vygotsky 1978). The idea was crystallised in his famous triangular model in which the conditioned direct connection between stimulus (S) and responses (R) was transcended by a complex mediated act. The limitation of the first generation was that the unit of analysis remained individually focused. This was overcome by the second generation, based on Leont'ev's work (1978). Here Engestrom (1999a) advocates the study of tools or artefacts as integral and inseparable components of human functioning. He argues that the focus of the study of mediation should be on its relationship with the other components of an activity system. The third generation of activity theory takes joint activity or practice as the unit of analysis for activity theory rather than individual activity. Engestrom's analysis is concerned with the process of social transformation and incorporates the structure of the social world, with particular emphasis upon the conflictual nature of social practice. Instability and contradictions are the motive force of change and development, and the transitions and reorganisation within and between activity systems are parts of the evolution. The aim of the third generation of activity theory is to understand dialogues, multiple perspectives and networks of interacting activity systems.
2.1 A brief overview
Activity theory focuses on the interaction of human activity and consciousness within its relevant environmental context (Vygotsky 1978; Leont'ev 1981). The basic unit of analysis in activity theory is human activity. Human activities are driven by certain needs where people wish to achieve certain purposes. The need in our example is to have a usable collaborative email application. It is obvious that activity cannot exist as an isolated entity. The very concept of activity implies that there is an agent who acts (an individual or collective 'subject'). An activity is undertaken by a subject (individual or subgroup) using tools to achieve an object (objective) thus transforming objects into outcomes. The subject is the users of the email application. The object in our example is the undeveloped email application. The outcome is the finished email application. Relations between elements of an activity are not directed, but mediated.
The relationship between subject and object of activity is mediated by a tool. A tool can be anything used in the transformation process, including both material tools and tools for thinking. Transforming the object into an outcome requires various tools (e.g., computer, software, methods, idea, procedure, internet, paper, pen etc.). In our example, tools include: computer, programming tools, methods, procedures, technologies, Internet, paper, pen etc). The object is seen and manipulated not 'as
such', but within the limitations set by the tools (Kuutti 1996). Artefacts are created and transformed during the development of the activity itself and carry with them a particular culture - a historical remnant of that development.
The relationship between subject and the community is mediated by rules. Rules cover both implicit and explicit norms, conventions and social relations within a community as related to the transformation process of the object into an outcome. Rules in our case consist of organisational practices and policies, working hours, working regulation, etc). The relationship between object and community is mediated by the division of labour -how the activity is distributed among the members of the community, that is, the role each individual in the community plays in the activity, the power each wields and the tasks each is held responsible for. The roles in the email system consists of manager, secretary, users etc. Each of the mediating terms is historically formed and opens to further development (Kuutti 1996). The basic structure of an activity can be illustrated as in Figure 1.
Mediating artefact
of Labour
Figure 1: Basic structure of an activity.
In activity theory, the human mind emerges, exists and can only be understood within the context of human interaction with the world and this interaction, i.e., activity, is socially and culturally determined (Kaptelinin et al 1999).
According to Kuutti (1996) activities can be considered as having three hierarchical levels: activity, action and operation, which can be individual or cooperative. They can be considered as corresponding to motive, goal and conditions. An activity (global) may be achieved through a variety of actions. The same action may be used as contribution to different activities. Similarly, operators may contribute to a variety of actions. (See Figure 2). Kuutti uses a simple example of these levels to describe the activity (motive) of 'building a house' in which 'fixing the roof' and 'transporting bricks by truck' are at the action level and 'hammering' and 'changing gears when driving' are at the operation level. Every activity has an internal and external component with the subject and object existing as part of a dynamic and reciprocal relationship.
74 Informatica 31 (2007) 71-83
L. Uden et al.
Activity _ Motive
It It
Action - Goal
It It
Operation - Condition
Figure 2: The three levels of activity.
Activity has double nature, both an external and internal side. The subject and object of an activity are in a reciprocal relationship with each other. The subject transforms the object. Conversely, the properties of the object penetrate into the subject and transform him or her. This is called internalisation (Kuutti 1996). Activities are not isolated units; they are like nodes in crossing hierarchies and networks. They are influenced by other activities and other changes in their environment. According to Kuutti (1996), external activities change some elements of activity, causing imbalances between them. Contradictions are used to indicate a misfit between elements, between different activities or different development phases of the same activity. Contradictions manifest themselves as problems, ruptures, clashes and breakdown. Activity theory sees contradictions as a source of development. Activities are always in the process of working through some of these contradictions.
2.2 Advantages of activity theory for email design
There are several advantages of applying activity theory for collaborative email design. According to Bardram (1998a) these include:
•	Activity theory provides a philosophical framework for understanding collective human work activities as embedded within a social practice (e.g. an organisation), and mediated by artefacts, including computer-based artefacts.
•	By building on a dialectical notion between doing and developing work, activity theory provides a foundation for understanding both the dynamics of cooperative work changing over time and for understanding changes in work caused by employing new technology.
•	The same conceptual basis can be used by activity theory to reflect on the user interface, cooperative work activities and the design process.
3 Implications of activity theory for design
Basic principles of activity theory include object orientedness, internalisation/externalisation, mediation, contradiction and development (for detailed discussions see Engeström 1987; Kuutti 1996; Kaptelinin et al 1999). The most immediate benefit of activity theory is in providing a triangular template for describing these relationships and looking for points of tension as new goals, tools or organizational changes create stress with the current roles, rules and artefacts. Some of the p rinciples of activity theory that have important implications for collaborative email design are:
3.1	Design is evolving
The design of a collaborative email system requires an understanding of psychological, social and cultural phenomena. It has to comprehend development as a basic feature. The design approach of the email application is concerned with making artefacts for human use. Design is a complex set of technical and social components and relationships that together constitute an activity system (Engeström 1987). Design in activity theory is not a conscious goal or aim. It is not even a single object, but an ensemble of elusive and constantly changing objects, both material and ideal (Zappen & Harrison 2005).
3.2	Design as mediated activity
Design is a heteropraxial activity involving groups of people with different backgrounds and motivation in the process. During design, users and designers constitute a reified, implicit common understanding of the prototype. In activity theory, all human endeavours are mediated by socially constituted artefacts (Engeström 1987; Leont'ev 1978). This means that email design is mediated by artefacts. The designer (subject) shapes the design object by means of some design artefacts. The design object is the artefact produced in the design, the outcome the design activity is directed to. Design activity is mediated by design artefacts such as programming languages, methodologies, theories, technologies, etc. The prototype in collaborative design serves two purposes. It is the continuously moving object of the design activity and is also a design artefact mediating the creation of insights and vision of the new system (Bertelsen 2000).
3.3	Design artefacts mediate across
heterogenous activities
In activity theory heterogeneous activities of the different users contribute to design by tying together through their joint use of artefacts and their joint focus on the same object. Design artefacts tie different communities of practice together, maintaining meaning across groups, but by making sense in different ways to different groups. They not only take different shapes and serve different purposes to different groups; they also take different functions with one group across time, during use and design.
USABLE COLLABORATIVE EMAIL REQUIREMENTS.
Informática 31 (2007) 71-83 77
3.4	The hierarchy of activity structures must be understood
Activity should be the unit of analysis in design of email application. This is a conceptual level about the level at which most business analysis takes place, i.e. at the level of action, which is undertaken towards specific goals (Hasan 2000). Typically in most computer systems, actions which are routine and standardised can become automatic when driven to a lower level of operation under certain conditions.
Email use may be the core business activity at the top level. In activity theory, the email application is not an end in itself, but, more often; it is a support for other business activities at all three levels in the activity theory structure. Email management is an explicit adjunct to core business activity, with value adding projects such as customer relations management is at the second level. These systems are viewed by activity theory as actions towards specific goals, but not as core business activities themselves. The third level in the activity theory hierarchy is that of operations where email systems are seen as primary tools automating basic organisational management processes.
3.5	Analyse collective activity through context
One of the main limitations of the traditional approach to designing interfaces based on the cognitive science approach may be due to their omission of context. This notion of context needs to be conceptualised. Kuutti and Juustila (1998) stress the importance of focusing on work activities as the context of information systems, saying, "We are never developing information systems, but the whole of the work activity where it will be utilised." How do we conceptualise work activities? The highest level of contextualisation is usually the task level. Task analysis identifies the outer behaviour of work activities and is a popular basis for defining the uses to which a computer interface will be put. This analysis may have an important function for describing job requirements. However, the distinction between human and computer tasks such as analysis is rather limited in relation to identifying the psychological processes in work activities. Focusing on observed behaviour does not say much about the inner structure of activity, as the same observed behaviour may correspond to different motives and goals of the individual. Operating a computer can be a playing, learning or working activity, thus having a different personal sense for subjects. We believe that studying cognition only within its task context does not solve the problem of contextualisation. Human procedures are not determined by the task, but determination is based on special characteristics of the case. For task analysis to have any real significance in design, it needs to be embedded within the work activity. It is impossible to make a general classification of activities, actions or operations because activities are in a constant state of development. The identification is independent of the activity of the individual.
It is important in a collaborative email system to use a collective activity system as the unit of analysis, giving context and meaning to seemingly random individual events. In activity theory, activity and context cannot be separated. The activity system itself is the context. What takes place in an activity system composed of object, actions and operations, is the context. Context is constituted through the enactment of an activity involving person (subject) and artefacts. Context is therefore the activity system and the activity system is connected to other activity systems. People consciously and deliberately generate contexts (activities) in part through their own objects. Context cannot be reduced to an enumeration of people and artefacts. In activity theory, context is not persistent and fixed information. Continuous construction is going on between the components of an activity system. Humans not only use tools, they also continuously renew and develop them either consciously or unconsciously. They not only use rules, but also transform them. It is generally acknowledged that understanding the social and organisational context is critical to the success of systems. The usability of a product depends on its context of use. Products should be designed for a specific context (Maguire 2001). The role of context of use within usability is required by the International Standard ISO 13407 (ISO 1999).
3.6	Historically analyse the activity and its components
An activity system does not exist in a vacuum; it interacts with a network of other activity systems. For example, a project team (activity system) receives rules and instruments from business activity, its members are trained by educational activity and it produces outcomes that are being used for activities in other organizational settings. An activity is also situated in time besides in a network of influencing activity systems. It is important to investigate its temporal interconnectedness (Pettigrew 1990). History is the basis of classification. This means that the activity system and its components shall be understood historically. An activity is not a homogeneous entity. It is comprised of a variety of disparate elements, voices and viewpoints (Engestrom 1990). The multiplicity can be understood in terms of historical layers. Activities are not static or rigid, they are constantly evolving. To understand a phenomenon means to know how it is developed into its existing form (Kaptelinin 1996). This applies to all the elements of an activity. The current relationship between subject and object includes a condensation of the historical development of that relationship (Kuutti 1996).
3.7	Contradictions in activity systems
Activity systems are interrelated, providing each other with input and serving as instruments for each other. Contradictions are inevitable, occurring within and between activity systems; they lead to transformation of the processes. Activity is constantly developing as a
76 Informática 31 (2007) 71-83
L. Uden et al.
result of contradictions and instability, and due to the construction of new needs. Activity theory understands human beings as dialectically recreating their own environment. Subjects are not merely choosing from possibilities in the environment, but actively creating the environment through activity.
According to Engeström (1987), any activity system has four levels of contradictions that must be attended to in analysis of a working situation. Level 1 is the primary contradiction. It is the contradiction found within a single node of an activity. This contradiction emerges from tension between use value and exchange value. It permeates every single corner of the triangle and is the basic source of instability and development (Engeström 1987). Primary contradiction can be understood in terms of breakdowns between actions or sets of actions that realises the activity. These actions are poly-motivated. This means that the same action can be executed by different people for different reasons or by the same person as part of two separate activities. This polymotivation may be at the root of subsequent contradictions.
Secondary contradictions are those that occur between the constituent nodes. For example, between the skills of the subject and the tool he/she is using, or between rules and tools. Tertiary contradiction arises between an existing activity and what is described as a more advanced form of that activity. This may be found when an activity is remodelled to take account of new motives or ways of working. Quaternary contradictions are contradictions between the central activity and the neighbouring activities, e.g. instrument producing, subject-producing and rule producing activities. Contradictions are present in every collective activity. They indicate emergent opportunities for the activity development. Contradictions are not weakness, but signs of richness, and of mobility and the capacity of an organisation to develop rather than function in a fixed and static mode. They are not points of failure or deficits within the activity system in which they occur. They reveal the growing edge of the activity system - the place where growth buds are able to expand and expansive development takes place (Foot 2001), and are starting places, not ending points. Contradictions are not problems to be fixed, and they cannot quickly transcend through technical solutions. Engeström (2001) defines contradictions as historically accumulating structural tensions within and between activity systems. It is important to identify all the different kinds of contradictions in the email activity. In order to analyse an activity system's development, it is important to identify contradictions. By identifying the tensions and interactions between the elements of an activity system, it is possible to reconstruct the system in its concrete diversity and richness, and therefore explain and foresee its development (Engeström 1999b).
4 Collaborative email design
In XBC, the management of email is important for the company. Microsoft Outlook Exchange is currently being
used by XBC. A shared folder is organised so that documents can be accessed by all users that need them. It is currently impossible to track who has updated these documents, since documents updated by users are not made known to the other users. The secretary, Rita, needs to send large documents containing product pictures to multiple clients. Rita often uses the sent folder to find product images to send to the different customers. This means that she cannot delete the sent emails because she needs to keep track of her sending activities. Consequently she uses up all her allocated 20Mb quota. Because Rita has to send multiple file attachments, this prevents her from sending out files more than 5Mb to customers. Rita also uses the email system to maintain her task list, scheduling, study notes, evens management, etc.
John is the manager of the organisation. He likes thread-based email and uses it to track related information. Instead of using Microsoft Outlook Exchange, he uses G-mail, a web-based email product from Google to implement the conversation-based email facility. This results in incompatibility between his system and Rita's, causing many problems, especially integration of information and management of tasks. A collaborative email application was proposed as the solution to overcome the above problems using semantic web. Due to the limited size of this paper, it only concentrates on the requirements analysis of the collaborative email application. The semantic aspects of the development will be discussed in a further paper. The design of a collaborative email application is basically a socio-cultural phenomenon. It cannot be based solely on the systematic application of quantitative software measures, or any other methods from ideal natural science. The design of a collaborative email application has to include an understanding of psychological, social and cultural phenomena. It has to comprehend development as a basic feature. The design approach of collaborative email application is concerned with making artefacts for human use. Collaborative email application development research is based on a multitude of research methods and strategies such as intervention, field studies, theorising and controlled experiments. It is complicated by many factors, making it necessary for the application of a broad spectrum of modes of enquiry. Based on the above activity theory framework, the following questions that are relevant for the design of collaborative email application include:
•	What are the activities, goals and sub goals to be supported by system?
•	What social context elements are to be considered?
•	How can we model the collaborative email users?
According to activity theory, the email application is considered as artefact that mediates activities that are related to, or executed during, knowledge management in an organisation. In activity theory, artefacts and activities are in a reciprocal relation. New artefacts cause new or changed goals and activities.
USABLE COLLABORATIVE EMAIL REQUIREMENTS.
Informática 31 (2007) 71-83 79
The basic idea of Activity Theory is that an individual's relation to the surrounding world is not immediate, but is always mediated by culturally created artefacts. Individuals use both conceptual and practical tools to plan and realise their actions. Individual's actions are therefore always situated in a culturally-determined context and are impossible to understand outside of that context. We believe that only having a better understanding of human activity will allow us to conceive and design more flexible systems, responsive to human needs and use.
We can regard the development of collaborative email application an assembly of human beings and artefacts being changed or reconstructed to satisfy some motivation. It is therefore important to understand the individual components involved in order to understand the whole process.
5 Requirements analysis for
collaborative email design using activity theory
Activity theory helps structure analysis, but does not prescribe what to look for. Activity theory does not offer ready-made technologies and procedures for research (Engestrom 1993). Its conceptual tools must be concretised according to the specific nature of the object under study.
Designing email based upon activity requires in-depth understanding of tasks associated with collaboration. The best way to identify these task lists is to observe observing the way people work with the email system. The shared tasks users perform are also affected by factors such as their environment, experiences and culture etc., so addressing these issues is very important. According to Bellotti and others (2003), a task management system in email should have the properties of differentiating important or outstanding items, indication for updated information, keeping track of threads of activity and discussions, methods to manage deadlines and reminders, embedding task features with in email and gathering related items. Based on her work, it is important the following should be considered when designing a task-based email system.
1.	There should be easy way to differentiate important and outstanding items.
2.	Days left indicator should be properly shown.
3.	Use of conversation thread-based system
4.	Mentioning the deadline and remainders.
5.	Documents or files should be correlated accordingly with the email message.
6.	Task-generated to-do list.
5.1	Clarify the purpose of the activity
system
The purpose of this step is twofold: (a) to understand the context within which activities occur and (b) to reach a thorough understanding of the motivations for the activity being modelled, and any interpretations of perceived contradictions. Engestrom (1987) emphasises clarification of the motives and goals of the activity system. What are stakeholders' goals and motives? What are their expectations about the outcome? We consider this stage to be the most important step of the process. Several techniques can be used at this initial stage, including the analysis of formal and informal documentation, user observations and interviewing. Given that the application developed must meet users' needs, a thorough understanding of the intentional dynamics of the activity system is critical. Activities always take place with a specific context in a certain situation. Activity context can be modelled using Engestrom's Triangle (Engestrom 1987) as a network of different elements that influence each other. It is important to have a clear understanding of the goals of the email application to be built. The goals will help to define the object of the problem that users have. The motives will help to determine what perspectives to represent in the design. For our email application, we would examine users' problems for different uses, what were their problems, their motives and expectations? It is necessary to understand relevant context(s) within which activities occur. From this we can generate a list of problems that users typically have to deal with. We also have to understand the subject, his or her motivations and interpretations of perceived contradictions in the system. This will enable us to generate a list of subject-driven motives and goals for each of the groups involved that might derive the activity.
5.2	Analyse the activity system
This step involves defining, in depth, the components of the given activity, namely, the subject, object, community, rules and division of labour. This study began by interpreting the various components of the activity triangle (Figure 1.) in terms of the situation being examined. The activity system for XBC is shown in Figure 3. It is important to know the perception of the users as their roles in relationship to the goals of the system. Central to the analysis is the identification of the object of the system. The object here is to develop the collaborative email application. Having a clear idea of the object will to fulfil the goals or intentions of the system. The community of practice in XBC comprises the activity system. The community and its rules determine the problem context, and the division of labour determines with whom the user must interact with when working at XBC.
80 Informatica 31 (2007) 51-59
K. Zielinski et al.
Tools
(Operating systems, Microsoft Exchange, procedures, documents, customer orders, etc.) Software
Subject
(Users at XBC)
Object
Collaborative email application
Rules
(Company regulations, Tax regulations, VAT, working hours, etc)
Community
(The people working at XBC)
Division of Labour
(Chairman, manager, supervisor, secretary, workers, etc.)
Figure 3: The activity system of XBC.
5.3	Produce an activity system of the application
The above information gathered enables us to acquire basic knowledge about the situation. This is necessary for the purposes of mapping Engestrom's model (Figure 1) onto the situation in order to produce an activity system of that situation. This approach helps us to identify areas to be focused on during the investigation and also in deciding what resources would be necessary during the analysis.
5.4	Analyse the activity structure
It is necessary at this stage to analyse the activity structure (all of the activities that engage the subject) that defines the purpose of the activity system. The hierarchy of activity, actions and operations describe the activity structure. This is not unlike traditional task analysis. when defining and identifying activity structures, it is useful to have an understanding of the intentionality of the action or operation of the users. Why are people doing this? The outcome of this step will consist of a description of the activities, actions, and operations that are required to solve the email problem for XBC. To analyse the activity structure requires that we define the activity itself. It is important to identify the activities in which the subjects participate and how the work (actions and operations) have been transformed over time. This means how the work is actually done in practice and what historical phases have there been on the work activities. This is then followed by the decomposition of activities into components actions and operations. For each activity, observe and analyse the actions that are performed and by whom. Conversely, for each action, observe and analyse the operations that the subjects performed.
5.5	Analyse tools and mediators
Components of activity systems (subject, community, object) do not act on each other directly. Instead, their interactions are mediated by tools that provide direct and indirect communication between the objects. Mediators can be instruments, signs, procedures, machines, methods, languages, formalism and laws. Important questions to ask are: What tools are used in the activity? How available are the tools to the users? How have the tools changed over time? Mediators also include formal rules or models. Rules mediate the relationship between the subject and the community or communities in which they participate. It is necessary for us to know what formal or informal rules, laws, or assumptions guide the activities in which people engage? Besides rule mediation there is also role mediation. Who traditionally has assumed the various roles? How does that affect work group?
5.6	Decompose the situation's activity system
The activity system produced so far can be very complex because it incorporates the various sub-activities that together make up the main activity system being analysed. An activity notation can be used to aid the process of breaking down the situation's activity triangle system into smaller manageable units or sub-activity triangles (Mwanza, 2001). Figure 4 shows the activity notation. Each combination within the activity notation should consist of:
•	An 'actor' - represented by the subject or community component of the triangle model.
•	A 'mediator' - represented by the tools, rules or division of labour component of the triangle.
•	The 'object' on which activity is focused.
USABLE COLLABORATIVE EMAIL REQUIREMENTS.
Informática 31 (2007) 71-83 81
Each combination within the activity notation represents a complete sub-activity triangle from the main activity system. For example, it is possible to identify the subject-rules-object sub-activity triangle representation whose mediated relationship could be arranged in terms of the application of rules as shown in Figure 2.
5.7 Generate questions for each activity notation
Questions that are specific to a particular combination within the activity notation and also representing a sub-activity triangle are then generated. The questions generated can be general or specific to a particular situation. Questions that are specific to a particular combination within the activity notation and also representing a sub-activity triangle are then generated.
5.8 Analyse the context
The traditional approach to analysis ignores real life contexts within which activities take place. Activity theory argues that activity itself is both defined by and defines context. Context is both internal to people (involving particular goals or objects), and also external (involving artefacts, other people and settings). Analysing context is essential for defining the larger activity systems within which activity occurs (subject, community, and object) and the dynamics that exist between the subject and the mediators. The designer is seeking information in order to describe "how things get done in this context". Why? Because different contexts impose distinctly different practices.
There are two types of contexts that need to be identified: internal or subject-driven contextual bounds and external or community driven contextual bounds. (Jonassen & Rohrer-Murphy 1999), Questions to be asked are:
•	What are the beliefs, assumptions, models and methods that are commonly held by the users?
•	What tools do users use in doing their tasks : How well do they use them?
•	What is the structure of the social interactions surrounding the activity?
•	What limitations are placed on the activity by the company or outside agencies?
These questions can also be general or specific to a
particular situation.
The six general research questions:
i.	What Tools do the Subjects use to achieve their Objective and how?
ii.	What Rules affect the way the Subjects achieve the Objective and how?
iii.	How does the Division of Labour influence the way the Subjects satisfy their Objective?
iv.	How do the Tools in use affect the way the Community achieves the Objective?
v.	What Rules affect the way the Community satisfies their Objective and how?
vi.	How does the Division of Labour affect the way the Community achieves the Objective?
Examples of specific research questions for XBC:
How does the email (tools) support collaborative task
management (object) amongst teams (subject) ?
How do rules of XBC affect collaborative task
management (object) amongst individuals and teams
(subject)?
How do roles of people at XBC (division of labour) affect the way collaborative task management (object) is achieved amongst the teams (subject)? How does the use of outlook (tools) as performance indicators affect the way XBC (community) support task management (object)?
How does XBC's (community) use of email influence the way the organisation manage their tasks (object)?
•	How are the tasks organised among members who are working towards the object?
•	How are tasks divided or shared among the participants?
•	What formal or informal rules guide the activities in which people engage?
5.9 Identify the different types of contradictions
Contradictions can be identified by disturbances in the free running of an activity (Engestrom 1999b). In order to identify contradictions, it is necessary to understand the dynamics of the current work and make visible its nuances and identify the disturbances therein. Contradictions are present in every collective activity. They indicate emergent opportunities for the activity development. Contradictions demand creative solutions. The contradictions identified for the S SIL email application are shown in Figure 5. Contradictions are important aspects of an activity because they are used as sources of development (Kuutti 1996). They trigger reflection, thereby helping with the improvement of the activity. Several levels of contradictions were identified at XBC.
Actors (Doers)		Mediator		Objective (purpose)
Subjects		Tools	~	Object
Subjects		Rules	~	Object
Subjects		Division of labour	~	Object
Community		Tools	~	Object
Community		Rules	~	Object
Community		Division of labour		Object
Figure 4: Activity Notations.
76 Informática 31 (2007) 71-83
L. Uden et al.
More Advanced Email
4. Secondary Contradiction
2. Primary Contradiction
Customer
Product
Figure 5: Contradictions of the XBC system
5.10	Potential primary contradictions within the email activity
1.	At the object node, there is tension between the requirements of the users. Rita and John have different objectives.
2.	At the subject node, the skills and experience of the users vary as a function of their history, experience and training.
3.	At the tool node, there are conflicts of interest between the choice of technologies used for the development of the collaborative email system, e.g. traditional approach versus semantic web technologies.
5.11	Potential secondary contradictions within the email activity
4.	There is tension between the subject node and the tool node. The subject (the developer) may not have the necessary semantic web skills to produce the collaborative email application.
5.	There is a conflict between the choice of tool and the rule of the organisation. Semantic web technologies may cost more than the limited budget the company is able to
pay.
5.12	Potential tertiary contradictions within the email activity
6.	There is tertiary contradiction between the existing activity and the new collaborative email activity because the subjects would have to learn the new system.
5.13	Potential quaternary contradictions within the email activity
7.	There is a fundamental contradiction between the effective mail management and supporting staff at the customer department.
8.	There is a contradiction between the aim of the product development and the interests of the staff using the email system.
Semantic web offers open-standards that can enable vendor-neutral solutions, with a useful flexibility (allowing structured and semi-structured data, formal and informal descriptions, and an open and extensible architecture). RDF can be used as a common interchange format for catalogue metadata and shared vocabularies that can be used by all libraries and search engines across the web.
The above identified contradictions were resolved before we designed the email application using semantic web. A screen shot of the Semantic email database schema is shown in Figure 6 on next page.
USABLE COLLABORATIVE EMAIL REQUIREMENTS.
Informática 31 (2007) 71-83 83
There are benefits for using semantic web for the design of our collaborative email application. Semantic Web enables automated information access and use based on machine-processable semantics of data. The application
was evaluated by the different users of XBC. They found it very useful because it enables them to take care of task management as well as normal email activities.
Figure 6: Semantic email database schema
6 Conclusion
The development of effective email applications is a socio-cultural activity. A technical solution is not adequate to address the complexity of the system. To design collaborative email systems without consideration of the different needs of the users' social processes is a recipe for disaster. Email systems are inevitably groupware systems that connect people to people either directly or indirectly through sharing knowledge. To support effective collaborative email systems, it is necessary to understand the interrelationship of cultural, technical and organisational elements. While this is beginning to change, there remains a substantial research challenge in developing activity theory and tools to apply in the design of applications to support work such as such email.
Software systems are not built in a vacuum, but within organisational environments where outcomes are heavily influenced by a myriad of internal and external social-technical factors. Softer issues should be given the same
weight in software development and implementation processes as the more technical features. The research presented here is underpinned by these concerns. Activity theory principles are ideal for making visible the structure and dynamics of work situations, especially with respect to contradictions. Contradictions provide a systematic way of modelling and reasoning about breakdowns and opportunities for email design. The strength of the activity theoretical perspective is the recognition that work systems are inherently dynamic. However, further work is still needed for activity theory to be used as a robust requirement or design method. More research would be needed. The authors are currently working on making the principles of activity theory concrete so that anyone without activity theory knowledge can use the proposed guidelines for requirements analysis.
6.1 Acknowledgement
We acknowledge the collaboration with the XBC Ltd company in providing the business case for this study.
76 Informática 31 (2007) 71-83
L. Uden et al.
7 References
[1]	Al-Rawas, A.. & Easterbrook, S. (1996). Communications Problems in Requirements Engineering: A Field Study. Proceedings of he First Westminster Conference on Professional Awareness in Software Engineering (The Royal Society, London, 1-2 February.
[2]	Avison, D.E. and Wood-Harper, T. Multiview: An Exploration in Information System Development. Alfred Walter, Oxford, 1990.
[3]	Bannon, L. (1991). From Human Factors to Human Actors: the role of psychology and human-computer interaction studies in system design. In J. Greenbaum & H.M Kyng (eds.), Design at Work: Cooperative Design of Computer Systems. Hillsdale, NJ: Lawrence Erlbaum Associates.
[4]	Bannon, L. & Bedker, S. (1991). Beyond the Interface: encountering artefacts in use. In J.M. Carroll (ed.), Designing Interaction: Psychology at the human-computer interface (pp 74-102), Cambridge: Cambridge University Press.
[5]	Bellotti, V., Ducheneuaut, N., Howard, S. & Smith, I. (2003). Taking Email to task: the design and evaluation of a task management centred email tool. CHI 2003, April 5-10, 2003, Fort Lauderdale, FL: USA. Vol. 5(1), pp 345-352.
[6]	Bertelsen, O.W. (1998). Elements of a Theory of Design Artefacts: a contribution to critical system development research. PhD Thesis. Aachus, Jan. 1998.
[7]	Bedker, S. (1991): Activity theory as a challenge to systems design. In: Nissen H-E, Klein HK and Hirscheim R (eds.): Information Systems Research: Contemporary Approaches and Emergent Traditions, Amsterdam: Elsevier, pp. 551-564.
[8]	Ducheneuaut, N. & Bellotti, V. (2001). Email as Habit: An exploration of Embedded Personal Information Management. Interactions, 8(5) ACM Press, pp30-38.
[9]	Engeström, Y. (1987). Learning by Expanding. Helsinki: Orienta-Konsultit OY.
[10]	Engeström, Y. (1990). Developmental work: Research as activity theory in practice: Analysing the work of general practitioners. In Y. Engeström, Learning, Working and imaging: Twelve studies in activity theory, Orienta-Konsultit OY, Helsinki.
[11]	Engeström, Y. (1993). Developmental studies of work as a testbed of activity theory. In C. Chaiklin & J. Lane (eds.), Understanding Practice: perspectives on activity and context. Cambridge: Cambridge University Press, pp 64-103.
[12]	Engeström, Y. (1999a). Innovative learning in work teams: analysing knowledge creation in practice. In Y. Engeström, R. Miettinen, & R-L Punamaki (eds.), Perspectives on Activity Theory: Learning in Doing: Social, Cognitive and computational perspectives. Cambridge University Press, UK: pp 377-404.
[13]	Engeström, Y. (1999b). Expansive Visibilization of Work: An Activity-Theoretical Perspective.
Computer Supported Cooperative Work. Journal of Collaborative Computing 9(1-2), pp 63-93.
[14]	Engeström, Y. (2001). Expansive Learning at work: towards an activity theoretical reconceptualisation. Journal of Education and Work, Vol 14 no 1.
[15]	Floyd, C. (1987). Outline of a paradigm change in software engineering. In G. Bjerknes, P. Ehn, & M. Kyng (Eds.), Computers and democracy - A Scandinavian challenge (pp. 191-212). Aldershot, UK: Avebury.
[16]	Foot, K.A. (2001). Cultural-Historical Activity Theory as Practical theory: Illuminating the development of a Conflict Monitoring Network. Communication Theory Vol. 11, Feb 2001, pp 56 -83.
[17]	Goguen, J.A. and Linde, C. (1993). Techniques for requirements elicitation. Proceedings of the First IEEE International Symposium on Requirements Engineering (RE'93), 152-164.
[18]	Gwizdka, J. (2001) Supporting Prospective Information in Email. Proceedings of CHI'2001, ACM Press, pp 135-136.
[19]	Hargreaves, D. (1996). Teaching as a Research-Based Profession. London: TTA.
[20]	Hasan, H. (2000). The mediating role of technology in making sense of information in a knowledge intensive industry, Knowledge and process management, 6/2, p. 72-82.
[21]	ISO (1999). ISO 13407: Human-centred design processes for interactive systems. Geneva: International Standards Organisation. Also available from the British Standards Institute, London.
[22]	Jonassen, D.H. and Rohrer-Murphy, L. (1999). Activity theory as a framework for designing constructivist learning environments. Educational Technology Research and Development, 47(1), 6279.
[23]	Kaptelinin, V., Nardi, B. A., Macaulay, C., 1999. The Activity Checklist: A tool for representing the "space" of context. ACM Interactions, 6 (4), 27-39.
[24]	Kaptelinin, V., (1996). Activity Theory: Implications for Human-Computer Interaction, In Context and Consciousness: Activity Theory and Human-Computer Interaction. B. Nardi, (ed.), Cambridge, Mass.: MIT Press.
[25]	Khoussainov, R. & Kushmerick, N. (2005). Email Task Management: an iterative relational learning approach., http://www.ceas.cc/papers-2005/142.pdf, accessed on 20.11.2006.
[26]	Kuutti, K. (1991). Activity Theory and its applications to information systems research and development. In H.E. Nissen, H.K. Klein & Hirschheim (eds.), Contemporary Approaches and Emergent Traditions. Elsevier Science Publications. North-Holland.
[27]	Kuutti, K. (1996). Activity Theory as a Potential Framework for Human Computer Interaction Research. In B.A. Nardi (ed.), Context and Consciousness: Activity Theory and HumanComputer Interaction. MIT Press, Cambridge, MA.
USABLE COLLABORATIVE EMAIL REQUIREMENTS.
Informática 31 (2007) 71-83 85
[28]	Kuutti, K. & Vikkunen, J. (1995). Organisational Memory and Learning Network Organisation: the case of Finnish Labour Protection Inspectors. Proceedings of HICSS 28.
[29]	Kuutti, K. & Juustila, T.M. (1998). Information System Support for 'Loose' Co-ordination in a Network Organisation: an Activity Theory perspective. In H. Hasan, E. Gould & P. Hyland (eds.), Information Systems and Activity Theory: tools in context. University of Wollongong Press.
[30]	Leont'iev, A.N. (1978). Problems of the Development of the Mind. Moscow, Progress.
[31]	Leont'ev, A.N. (1981). Activity, Consciousness and Personality. Englewood Cliffs, Prentice-Hall.
[32]	McGrath, M. & Uden, L. (2000). Modelling Softer Aspects of the Software Development Process: An Activity Theory based approach Thirty-third Hawaii International Conference on System Sciences. (HICSS-33) Wailea, Maui, Hawaii, USA - Software Process Improvement. IEEE Computer Society Press. January 2000.
[33]	Maguire, M. (2001). Context of Use within usability activities, Int. J. Human-Computer Studies (2001) 55, 453}483 doi: 10.1006/ijhc.2001.0486, Available online at http://www.idealibrary.com
[34]	Mwanza, D. (2001). Where theory meets practice: A case for an Activity Theory based methodology to guide computer system design. Proceedings of INTERACT 2001: Eighth IFIP TRC13 conference on Human-computer interaction, Tokyo, Japan, July 9-13, 2001.
[35]	Nardi, B.A. (ed.), (1996). Context and consciousness: Activity Theory and humancomputer Interaction. Cambridge, MA: MIT press.
[36]	Pettigrew, A. M. (1990). Longitudinal field research on change: theory and practice. Organization Science 1(3): 267-292.
[37]	Probert, S.K. (1999). Requirements engineering, soft system methodology and workforce empowerment. Requirements Engineering, 4, Springer-Verlag, London, 85-91.
[38]	Vygotsky, L.S. (1978). Mind in Society. Harvard University Press, Cambridge, MA.
[39]	Whittaker, S., & Sidner, C. (1996). Email overload: exploring personal information management of email. In Proceedings of CHI'96, Conference on Human Factors in Computing Systems, ACM, NY, 276-283.
[40]	Zappen J.P. & Harrison, M (2005). Intention and Motive in Information-System Design: towards a theory and method for assessing users' needs. P. van den Basselaar & S. Koizumi (eds.), Digital Cities 2003, LNCS 3081 pp 354-368. SpringerVerlag, Berlin, Heidelberg, 2005.