Integrating Activity Theory and Organizational Modeling for Context of Use Analysis Genésio Cruz Neto Faculdade Integrada do Recife, Recife PE, Brasil, 50720-635 55 081 21018300
[email protected]
Alex Sandro Gomes Universidade Federal de Pernambuco, CIn, Recife PE , Brazil, 50732-970 55 81 21268430
[email protected]
Jaelson Castro Centro de Estudos e Sistemas Avançados do Recife, Recife PE, Brazil, 50030-390 55 81 21268430
[email protected]
Suzana Sampaio Centro de Estudos e Sistemas Avançados do Recife, Recife PE, Brazil, 50030-390 55 81 34254700
[email protected]
ABSTRACT
Activity Theory is a theoretical-based context analysis technique that anchors the ethnographer descriptive work, calling his attention to the individual and social elements of human activities. For more than a decade, it has been a recognized framework for enhancing computer design practices, however there are still no methods for integrating context analysis based on Activity Theory with traditional system modeling techniques. In this paper we present a system design process that integrates ethnographic analysis based on Activity Theory with the i* organizational modeling technique. The approach uses human-practices analysis as the social root for system requirements derivation. Keywords
Context of Use Analysis, Activity Theory, Organizational Modeling, Requirement Engineering INTRODUCTION
It is widely recognized that understanding the social and organizational context is critical to the success of many systems today. The usability of a product depends on its context of use and products should be designed for specific contexts [13]. The international standard ISO 13407 [9] also recognizes the role of context of use within usability. It defines the process of understanding and specifying the context of use as one of the main stages within humancentred design process [14]. The i* framework [25], by explicitly modeling and analyzing strategic relationships among multiple actors,
incorporates social context specifications into a systems analysis and design framework. Actors depend on each other for goals to be achieved, tasks to be performed, and resources to be furnished. A notion of soft goal is used to deal systematically with quality attributes, or non-functional requirements. Dependencies among actors give rise to opportunities as well as vulnerabilities. Networks of dependencies are analyzed using a qualitative reasoning procedure. During systems design, actors explore alternative configurations of dependencies to assess their strategic positioning in a multi-agent, social context. Unfortunately, stakeholders do not know how to describe their own social and organizational problems, neither define many tasks they regularly do [8]. Ethnography [12, 24] is an elicitation technique that helps the requirements engineer to approach those problems by observing the user daily activities as it is actually performed. By having a deep understanding of the social context, a requirement engineer can have insights on how to elaborate software systems that better support the user daily activities. Activity Theory [11, 18] provides a theoretical structure that helps the ethnographer to select the observation focus, gives fresh insights about the phenomena observed, and also describes the social activities in a structured way. These contribute to transform an apparently intuitive and non-practical ethnographical process in a work guided by objective reflections [12]. Indeed, for more than a decade, Activity Theory has been a recognized framework for enhancing design practices in Computer Supported Collaborative Work (CSCW) and related fields of Human-Computer Interaction (HCI) [1, 18, 19]. However, in most of the applications it has been deployed as an analytical framework, not oriented towards system modeling [4, 10, 17, 23].
In this paper we advocate that the use of i* organizational models is a step forward in constructing software systems more adapted to their context of use. However, we acknowledge that its application still brings open questions for the requirements engineer: •
Where do the organizational elements (used in the early requirement model) come from?
•
What are the theoretical social background used for structuring the organizational elements?
In order to answer these issues we describe a process that integrates ethnography analysis oriented by Activity Theory constructs with the i* technique based on organizational modeling [25]. It relies on the use of human practices analysis as a guide for system design. This paper extends and integrates previous preliminary works [5, 6]. Sections 2 and 3 describe, respectively, the Activity Theory framework and the i* organizational modeling technique. The design process that integrates ethnography analysis based on Activity Theory with i* organizational modeling is introduced in section 4. In section 5, we analyse some related works. At end, in section 6, some conclusions and future works are described
Activities can be also defined in different levels: activity consists of actions or chains of actions. Participating in an activity is performing conscious actions that have an immediate and defined goal, or objective. Actions are linked to each other in one activity by the same overall motivation of transforming the activity object into an outcome. The activity motivation is the characteristic that differentiates and relates activities and actions.
Figure 1. The Engeström systemic model. Actions can be broken in lower level sub-actions, which, in turn, have sub-goals. Lower level actions carried automatically are operations. Actions turn into operations when they become routine and unconscious. Operations are well-defined habitual routines used as answers to conditions. The activity levels, and their dynamics, are showed graphically by Figure 2.
ACTIVITY THEORY
Activity Theory (AT) [11, 18] is a broad theoretical framework for describing the structure, development, and social context of human activities. It has roots in the historical-cultural soviet psychology founded by Lev Vygostsky, A. N. Leont´ev and A. N. Luria. According to this theory, an activity is the way a subject (either an individual or a group) moves towards an object with the purpose of attaining certain results or certain objectives. Activity objects can be a concrete thing (such as a software) or something more abstract (for example, an idea). Mediation tools, such as a text editor or an e-mail system, are artifacts used to support the object transformation into a result. Tools can be used to manipulate and understand the object, or to improve participants communication and motivation. Human practices are always included in a social context. In Activity Theory the systemic relationships between the subject and its environment are represented by the concepts of community, rules, and labor division. The community is composed by all subjects interested in activity development (usually called by Stakeholders in software engineering community). Rules are conventions for social relationships established by the community. Labor division refers to the form of community organization for the process of transforming an object into a result. Figure 1 illustrates the systemic model proposed by Engeström [7] that shows the relationships between the structuring elements of the activity.
Figure 2. Activity levels. Real life situations always involve an intertwined and connected web of activities that are usually specified using an activity diagram. Because activities are not isolated units, they are influenced by other activities and changes in the environment. Activity Theory uses the terms tension (also called, contradiction) to indicate a misfit, problem, incompatibility, conflict or opportunity that occur within elements of a single activity, or between different activities. Activity Theory sees tension analysis as a source of activity development. Engestrom classifies the tensions in four types [7] (see Figure 3 for an illustration). -
Primary: the tensions found within an element of a single activity. - Secondary: those found between two elements of a single activity. - Tertiary: the imbalances found between an activity and a culturally more advanced version of this same activity (co-constructed with the stakeholders). - Quaternary: the tensions between different activities. A system design usually is rooted in two main tasks: 1) the identification of user problems that justify the new software
project, and 2) the design of a software system that can overcome the problems identified. AT can be useful for supporting these tasks because: first, it helps the software engineer in finding and describing the user tensions and its social roots [4, 23]; second, it offers a framework that helps in making structured insights about how a new software system can support the user activities in order to overcome their tensions[12].
actor depends on another actor to provide a physical resource (or information). A softgoal dependeny is similar to a goal dependency, except that the achievement evaluation of a softgoal is subjective. The softgoal is usually associated to the notion of non-functional requirement. SR models provide a complementary view by describing how the actors are internally structured in order to satisfy their external dependency relations. One can specify internal actor organization by using previously mentioned node types, i.e. goal, task, resource and softgoal, in addition with the Means-End and Task-Decomposition relationships that describe, respectively, how to decompose a goal into sub-goals, and a task into sub-tasks. A Process that integrates AT and i*
Figure 3. Activity tensions. THE I* FRAMEWORK
The i* technique was developed for modeling and reasoning about organizational environments and their information systems [25]. One interesting characteristic of the framework is its support for doing organizational reengineering in order to analyse the effects of system alternatives. This feature motivates the division of the design process in two different stages: one focusing on modeling the organizational environment, called “Early Requirement”, and another whose objective is to design a system to be fitted in the environment modeled, called “Late Requirement” [3]. The i* framework consists of two types of organizational models: the Strategic Dependency (SD) Model and the Strategic Rationale (SR) Model. The Strategic Dependency Model is a graph composed by the environment actors (including here also the software systems) and their dependency relations. The dependency relations modeled can be of various types, including Goal Dependency, SoftGoal Dependency, Task Dependency e Resource Dependency. In a goal dependency, an actor (the dependent) depends on another actor (the dependee) to fulfil a goal, without worrying how this goal will be achieved. The dependee has autonomy to make whatever decisions are necessary to achieve the goal. In a task dependency, an actor depends on another actor to carry out a task. The task-dependency specifies how the task is to be performed, but not why. The depender makes the decision. In a resource dependency, an
In this section we present a requirement engineering process that integrates ethnographical analysis based on AT with i* organizational modeling. The process is divided into three parts (see Figure 5): 1) a practical ethnographical method to support in selecting, describing and analysing user activities and their social relations; 2) a set of mapping guidelines to systematically obtain early requirement i* models from the activities modeled; and 3) a method that uses human practices analysis as a guide for Late Requirement refinement. A preliminary version of the process was published in [6]. The originalities of the one described here are the use of tension analysis to guide the overall design phase and the incorporation of practices of rapid ethnographic. The present process also provides step-by-step methods for the ethnographical analysis and late requirement phases that are not included in the previous work. The mapping guidelines published in [5] are integrated in this approach as one of the steps of the proposed process. The process is aligned to the ISO 13407 standard for usability engineering [9], since it helps to integrate the phases of “Understand and specify the context of use” and “Specify the user and organizational requirements” presented in the ISO 13407 human-centred design cycle (see Figure 4).
Figure 4. The human-centred design cycle (from ISO 13407).
Figure 5. Integrating Activity Theory and Organizational Modeling Ethnographical Analysis
Traditional ethnographical methods are time intensive and hence usually non-practical for the tied software project schedules [24]. To overcome this limitation, the process starts with an ethnographical observation based on the following techniques of Rapid Ethnography [16]: •
•
•
Narrow the research focus. Observe and understand just the user activities and tensions the future system is likely to support. Use key informants as research field guides. Key informants are people with the ability to discuss in advance where the interesting behaviors are most likely to be observed or where the social tensions are most likely to be found. Use multiple interactive observation techniques (interviews, in-loco observations, videos, taperecording of user’s interactions, and others).
In a second stage, there is a computerized qualitative data analysis [20] where the collected ethnographical information are then sorted and classified in the search for clues that point to Activity Theory elements. The qualitative analysis is guided by a four-step method:
1.
Find User Activities: the field-notes and transcribed interactions are analysed to identify basic activity elements and their dependencies. Basic activity elements represent its users, the object to be transformed and the result to be accomplished.
2.
Find Activity Structure: search the ethnography data for the elements that structures each activity (mediation tools, social rules, community and labor division).
3.
Find Activity Levels: look for clues that identify activity actions and operations.
4.
Find Activity Tensions: identify primary, secondary, tertiary and quaternary tensions.
The Mapping Guidelines
The Early Requirements phase ends with the generation of i* organizational model from the activities modeled. The transformation of activity diagrams into early requirements i* models is based on mapping guidelines that analyses the dependencies between subjects in and between activities. The guidelines used to generate the early requirement mode are divided in two groups. The ones used for generating the relations of the Strategic Dependence (SD) Model, and the ones used to derivate the internal actor elements of the Strategic Rationale (SR) Model
In [5] is possible to find an explanation of the mapping guidelines with a detailed description of its application in a project based learning environment. The Late Requirement Phase
Activity Theory offers a structured framework that helps the requirement engineer in giving systematical insights about how a new software system could support the user activities. The i* framework, on the other hand, provides a practical way of presenting system alternatives by way means-end analysis. In other to integrate this two frameworks for late requirement, the following two-step method is used: •
•
Select Critical Tensions: analyze and select with stakeholders the critical tensions that will justify system development. Do System Refinement: perform i* graphtransformation in late requirement by reflecting on how new software requirements could support the user activities in order to overcome the critical tensions identified.
Usually the overall process is iterative. As soon as a requirement engineer obtain an organizational structure of the system, its often necessary to obtain a deeper understanding of user practices in order to support them in detail. New ethnographical observations are then realized using a narrower system perspective focus. RELATED WORKS There are some works that also tries to integrate social analysis with requirement engineering techniques [8, 24]. Instead of engaging in a broad theoretical debate, we will concentrate here on works that use Activity Theory. There are various papers relating experiences on using Activity Theory tension analysis for software design [4, 17, 23]. However, their results are usually a natural language description of requirement suggestions that could overcome the tensions identified. Martins and Daltrini [15] proposed a requirement elicitation methodology based on Activity Theory. Their focus is on using activity diagrams to specify system requirements, comparing it wih the UML Use Case approach [21]. Using AT concepts only for system specification, limits its use for guiding system design by way of human practices analysis. The work does not have a clear division between the early and late requirement phases. Korpela, Soryan and Olufokunbi [9] mentioned in their paper conclusion the possibility of linking UML use cases to AT actions as a way of integrating AT analysis and requirement engineering processes. We prefer to use i* since it provides facilities for specifying the organizational environment and their information systems using the same modeling framework. The i* technique offers a way to analyse the various system possibilities by doing graph transformations in an organizational model. Besides, there
are also guidelines for transforming i* models into UML use case [22] and class diagrams [2]. CONCLUSIONS AND FUTURE WORKS
In this paper we presented a system design process that starts with an abstract theoretical representation of context (obtained from ethnographical studies) and then use it to complement and guide organizational and systems analysis using the i* framework. The approach combines the facilities of Activity Theory to understand, describe and make insights about the context of use, with the i* facilities to model the system functionalities and also visualize its impact on the actors dependence relations. As future work, we intend to pursue the following research topics: •
In the i* framework [25], a task can be decomposed in alternative sub-tasks by way of means-end links. However, Activity Theory does not allow the specification of alternative actions and operations. We intend, as a future research work, to introduce alternative actions and operations in the Activity Theory framework in order to improve its descriptive power.
•
An industrial application of the process based on the context analysis of a Pharmaceutical Laboratory is under development.
•
We envision, as a future work, extend the set of guidelines to deal with specific non-functional aspects of AT. From analysing some AT elements, such as the user motivation and the social rules, we believe new mapping guidelines can be created to derivate useful soft-goal dependency relations in the i* early requirement model.
REFERENCES
1. S. Bødker, “Activity theory as a challenge to systems design”, In H-E. Nissen, H. K. Klein and R. Hirscheim (eds.): Information Systems Research: Contemporary Approaches and Emergent Traditions, Elsevier, Amsterdam, 1991, pp. 551-564.
2. J.B. Castro, F.M.R. Alencar, and G.A.A.Cysneiro Filho, “Integrating Organizational Requirements and Object Oriented Modeling”, Proceeding of the 5th IEEE International Symposium on Requirements Engineering, Toronto, Canada, 2001, p.146 – 153. 3. J.B. Castro, M. Kolp, and J. Mylopoulos, “Towards Requirements-Driven Information Systems Engineering: The Tropos Project”, Information Systems, Elsevier, Amsterdam, The Netherlands, The Netherlands. v. 27, n. 6, p. 365-389, 2002 4. P. Collins, S. Shukla, and D. Redmiles, “Activity Theory and System Design: A View from the Trenches”, Nardi, B. A., Redmile, D., (eds), Activity Theory and the
practice of Design. Computer Supported Cooperative Work., 2002, Vol. 11, Nos. 1-2. pp 55-80. 5. G.G. Cruz Neto, A.G. Gomes, and J.B. Castro, “Mapeando Diagramas da Teoria da Atividade em Modelos Organizacionais Baseados em i*” (in portuguese), In Proceedings of the VII Workshop on Requirements Engineering, Tandil, Argentina, 2004, pp. 39-50. (an english version of this paper was selected to appear in the Journal of Computer Science and Technology, special issue on Software Requirement Engineering, vol. 5 – no. 2 – ISSN 1666-6038, July, 2005). 6. G.G. Cruz Neto, A.S. Gomes, and P. Tedesco, “Aliando Teoria da Atividade e TROPOS na Elicitação de Ambientes Colaborativos de Aprendizagem” (in portuguese), In Proceedings of the VI Workshop on Requirements Engineering (WER 2003), Piracicaba, Brasil, 2003, pp 63-77. 7. Y. Engeström, Learning by Expanding, Helsinki: Orienta-Konsultit, 1987. 8. J. Goguem, “Requirement Engineering as the Reconciliation of Technical and Social Issues”, Goguem, J and Jirotka, M (eds): Requirement Engineering: Social and Technical Issues, London, UK:Academic Press, 1994, pp. 165-199. 9. ISO, “ISO 13407: Human-Centred Design Process for Interactive Systems”. International Standard Organisation, 1999. 10. M. Korpela, H.A. Soriyan, K.C. Olufokunbi, “Activity Analysis as a Method for Information System Development: General introduction and experiments from Nigeria and Finland”, Scandinavian Journal of Information System, 2000, vol 12, pp 191-210 11. A. N. Leont´ev, “The Problem of Activity in Psychology”, J. Werstch (Ed.), The concept of Activity in Soviet Psychology. Armonk, New York: M. E. Sharpe, inc., 1979. 12. C. Macaulay, D. Benyon, and A. Crerar, “Ethnography, Theory and System Design: From Intution to Insight”,Journal of Human Computer Studies, 2000, 53, 35-60. 13. Maguire, M. (2001a): “Context of Use within Usability Activities”, International Journal of Human-Computer Studies, 55, pp. 453-483. 14. Maguire, M. (2001b): “Methods ro Support HumanCentered Design”, International Journal of HumanComputer Studies, 55, pp 587-634. 15. L. E. G. Martins, and B. M. Daltrini, “An Approach to Software Requirement Elicitation Using Percepts from Activity Theory”, Proceeding of the 14th IEEE International Conference on Automated Software Engineering (ASE´99), Florida, USA, 1999.
16. D. Milen, “Rapid Ethnographiy: Time Deepening Strategies for HCI Field Research”, Proceedings of the Conference on Designing Interactive Systems, ACM Press, New York., 2000, pp: 280-286. 17. D. Mwanza, “Where Theory meets Practice: A Case for Activity Theory based Methodolgy to guide Computer System Design”, Interact’2001, Japan, 2001. 18. B.A. Nardi, (ed), Activity Theory and Human-Computer Interaction, London: MIT Press, 1996. 19. B. A. Nardi, and D. Redmile, (eds), Activity Theory and the practice of Design, Computer Supported Cooperative Work., 2002, Vol. 11, Nos. 1-2 20. T.J. Richards, and L. Richards, “Using Computers in Qualitative Research”. In Denzin, N. K. and Lincoln, Y. S. (eds.): Collecting and Interpreting Qualitative Materials. Sage Publication, 1998, pp. 211-243. 21. J. Rumbaugh, I. Jacobson, and G. Booch, The Unified Modeling Language Reference Manual, Addison Wesley, 1999. 22. V.F. Santander, and J.F. Castro, “Deriving Use Cases from Organizational Modeling”, IEEE Joint International Requirements Enginnering Conference, RE´2002, University of Essen, Germany, September 913, 2002, pp. 32-39. 23. P. Turner, and S. Turner, “From description to requirements: an activity theoretic perspective”, Proceedings of the international ACM SIGGROUP conference on supporting group work. Arizona, 1999, pp. 286-295. 24. S. Viller, and I. Sommerville, “Social Analysis in the Requirement Enginnering Process: From Etnography to Method”, 4th IEEE International Symposium on Requirement Engineering. Limerick, Ireland, IEEE Computer Society Press, Los Alamitos, 1999, pp. 6-13. 25. E. Yu, Modelling Strategic Relationships for Process Reengineering, Phd thesis, University of Toronto, Department of Computer Science, 1995.
