Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Using the organisational actor concept in information system analysis Monu, Kafui Andre 2011

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
24-ubc_2011_fall_monu_kafui.pdf [ 2.46MB ]
Metadata
JSON: 24-1.0072052.json
JSON-LD: 24-1.0072052-ld.json
RDF/XML (Pretty): 24-1.0072052-rdf.xml
RDF/JSON: 24-1.0072052-rdf.json
Turtle: 24-1.0072052-turtle.txt
N-Triples: 24-1.0072052-rdf-ntriples.txt
Original Record: 24-1.0072052-source.json
Full Text
24-1.0072052-fulltext.txt
Citation
24-1.0072052.ris

Full Text

USING THE ORGANISATIONAL ACTOR CONCEPT IN INFORMATION SYSTEM ANALYSIS by KAFUI MONU B.Comm (Honours), University of Manitoba, Winnipeg, 2002 M.Sc. in Business Administration, University of British Columbia, Vancouver, 2005 A DISSERTATION SUBMITTED IN PARTIAL FULFILMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY in THE FACULTY OF GRADUATE STUDIES (BUSINESS ADMINISTRATION)  THE UNIVERSITY OF BRITISH COLUMBIA (Vancouver)  August 2011  © Kafui Monu, 2011  Abstract The correct and complete identification of requirements for information systems is important to the development and implementation of systems into organisations. These requirements are gatherd using conceptual models, which are important tools used by system analysts to understand organisations. However, as more users participate in system analysis, researchers have found that traditional conceptual modeling techniques do not completely represent the contextual information in a user's scenario. In this work we design and develop a structured conceptual modeling method, called the organisational actor method. We define a conceptual modeling method as a set of concepts, rules, and method for representing phenomena in the world. The organisational actor method represents the context of an environment which can be represented by understanding how an actor thinks about the environment and how the environment affects, and is affected by, the actor. A design-science approach was used to develop the organisational actor method. The approach used the theory of affordances, the systems approach, ontology, and software agent literature as theoretical foundations for the development of the organisational actor method. This study's purpose was to develop a method that could represent the internal view of an actor, the external view of the actor, and connect the two views. We also conducted four studies determining the usefulness and usability of the organisational actor concepts and the organisational actor method. We found that our concepts: perceptions/inputs, beliefs, learning, goals, reasoning, intentions, capabilities, actions, output are usable because non-technical people implicitly use the organisational actor concepts when describing domains. Also, our concepts are useful because domain experts judge them to be better representations of the domain than another commonly used conceptual modeling language called i*, and our method is usable because domain experts better represent the domain when using a method than when they don't. Finally, our method is useful because it can be used to gather information from employees about how they perform, and make decisions about, their work. In future research we will use our method to design cooperative information systems and to gain an understanding of processes that involve interdependent but autonomous individuals.  ii  Preface This research gained ethics approval from the UBC Behavioural Research Ethics Board. The certificate number of the Ethics certificate was H08-00726.  iii  Table of Contents Abstract..........................................................................................................................................ii Preface..........................................................................................................................................iii Table of Contents.......................................................................................................................iv List of Tables..............................................................................................................................vii List of Figures...........................................................................................................................ix Acknowledgements...................................................................................................................x Chapter 1: Introduction...............................................................................................................1 1.1 Motivation...........................................................................................................................1 1.1.1 User Story…....................……………………........………….……….................……2 1.1.2 Problem Scenarios……………..........................………....…………………………3 1.1.3 Use-case Modeling…………………................…………………………………….4 1.1.4 Discussion……………………………..................…………………………………5 1.2 Agent Conceptual Modeling.................................................................................................6 1.2.1 Gaia...............................................................................................................................8 1.2.2 Role Oriented Analysis and Design for Multi-agent Programming..............................9 1.2.3 Agent-object Relationship Modeling Language.........................................................9 1.2.4 Tropos..........................................................................................................................10 1.2.5 i* Framework..............................................................................................................11 1.2.6 Multiagent Based Integrative Business Modeling Language (MibML).....................12 1.2.7 Evaluation of Agent Modeling Languages..................................................................13 1.2.8 Representing Employees' Descriptions Using Agent Modeling Languages...............17 1.3 Overview of the Research Method.....................................................................................19 1.3.1 Overview of Theoretical Foundations.........................................................................20 1.3.2 Overview of Design Activities...................................................................................21 1.3.3 Overview of Artifact Testing......................................................................................24 1.4 Conclusion..........................................................................................................................26  Chapter 2: The Development of the Organisational Actor Method.................................27 2.1 Introduction.........................................................................................................................27 2.2 Theoretical Foundations......................................................................................................28 2.2.1 The Theory of Affordances.........................................................................................28 2.2.2 Systems Approach.......................................................................................................28 2.2.3 Ontology: Bunge-Wand-Weber Ontology..................................................................30 2.2.4 Software Agent Concepts............................................................................................31 2.3 Design Activities.................................................................................................................32 2.3.1 Defining the Organisational Actor Modeling Construct............................................34 2.3.2 Determining the Components of the Organisational Actor Modeling Construct.......35 2.3.3 Identifying the Organisational Actor Concepts..........................................................37 2.3.4 Determining the Relationships Between the Organisational Actor Concepts............42 2.3.4.1 Structural Metamodel.........................................................................................44 iv  2.3.4.2 Dynamic Metamodel............................................................................................46 2.3.4.3 Interaction Metamodel........................................................................................49 2.3.4.4 Conclusion...........................................................................................................51 2.3.5 Determining Rules to Validate Organisational Actor Models....................................51 2.3.6 Determining a Process for Developing Organisational Actor Models.......................55 2.3.7 Conclusion...................................................................................................................66 2.4 Organisational Actor Modeling Diagrams.........................................................................68 2.4.1 Using the Organisational Actor Diagram to Represent a Domain.............................69 2.4.2 Using the Organisational Actor Method.....................................................................71 2.5 Conclusion..........................................................................................................................74  Chapter 3: Validation of the Organisational Actor Method..............................................77 3.1 Study 1: Determining the Usability of the Organisational Actor Concepts.......................82 3.1.1 Subjects......................................................................................................................82 3.1.2 Method........................................................................................................................82 3.1.3 Results........................................................................................................................85 3.1.4 Threats to Validity.......................................................................................................89 3.2 Study 2: Determining the Usefulness of the Organisational Actor Concepts....................90 3.2.1 Subjects.......................................................................................................................90 3.2.2 Method........................................................................................................................90 3.2.3 Results.........................................................................................................................99 3.2.4 Threats to Validity.....................................................................................................101 3.3 Study 3: Determining the Need for an Organisational Actor Method.............................102 3.3.1 An Organisational Actor Modeling Method for Study 3..........................................103 3.3.2 Experimental Design.................................................................................................105 3.3.3 Experiment 1: Exposing Novice System Analysts to a Method...............................107 3.3.3.1 Propositions.......................................................................................................108 3.3.3.2 Subjects.............................................................................................................109 3.3.3.3 Method..............................................................................................................109 3.3.3.4 Results...............................................................................................................110 3.3.4 Experiment 2: Giving Expert System Analysts a Method........................................113 3.3.4.1 Propositions.......................................................................................................114 3.3.4.2 Subjects..............................................................................................................114 3.3.4.3 Method...............................................................................................................115 3.3.4.4 Results...............................................................................................................115 3.3.5 Threats to Validity.....................................................................................................118 3.4 Study 4: Determining the Usefulness of the Organisational Actor Method.....................119 3.4.1 Subject ......................................................................................................................121 3.4.2 Method.....................................................................................................................122 3.4.2.1 An Organisational Actor Guided Knowledge Acquisition Technique.............122 3.4.2.2 Empirical Procedure..........................................................................................124 3.4.3 Results......................................................................................................................125 3.4.4 Threats to Validity.....................................................................................................130 3.5 Conclusion........................................................................................................................131  Chapter 4: Conclusion............................................................................................................134 4.1 Summary of Research………………………………....…………………………...……134 4.2 Contributions to Research and Practice…………………....……………………………136 4.3 Conclusion and Future Research…………………………………………....…………..142 v  References.................................................................................................................................144  vi  List of Tables Table 1: Evaluation of Usage Modeling Techniques (Adapted from Riedemann & Freitag 2009)................................................................................................................................................6 Table 2: Criteria For Evaluating Agent Modeling Frameworks....................................................13 Table 3: Evaluation of Agent Modeling Languages.....................................................................16 Table 4: Overview of Artifact Test Studies...................................................................................26 Table 5: BWW Ontology Concepts...............................................................................................31 Table 6: Reconciliation of Miller 1978 and Bertalanffy 1968......................................................35 Table 7: Organisational Actor Concepts and Definitions.............................................................40 Table 8: Structural Relationship between Organisational Actor Concepts..................................45 Table 9: Organisational Actor Concepts in Relation to Actor Behaviour....................................48 Table 10: Relationship between Organisational Actor Concepts for Representing Interactions..50 Table 11: Integrity Checks.............................................................................................................54 Table 12: Actions to Model a Domain Using the Organisational Actor Method.........................58 Table 13: Actor's Traits Represented by the Organisational Actor Method.................................67 Table 14: Artifacts and Criteria for Validation Studies.................................................................78 Table 15: Overview of Validation Studies....................................................................................80 Table 16: Colloquial Definitions of the Organisational Actor Concepts......................................83 Table 17: Synonyms of the Organisational Actor Concepts Identified by Coders.......................84 Table 18: Incidents of Organisational Actor Concepts in User Descriptions (Terms)................86 Table 19: Incidents of Organisational Actor Concepts in User Descriptions (Phrases)...............87 Table 20: Difference between the Control and Treatment Groups in Study 2..............................92 Table 21: i* Concepts Represented by Organisational Actor Concepts.......................................93 Table 22: Results of the i* and Organisational Actor Concepts Study.........................................99 Table 23: A Method for Some Organisational Actor Concepts in a Scenario............................105 vii  Table 24: Breakdowns in Subjects' Modeling Process (Experiment 1).......................................111 Table 25: Average Quality of Organisational Actor Diagrams (Experiment 1).........................113 Table 26: Breakdowns in Subjects' Modeling Process (Experiment 2).......................................116 Table 27: Average Quality of Subjects' Diagrams (Experiment 2).............................................117 Table 28: Organisational Actor Concepts Elicited in the Knowledge Acquisition Process.......121 Table 29: Organisational Actor Method.....................................................................................122 Table 30: Questions to Elicit Organisational Actor Concepts....................................................123 Table 31: Breakdown of Organisational Actor Concepts Elicited by Interview Questions.......125 Table 32: Identification of Organisational Actor Concept by Question.....................................126 Table 33: Identifying Requirements Using the Organisational Actor Method..........................138  viii  List of Figures Figure 1. User Story with Notes (adapted from Cohn 2004)..........................................................3 Figure 2. Design Process of the Organisational Actor Method.....................................................23 Figure 3. Subsystems for Information Processing (adapted from Miller 1978)............................30 Figure 4. Design Process to Develop the Organisational Actor Method......................................33 Figure 5. Reconciliation of Miller 1978 and Bertalanffy 1968.....................................................37 Figure 6. Concepts Linked to the Organisational Actor Modeling Construct..............................40 Figure 7. Structural Metamodel of the Organisational Actor.......................................................46 Figure 8. Dynamic Metamodel of the Organisational Actor.......................................................49 Figure 9. Interaction Metamodel of the Organisational Actor....................................................51 Figure 10. Proposed Sequence of the Organisational Actor Method............................................65 Figure 11. Modeling Diagram for Organisational Actor Concepts..............................................69 Figure 12. Organisational Actor Representation of Disaster Management Example...................70 Figure 13. Diagram Based on the Application of the Organisational Actor Method...................74 Figure 14. i* Strategic Dependency Diagram of the Scenario (Castro et al. 2002)......................94 Figure 15. i* Strategic Rational Diagram of the Scenario (Castro et al. 2002)............................95 Figure 16. Translated Organisational Actor Diagram of the Scenario (Strategic Dependency)...96 Figure 17. Translated Organisational Actor Diagram of the Scenario (Strategic Rationale).......97 Figure 18. Organisational Actor Diagram of the Scenario...........................................................98 Figure 19. Organisational Actor Diagram of an Example Scenario ..........................................105 Figure 20. Subjects‘ Modeling Processes (Experiment 1) Above: Control Below: Treatment...112 Figure 21. Subjects‘ Modeling Processes (Experiment 2) Above: Control Below: Treatment...117 Figure 22. Initial Organisational Actor Diagram of Disaster Management Professional...........127 Figure 10: Finalised organisational actor Diagram of Disaster Management Professional  Figure 23. Finalised Organisational Actor Diagram of Disaster Management Professional......129  ix  Acknowledgements "We are building something here, building it from scratch. All the pieces matter." - 'Detective Lester Freamon' (The Wire)  I would first like to thank my supervisor, Dr. Carson Woo who was extremely helpful over the course of the dissertation. From data collection to the structure of the dissertation itself, his help and support has been invaluable. Also because of him I have been able to make connections in the academic community which could not have been made otherwise. I would also like to thank Drs. Yair Wand and Philippe Kruchten. Dr. Wand has provided excellent feedback on the theoretical foundations of my work and has strengthened the rigour of this work. Working with Dr. Kruchten on a research project, I was able to find an application for my work in the disaster management area. It was a pleasure working with him. There are others who helped with the creation of this work, whether they are aware of it or not. I would like to thank the wonderful friends that I met through my years pursuing the PhD. It is always good to have people by your side who know the pains (and joys) of graduate work. Lastly, I would like to extend my greatest appreciation to my parents and sister who were not only wonderful editors, sounding boards, and reviewers but were also emotional support. This work would not have been possible without them.  x  Chapter 1: Introduction Conceptual modeling is a technique used in system analysis to understand and communicate what is happening in an organisation. To gain an understanding of what is happening in a firm, analysts usually interview employees about the business processes. Unfortunately, the involvement of the user in the system analysis process is difficult because analysts and users can have problems communicating with each other. For instance, as mentioned by Alexander and Maiden (2004), users provide analysts with informal descriptions about their environment and tasks but analysts look for a structured description of the domain. Alvarez (2002) suggests that interviewees should be allowed to simply tell their stories and analysts should find requirements within the stories. However Riedemann and Freitag (2009), in their analysis of usage modeling techniques, state that developers do not like to use techniques that create long narratives since the requirements are difficult to identify. In this Chapter, we propose that an agent conceptual modeling language would structure the users' descriptions of their work and maintain the richness of the user‘s description of the domain. Agent conceptual modeling focuses on the actors in the domain, which are entities that perceive, think, and act in an environment. These actors can structure the description of the protagonists in the users‘ stories and include contextual information about the process, such as the motivations for the process and attitudes of the process‘s participants towards others in the organization. However, none of the existing agent conceptual modeling languages have been used to explicitly represent the user's description of the domain, so we must evaluate the appropriateness of the languages. If we find that none of the languages are appropriate for capturing aspects of the domain that contribute to the richness of the user's description then we will present a research plan for creating a conceptual modeling method that can be used to structure the user's description and capture the richness of his or her description.  1.1 Motivation The requirements of an information system describe the intended features of the system. According to Nuseibeh and Easterbrook (2000), the importance of correct and complete identification of requirements for an information system has been long recognized in the literature. To determine the requirements of a system an analyst must understand the application 1  domain. Conceptual models are important tools used by system analysts during requirements gathering to understand the domain. A conceptual model is a representation, usually a diagram, of a situation in the world. Conceptual modeling, the act of creating conceptual models, has been defined as the ―activity of formally describing some aspect of the physical and social world around us for the purposes of understanding and communication‖ (Mylopoulos 1992, p. 50). Sets of concepts are used in conceptual modeling to represent real world domains (Wand and Weber 2002). For example, the entity-relationship diagram, introduced by Chen (1976), is based on entity and relationship constructs and the data flow diagram, discussed by DeMarco (1979), is based on processes, data store, and data flow modeling constructs. According to McKeen, Guimaraes, and Wetherbe (1994), the main source of information for conceptual models used in systems analysis is the employees involved in the business process. Unfortunately it is difficult to involve the user in the system analysis process because analysts and users can have problems communicating with each other. As mentioned by Alexander and Maiden (2004), analysts receive their users' information by informal descriptions about their environment and tasks but analysts look for a structured description of the domain. According to Beath and Orlikowski (1994), researchers have suggested that more structured or rigorous modeling techniques will help users and analysts communicate and that some have developed system development methods to help facilitate the communication between the analyst and the user. One technique used in system analysis to structure and understand the users' descriptions of their domain is called usage modeling. Unlike traditional conceptual modeling languages like Entity Relationship diagrams, usage modeling focuses its description of the domain on the user and not on the system. Unfortunately, as mentioned by Riedemann and Freitag (2009) usage modeling techniques either do not entirely focus on the user or are not structured enough to identify system requirements. Three popular techniques of conceptualising user information are: User stories, problem scenarios, and use-case modeling. 1.1.1 User Story A user story "describes functionality [system features] that will be valuable to either a user or purchaser of a system or software" (Cohn 2004, p. 4). Users personally construct user stories, which are usually one-sentence descriptions of a functionality, e.g. a user story may be "User can access work files from home." These stories are usually put on index cards and once completed by the user, the analyst determines the details of these stories through conversation with the users 2  who wrote them. According to Cohn (2004), this process could lead to the generation of more user stories by the user, or "notes" added to the original user story. For instance, through the elicitation process the analyst may find that the user wants to upload files from home to the work station and be able to access work files that are available to them at work. The first detail of this example is another user story because it can be performed separately from "access work files from home". However, the second detail would be in a note in the "Users can access work files" user story. As mentioned by Cohn (2004). This is done to ensure that every use story is manageable and testable. User stories are then used to guide the development of features for the system; for example, adding a remote desktop function to office computers based on the story above. In Figure 1, we show an example of a user story for a job posting web site.  Figure 1: User Story with Notes (adapted from Cohn 2004) The strength of the user story technique is that it actively involves the user in the requirements generation process and development process. Riedemann and Freitag (2009) state that it is the user who generates the requirements through user stories, and the stories are the only documentation the system designers have to build the system. An additional benefit is that user stories also provide a more detailed explanation of the interaction between users and the information system than do use case models. 1.1.2 Problem Scenarios A problem scenario is defined as "a simple story about people carrying out their activities" (Robson & Carroll 2002, p.2). The problem scenario highlights the objectives of users (referred to as actors) in the scenario and, according to Robson and Carroll (2002), problem scenarios 3  include seven phenomena; settings, actors, task goals, plans, evaluations, actions and events. Settings are the details of the situation, such as the time of day, and the objects that exist in the environment that can have an effect on the scenario. As in context, setting can be used to gain a better understanding of what may happen in the domain; for instance, knowing a user will be using a database in an accounting office versus a children's nursery will give the designer an idea of how the database will be utilized and the features it should include. Actors are humans interacting in the domain, task goals are effects on the world that motivate the actor, plans are ways of converting a goal into a behavior, evaluation is a way of interpreting features of the environment, actions are observable behaviours of the actor and events are actions caused by non-actors. The main strength of the problem scenario is that it focuses on the actor's behaviour and story rather than on the system. Also, as mentioned by Alexander and Maiden (2004), it is easy for users to understand and analyse problem scenarios, as they are similar to their intuitive thought processes concerning the domain. 1.1.3 Use-case Modeling According to Jacobson, Christerson, Jonsson, and Övergaard (1992), use-case modeling is used to analyse the environment before implementing an information system. In analysis, usecase modeling represents actors and use cases. Actors are the prospective users of the information system, and use cases are the possible functionalities of the information system. Jacobson et al. (1992) show how use-case modeling can help to specify the requirements of the system that will be built. However, for the purposes of this study we will also discuss a more abstract use of use-case modeling which represents a business as a system. Jacobson, Ericsson, and Jacobson (1994) state that the concepts used to represent information systems and users can also be used to represent a business and its stakeholders, meaning that use-case modeling does not have to represent an actual information system. The major difference between this type of use-case modeling and the one specified in Jacobson et al. (1992) is that the business is identified as the system and the internal objects within the system are the employees, machinery and resources that the business employs to perform its functionalities. An example used by Jacobson et al. (1994) is that a business system may be a restaurant and that the customer is an actor (i.e. user) of the restaurant. In the business system the waiter, food, and drinks would be considered as objects. Jacobson et al. (1994) state that objects are "products or things that are used during a flow of events in the system" (p. 113). 4  Jacobson et al. 1994 also mention a technique that can be used to better understand the domain. First a use-case model is created to determine the users of the business and the use cases in the system. Second, each use case is described to provide more details of the interaction between the actor and the system. The use-case description specifies the flow of events occuring within the system, and can include alternative events that occur under unexpected circumstances. Unlike the use-case model, the use-case description is represented in a narrative form. Lastly, to obtain more details about the business, an object model is created which identifies the components of the business used to enact the use cases. Each of these representations provides an important view of the business; the use-case model identifies what the business does, the usecase description describes the activities that occur within each use-case, and the object model describes resources, such as equipment and supplies, things used in the business. 1.1.4 Discussion Although the usage modeling techniques discussed in Sections 1.1.1 - 1.1.3 adequately address a variety of issues, they have their weaknesses. User stories are focused on very specific interactions between the user and the system, which leads to difficulty representing the "big picture" of how, why, and, when user stories occur (Riedemann & Freitag 2009). This also means that the actor's behaviour is simply modeled as an extension of the system's features rather than what the user wants to achieve. The problem scenario does represent the users' perspectives and behaviour, but these scenarios are unstructured and create lengthy documentation (Riedemann & Freitag 2009). In addition, the creation of problem scenarios involves creative writing skills to develop a plot and story rather than the structured documentation of facts usually utilized by developers to design systems (Riedemann & Freitag 2009). Lastly, use-case modeling represents the system adequately and can identify relevant events and resources in a business, but does not view the internal objects of the domain as being able to make decisions and have goals. However these "objects" may make decisions that affect the use cases in the system. Also it is difficult, using the use-case model, to represent the actor‘s thought process on the domain and decision making. These elements can be specified in the use case description, but it would require the the analyst to read through a large number of use case descriptions to identify exactly how the actor thinks about the domain, and there is no guarantee that the use case description will include this information. Table 1 shows the strengths and weaknesses of the techniques.  5  Table 1: Strengths and Weaknesses of Usage Modeling Techniques (Adapted from Riedemann & Freitag 2009) Usage Modeling Strengths Weaknesses Techniques -Encourages communication with users, -Each user story is very detailed User Story leading to reduced documentation effort. -Helps team focus implementation only on aspects related to the user's tasks.  Problem Scenario  Use-case modeling  -Focuses on user tasks, not on system functionality. -Easy for user to recognize their own situation, thereby enabling dialogue between the system analyst and the user. -Encourages the developer to consider the user‘s viewpoint. -Enables early focus on wording as well as appropriate interaction concepts and features. -Easy to read in natural language and transferable to more formal specifications.  and focuses on a particular part of a user's task, making it difficult to understand the "big picture". -Documentation is haphazard and individual user stories may be misplaced after implementation. -Usage requirements can‘t be obtained by reading; they must be derived. -Developers don‘t like to work with long text documents. -Does not take into account the business object's view of the domain. -Difficult to model and understand how the business system and actors think about the domain.  Based on our analysis we propose that, generally, the usage modeling techniques have two problems; documents developed by these techniques can either easily be translated into system requirements but cannot capture the "big picture" of the domain, or they can capture the domain but defy easy translation into system requirements. Since it is important for the analyst to create a set of system requirements from these conceptual models (Nuseibeh & Easterbrook 2000) and to represent all of the narrative aspects of the domain (Alexander and Maiden 2004), we propose that it would be beneficial to analysts as well as users to use a conceptual modeling technique that has both of these features.  1.2. Agent Conceptual Modeling To represent the users' narrations of their work we must first represent their performance of activities in their environment. According to Yu (2001), one type of conceptual modeling suggested for systematically representing users interacting in their organisations is agent conceptual modeling. For example, Yu (2001) stated that:  6  ―Much like the concepts of activity and object that have played pivotal roles in earlier modeling paradigms, the agent concept can be instrumental in bringing about a shift to a much richer, socially-oriented ontology that is needed to characterize and analyze today's systems and environments‖ (Yu 2001, p. 123). We propose using agent conceptual modeling to represent users as agents in the domain. According to Wooldridge (1999) an agent is an autonomous entity that can react, initiate interactions, and respond to changes in the environment. Specifically, agents ―perceive their environment and respond in a timely fashion‖, ―exhibit goal oriented behaviour by taking the initiative‖, and ―interact with other agents‖ (Wooldridge 1999, p.32). For an agent to have these abilities, Wooldridge (1999) assumes that it must perceive its environment, form attitudes or opinions about the environment, and use this information to decide on an action. An agent must be able to perceive its environment to recognise the state of things, like objects, that are external to the agent, and the events that occur in the environment. The agent also must form opinions about the environment to construct a mental model of the domain. This model is then used to determine the actions that the agent wants to perform. From this description of the agent and its abilities, we propose that the agent can perform three functions: thought, interaction, and thoughtful action. Thought refers to the agent's ability to internally model its environment and learn about the world. Interaction refers to the changes in the environment caused by the agent, and thoughtful action refers to the agent's thinking process that leads to interaction with the rest of the environment. So, to perform these functions, we propose that the intelligent agent must have external states and processes, as well as internal states and processes. Internal states represent the components of the agent's mental model, such as decisions, objectives, and beliefs. Internal processes change these components and represent such events as the agent's decision-making and learning. External states represent objects that are external to the agent in the environment and external processes change these objects representing actions and events that occur in the environment. Based on this specification of an agent and research in organisational behaviour, we propose that the intelligent agent is the same as the user in an organisation. According to the behavioral theory of the firm proposed by Cyert and March (1963), organisations consist of individual actors who perceive their organisational environment, make decisions about their jobs, and interact with other people and objects within the organisation. Using this description of employees, we surmise that the behaviour of people in an organisation is analogous to the interaction between multiple intelligent agents; i.e. agents must perceive their environment, 7  make decisions about how to act, and interact with each other and objects in the environment. Therefore, for a conceptual modeling language to represent users' and their description of their work it must be able to accurately represent the intelligent agent. Currently there are many conceptual modeling languages that are used to represent agents, but they have not been specifically evaluated for representing users' descriptions of their work. In this section, we will provide a brief overview of some common agent modeling languages. We will also determine whether agent modeling languages directly represent agents as described by Wooldridge (1999). We do this to ensure that the modeling language can be used to describe an incarnation of an agent whether it is a software system or a human being. If a language is developed for the sole purpose of analysing the environment for software agent implementation, the language may not include internal processes of the agent since that will be created by software agent system developer. However, if we want to represent the contextual information of the domain we must also directly represent an abstraction of internal processes of the human agent. 1.2.1 Gaia Gaia is a software development method developed by Wooldridge, Jennings, and Kinny (2000) for creating agent-based information systems. It consists of five models or diagrams which are used during different stages of the information systems development process: the roles model, interaction model, agent model, services model, and acquaintance model. We will focus only on the roles model and interaction model because only these models are used in the system analysis phase of the Gaia method. The roles model's main concept is the role. A role can be adopted by an agent and consists of four other concepts: responsibilities, permissions, activities, and protocols. Responsibilities represent the states of the world desired and undesired by the agents. Permissions represent the resources available to agents and how they can be used. Activities represent ―private‖ actions performed by the agent that do not affect, nor can be seen by, other agents. Lastly, protocols represent interactions between roles. The interaction model provides a more detailed description of each protocol outlined in the role model. Each protocol in this description is described using six other concepts: purpose, initiator, responder, inputs, outputs, and processing. The purpose describes the type of interaction the protocol is representing. The initiator begins an interaction with the responder. Inputs represent information used by the initiator to begin the interaction, and outputs represent 8  the information given to, or supplied by, the responder in the interaction. Lastly, processing represents changes in the environment caused by the interaction. Therefore, in the Gaia Method the internal aspects of the agents are represented in the roles model, and the external view is represented through the protocols detailing the agents' interaction with the objects and other agents. 1.2.2 Role Oriented Analysis and Design for Multi-agent Programming The Role Oriented Analysis and Design for Multi-agent Programming (ROADMAP) method is an extension of the Gaia method developed by Juan, Pearce, and Sterling (2002). The ROADMAP method is similar to Gaia except, according to Juan et al. 2002), it adds three new models to the system analysis phase of the method: the use case, environment, and knowledge models. The use case model is similar to the use case model previously mentioned, but instead of representing actors interacting with a system, the model was developed by Juan et al. (2002) to represent actors interacting with a set of idealised agents that perfectly perform the functions of a system. The environment model describes the environmental zones, which represent the features of the environment that the agent system(s) will be situated, using the static object, object, constraint, source of uncertainty, and assumption concepts. Static objects represent things in the world that the agent is aware of, but does not interact with, while objects represent things that interact with the agents. Constraints define the properties of the environmental zone; for example, an environmental zone called a "meeting room" may have a constraint that it cannot fit more than twelve people. Sources of uncertainty represent uncertain aspects of the environmental zone. Assumptions represent the guesses that the modeler makes about the environmental zone. The knowledge model is based on the use case model and highlights the knowledge the agent needs in order to perform its actions. These are represented by the knowledge component concept that represents entities in the environment, which contain information, such as blueprints and legal documents. This concept can also represent knowledge internal to the agents. The knowledge model also connects knowledge components to roles in the domain. 1.2.3 Agent-object Relationship Modeling Language The Agent-Object Relationship Modeling Language (AORML) is an agent conceptual modeling language, developed by Wagner (2003), for designing software systems (Wagner 2003). The language has several diagrams which are split into external and internal models. 9  External models represent the observer‘s perception of the interaction between agents , and internal models show the environment from the perspective of a particular agent. The concepts used in AORML diagrams are: agents, objects, actions, associations, and commitments/claims. An agent is the representation of an actor in the domain. A specific type of agent is the focus agent, which determines the perspective of an AORML diagram. An object represents non-agent objects in the domain and the agent has an internal object which acts as the agent's representation of external objects. Actions are events that affect agents and are split into two types; the message type communicates information to an agent and the non-message type affects objects in the domain. Associations represent relationships between entities, and commitment/claim represents the agents' duties and/or expectation for a particular action. The model also represents rights and reaction rules. Rights denote whether an agent has the right to perform a particular action while the reaction rules represent how the agent changes its internal objects and when it performs actions. External models have four diagrams: the agent diagram, interaction sequence diagram, interaction pattern diagram, and interaction frame diagrams. Agent diagrams show the relationship between objects and agents. The interaction sequence diagram shows typical examples of a particular process, interaction pattern diagrams show the types of interactions that can occur based on different contexts, and the interaction frame diagrams show the actions and responsibilities that occur between agents during an interaction. Internal models have three diagrams: reaction frame diagrams, reaction sequence diagrams and reaction pattern diagrams. The reaction frame diagram shows the agents that the focus agent is aware and shows the agents‘ relationships with objects. The reaction sequence diagram shows the typical interaction process of the focus agent and the reaction pattern diagram shows the reactions of the focus agent in the environment. In AORML, the external models are developed first and then the internal models are used to focus on important agents and specify how they work. 1.2.4 Tropos According Giunchiglia, Mylopoulos, and Perini (2003), the Tropos method is an agent-system development method, which starts with an early requirements stage and continues to development of the software system. When identifying the early-stage requirements of a system using Tropos, the modeler must first identify and model the stakeholders in the domain. Once this has been accomplished, the modeler must represent the hard goals of the stakeholders and 10  any dependencies between the actors. Hard goals represent the goals that the agent must achieve and dependencies represent a situation where a stakeholder needs the support or aid of another stakeholder. Once this actor diagram is created, the modeler creates the goal diagram by identifying the plans, soft goals and resources needed to achieve the hard goal. Soft goals represent the ways that the agent wants the goal to be achieved and plans represent the actions that take place to achieve the hard goal. A resource represents a thing in the world with value to a stakeholder. In the actor diagram, plans are decomposed into sub-plans and hard goals are linked to plans, resources, and soft goals using mean-ends links. Means-end links represent which concepts are related to a specific hard goal. Once these concepts have been determined, the modeler establishes what new dependencies are created by the introduction of these plans, resources, etc. 1.2.5 i* Framework The purpose of the i* framework, according to Yu (1993, 1997), is to represent the underlying motivations behind business processes and aid early phase requirements gathering. This is accomplished by focusing on a concept called the intentional actor, which has goals and interacts with the world through the concepts in two models: the strategic dependency model and the strategic rationale model. Yu (1993) discusses that the strategic dependency model represents a specific relationship between the actors in the system; the one between the depender who needs something from the dependee (Yu 1993). The concepts used in the strategic dependency model are: goal, resource, task, and soft goal. A soft goal does not represent an objective of the actor, but instead how the actor wishes to achieve a goal; so a soft goal is always attached to a goal. For example, the actor may have a goal to travel around the world, but its soft goal would be to minimize the costs of travelling the world. Each of these concepts also has their own dependencies. A goal dependency represents a request from the depender to the dependee to achieve an objective. A resource dependency represents the depender's need for an object from the dependee. A task dependency represents the depender's request for a specific action to be taken by the dependee, but not the goal behind the task. And, the soft goal dependency is similar to the goal dependency, but represents the depender's need for a specific condition to be met by the dependee, instead of representing an objective to be achieved.  11  The strategic rationale model represents the underlying reason for the intentional actors' behaviour. Concepts used in the strategic rationale model are: tasks, goals, soft goals, resources, actors, means-end links, and dependencies. In the strategic rationale model, actors are assigned i* concepts (goals, tasks, etc.), which is different from the strategic dependency model where the i* concepts are modeled as not belonging to a particular Actor. The strategic rationale model also uses a new concept called means-end links that represent the intentions of actors by relating i* concepts to each other. For instance, Yu (1993) discusses that if goals, tasks, and resources are related to one another using means-end links, it represents that tasks, which involve certain resources, achieve a particular goal. Means-end links can also represent goal conflicts using contributions indicators which show how a concept helps or hinders a goal or soft goal. With both the strategic dependency model and the strategic rationale model, i* provides a way of representing how actors are related to each other through the dependencies, and the internal behaviour of the agent is represented in explaining the rationale of its actions. 1.2.6 Multiagent Based Integrative Business Modeling Language (MibML) The Multiagent Based Integrative Business modeling Language (MibML) is a modeling language, proposed by Zhang, Kishore, and Ramesh (2007), which is used to represent early requirements for agent systems used in business and aid in the system analysis phase of IS development. A MibML diagram is focused on the role concept. Roles are described using six concepts: goals, information entities, information flows, tasks, privileges, and knowledge. Goals represent objectives of the system that are assigned to a role. Information entities represent structured data that exist in the system, e.g. tables in a database. Information flows characterize the transfer of information. A task represents activities performed by a role and is defined by its inputs, outputs, and methods. Inputs represent information the agent can access, outputs represent the information produced at the end of the task, and the method represents the procedural knowledge used to perform the task. Privileges allow roles to process information by accessing certain information entities and initiate or receive particular information flows. Lastly, knowledge is possessed by roles and contains facts, deduction rules, activity execution structure, and activity execution constraints. Facts are defined as the agent's beliefs about the world, deductive reasoning allows the agent to learn new facts, and the activity execution structure and activity execution constraints refer to how the agent orders and times its tasks.  12  MibML diagrams also represent the external aspects of agents using the interaction concept, which models the ―speech acts‖ between the agents. The authors define speech acts as ―utterances that contain information needed to assert and perform actions‖ (Zhang et al. 2007, p. 10) and consider all interaction between agents to be speech acts. 1.2.7 Evaluation of Agent Modeling Languages We now can determine if these agent modeling languages can represent users' descriptions of their domain by evaluating them based on our criteria. To represent all contextual information in a user‘s narrative we must represent all aspects of the user and his or her environment that describe the actors‘ behaviour. Since we have equated the user with the intelligent agent concept we must ensure that a language used to represent the users' narrative can directly represent all traits of an agent needed to describe its behaviour. To determine these traits we can use the definition of agents provided by Wooldridge (1999), which states the three abilities that an entity must have to be considered an intelligent agent. It must be able to react to its environment, interact socially with other agents and perform goal oriented behaviour. Previously, we stated that the agent must have four components to have these abilities; it must have internal states, internal processes to change internal states, external states, and external process to change external states.  From this discussion, we propose that the agent's traits are: internal states, internal processes, external states, external processes, goal oriented behaviour, reactivity, and social ability. If an agent conceptual modeling language represents these traits then the language should be an appropriate candidate for representing the user's narrative about their work. Table 2 explains and shows each criterion used to determine whether the agent modeling frameworks represent all functions of the agent.  Table 2: Criteria For Evaluating Agent Modeling Frameworks Agent Criteria Definition Examples Functions Thought  Internal State Internal processes  These concepts represent the agent's model of the world. Decision and thinking processes of the agent.  Perceptions, goals and beliefs about the world. Interpreting the environment, forming beliefs, and choosing actions.  13  Table 2: Criteria For Evaluating Agent Modeling Frameworks Agent Criteria Definition Examples Functions Interaction  Thoughtful Action  External State  External processes Social ability  Represents things in the environment that the agent has access to affect it in some way Changes that occur in the environment Interaction between agents  Goal oriented behaviour  Setting objectives and proactively performing actions  Reactivity  Reacting to changes in the environment  Objects in the environment and their states. Actions of the agent and events Communication, indirect interaction and messaging between agents. Enacting plans to achieve a goal. Providing the rationale for why actions are being performed. Changing actions based on changes in the environment. Alternative plans depending on the context of the situation.  Firstly we begin by evaluating the Gaia method, which clearly represents the external processes of the agent through the processing concept in the interaction model, since it represents how the agent changes the environment. Gaia also represents external states through the input and output concepts in the interaction model, which describe the information created and used in the agent's actions and physical changes to the environment, are represented by the role's activities. Internal states are also represented in Gaia through the responsibility concept, which outlines the agent's desired states. The Gaia method can also represent social ability through the interaction model and goal oriented behaviour through the responsibility concept. But since there is no Gaia concept that represents changes in the responsibility concepts, the Gaia method does not represent the internal processes of the agent. Also since there is no representation of the agents‘ decision-making, it cannot represent reactivity. Secondly, the ROADMAP method represents more of the internal and external states of the agent than the Gaia method. The environment model represents external states in more detail than the Gaia method by describing all features of the agent's environment. The knowledge model represents internal states and includes the knowledge components that model which agents know certain facts about the environment based on their roles. Like the Gaia method, ROADMAP also represents social ability using the interaction model and goal oriented behaviour is represented through the responsibility concept. A weakness of the ROADMAP method is its inability to represent the internal processes of the agent. Its knowledge model only represents knowledge artifacts and their assignment to specific roles, not how knowledge is 14  changed. Also, like the Gaia method, it cannot represent reactivity. Thirdly, AORML represents internal states and processes as well as external states and processes. The internal object represents the internal state of the agent‘s beliefs about objects in the world and reaction rules represent an internal process. External states are represented by objects and external processes are represented by action events and non-action events. It represents social ability through the communicative actions and it represents reactivity through the reaction rules. A weakness of the language is that it cannot represent goal oriented behaviour. Fourthly, Tropos is a goal-oriented modeling method, and so in the early phases it focuses on the internal state of the agents which is represented by the goal, soft goal and plan concepts. The Tropos method focuses on goals and therefore is made to represent goal oriented behaviour. Reactivity is only partially represented because it represents alternative plans for achieving a goal through the "Or" concept, but it does not represent how the agent reacts to the environment to choose an alternative plan. Also, interaction between actors is difficult to represent since the only relationship between actors represented in Tropos is through dependencies. It is possible that actors may indirectly communicate with each other but not depend on one another; for instance, a retailer may change their prices in a competitive market that provides information to its competitors, but the retailers do not depend on each other to sell their products. This indirect communication would not be represented in Tropos. The method also does not represent internal processes and fails to represent the external states or processes of the environment in the goal diagram and actor diagram. Fifthly, the i* framework represents the internal and external states of the agent. The goals and soft goals represent some of the internal states of the agent and the goal oriented behaviour of the agent. The resources represent external states and the task concept represents external processes. i* also provides limited representation of reactivity through the means-end links, which represent how tasks and resources are related to the goals of the actor. The weakness in i* are its failure to explicitly represent social ability or the internal processes of the agent. Another weakness in i* is the relation of agents to each other through dependencies rather than communication. Even if we assume that an agent automatically communicates with agents that it depends on, the framework cannot represent agents that communicate with each other even though they are not dependent on each other. So the situation with a retailer signalling its pricing moves to its competitors, as mentioned in the previous discussion about Tropos, cannot be represented using i*. The internal processes cannot be explicitly represented in i* since the 15  means-ends links only implicitly represent the rationale for use of a particular task to solve a particular goal. This failure to illustrate communication also leads to the absence of social actors in the framework, as communication between actors is not represented, only their dependency. MibML represents internal and external states as well as internal and external processes. It represents internal states through the goals, information, and knowledge concepts, and internal processes through deductive rules and activity execution constraints. It also represents goal oriented behaviour through the goal concept. MibML has information input and output concepts, which represent external states; and information flow that represents the external process of passing information from one agent to another; however, due to MibML's information focus it is limited in representing the external view, since physical actions on the environment are not represented. Another weakness with MibML is that it does not fully represent the reactive agent since it can represent how the actors' thinking is affected by changes in the environment but does not represent its actions. Through our analysis of the languages we found that all concepts could fall into the criteria we mentioned previously. In Table 3 we summarise our evaluations of the agent modeling language based on our criteria for representation; internal states, internal processes, external states, external processes, goal oriented behaviour, reactivity, and social ability. For each criteria, the evaluated model is given three ratings; 'Yes', which means that the model represents an example of this criteria; 'No', which means that the model does not have a concept that represents the criteria; and 'Limited', which means that the models have a concept that comes close to representing the criteria but cannot be used as a substitute. Table 3: Evaluation of Agent Modeling Languages Agent Inter- Internal External External Modeling nal processes states processes Framewostates rk  Social ability  Goal Reactoriented ivity behaviour  Gaia  Yes  No  Yes  Yes  Yes  Yes  No  ROADMAP  Yes  No  Yes  Yes  Yes  Yes  No  AORML  Yes  Yes  Yes  Yes  Yes  No  Yes  Tropos  Yes  No  No  No  No  Yes  Limited  i*  Yes  No  Yes  Yes  No  Yes  Limited  MibML  Yes  Yes  Limited  Limited  Yes  Yes  Limited  16  1.2.8 Representing People's Descriptions of the Domain Using Agent Modeling Languages By evaluating the agent conceptual modeling languages we have determined that no one model can represent all aspects of the agent needed to describe its behaviour. One solution to this problem is to combine several models together which will cover all aspects of the agent. An example is the ARKnowD method, proposed by Guizzardi (2007), which combines the Tropos method and AORML language to create an agent-based method for creating knowledge management systems. Another solution is using goal modeling and scenario modeling together to represent the domain. In ARKnowD, the Tropos goal diagram is used to represent the internal aspect of the agent and is linked with AORML diagrams which provide a better specification of the interaction between agents. In this way ARKnowD provides a model of the agent's internal view and the external view which represent goal oriented behaviour, reactivity and social ability of the agents; however, there are some problems with using ARKnowD to represent users' descriptions of their work, and these problems highlight the difficulties in combining methods to more accurately represent actors in the domain. First, to link AORML to the Tropos goal Diagram, ARKnowD turns the Plan concept within the goal diagram into an AORML interaction diagram. Since many plans exist in a goal diagram, this means many AORML diagrams need to be created to represent the domain. This situation is adequate for system development since each plan could be considered a use case for the information system. However, when initially representing the business environment we need more details than the Tropos goal diagram can provide but not as many details as found in multiple AORML interaction diagrams. Another concern is that in ARKnowD the dependency link in the Tropos goal diagrams between agents is represented as an association concept in the translated AORML diagrams. This is a concern because an association is very generic. It could be a direct relationship or an indirect one. Information is lost in the translation and a core concept from one of the models does not exist in the translation. Lastly, the connection between the two diagrams is not completely specified, for instance if a goal in the Tropos goal diagram changes would the AORML diagram translated from the goal diagram also change? If so what specific concepts would change? These questions are not answered in ARKnowD. This is not a problem initially because the goals and plans are identified by the modeler, but if the situation were to change then an entirely new system analysis process would need to occur to determine how the AORML diagrams are changed. From this example we can see three possible problems with combining languages to represent the user's description of their work. The first problem is that there may be too many diagrams or 17  concepts for the new language when these are combined. As pointed out by Alexander and Maiden (2005), these extra concepts and diagrams may overwhelm users with complicated models. The second problem is the occurrence of issues concerning using concepts from one language and linking them to another. These concepts when linked together may not make sense or lose meaning. For instance, the association relation is too general and in the AORML diagrams we would be unaware of actors depending on each other, or simply associating with each other. Lastly, the links between all concepts in the languages would have to be identified and this may be problematic since they were not designed to be used together. So, if the information in one diagram were to change it would be difficult to determine if any of the concepts in the other diagram would also change. It has also been suggested that when trying to represent the social context, goal modeling and scenario modeling can be used to represent the domain. Goal modeling is a term for conceptual modeling that focuses on identifying why something occurs in the environment (Lamsweerde 2001). Based on this description we say that Tropos and i* can be considered to be goal-oriented conceptual modeling techniques, as Tropos focuses primarily on goals and i*‘s Strategic Rationale Diagram is specifically used to identify how goals are achieved in the domain. Scenario modeling, according to the authors, refers to modeling techniques that focus on how an information system will be used in the domain by users. Based on this description we say that techniques, such as use-case modeling and user stories, can be considered to be scenario modeling because they represent how the user interacts with the system. In Liu and Yu 2004 the authors suggest that goal modeling and scenario modeling can be used to represent the use of information systems in a social context. Goal modeling is used to identify the goals of the tasks being performed in the domain that may involve an information system. However, this representation may be too high level to design the system, so scenario modeling must also be used to gain a better understanding of how users interact with information systems in the domain. Liu and Yu 2004 suggest using both techniques simultaneously, so a modeler will identify the goals in the domain as well as how users interact with information systems. The two modeling techniques aid each other when insights from goal modeling are used to further develop scenario models and to add more detail to the goal models. Even though goal and scenario modeling can complement each other and deal with some of the issues that occur when the techniques are used separately, there are still some problems with using current goal modeling and scenario techniques for representing actors in the domain. Firstly, the representation of interaction between actors is still not apparent using these 18  techniques. Goal models focus on goals, not actors, so the models can not represent actors that interact but are not dependent on each other. And secondly scenario modeling techniques, like use-cases and user stories, only focus on the interaction with the system and not necessarily between users. Therefore, using this technique in an environment without an existing system will be difficult. Due to the concerns raised about combining different types of modeling, in this work we have decided to develop a completely new modeling method based on the actor. This organisational actor method will be developed to represent the users' activities in the organisation, their decision-making process while engaged in work, and their impact on the rest of the organisation. To be able to represent these phenomena, the method will have to represent all aspects necessary for describing the agent‘s behaviour. These include the thought aspects: internal states and internal processes, the interaction aspects: external states, external processes, and social ability, and the thoughtful action aspects: goal oriented behaviour and reactivity. The internal states and processes represent what people think. The external states represent the things used in people's work and external processes represent how people perform their work and how that work is integrated with the rest of the organisation. People also interact with each other, so social ability will be represented in the Method. Lastly, we represent how interaction is linked to the thought of the actor through thoughtful action. Goal oriented behaviour models how the goals of the agent lead to it interacting with the environment and reactivity represents how changes in the environment lead to an agent's actions.  1.3. Overview of the Research Method We use a design science approach articulated by Hevner et al (2004) to develop the organisational actor method because it is a research method that is used to develop practical systems, frameworks, or models based on information systems research. Since design science research is used to create useful IT artifacts that contribute to research, we believe the research method is appropriate for the development of the organisational actor method, which must be a system analysis technique that can represent people's descriptions of their work. We will use a theoretical foundation to develop the organisational actor method, as we wish to ensure that the new concepts can be used to represent phenomena in system analysis and is compatible with the agent-based system development process IS research. The organisational actor method will also be tested for practicality, since representing employees‘ descriptions of their work, including their decisions, may make it easier to analyse how 19  organizations deal with crises and surprises (Chen 2006). 1.3.1 Overview of Theoretical Foundations To develop the organisational actor method, we propose using a design process based on four theoretical foundations: 1) As stated by Jones (2003), the theory of affordances is used to describe how actors understand and use causality to make decisions. We use this theory because it describes entities that perform thought, interaction, and thoughtful action, such as agents. However the main reason is that according to Sahin, Cakmak, Dogar, Ugur, and Ucolu (2007), the theory has been used to describe software that represents human behaviour and the behaviour of users.. In our work, we use the theory to identify what features of the actor must be represented by the Method and to define the organisational actor modeling construct. The area of cognitive science involves many fields including psychology, philosophy, artificial intelligence, and neuroscience; Thagard (2008) states that the purpose of this science is to understand the mind and intelligence of human beings. Cognitive science also provides theories to explain human thinking, and the concepts in these theories can be used to represent human intelligence. However, theories that focus on the exact details of human thinking may not be appropriate as the foundation of our work because we seek to develop a more basic model of actor behaviour. In the beginning, the modeling approach should be able to represent how actors (humans, animals, robots, etc.) generally behave, rather than accurately represent how humans think. However, in the future we may use more complex cognitive science theories to refine how we use the method and to aid in understanding the domain in greater detail. The theory of reasoned action was created to help predict human behaviour; however it may not be appropriate for this study. Posited by Ajzen and Fishbein (1973), the theory explains that there are two influences on a person‘s intention to behave a particular way: attitude and subjective norm. Attitude is a concept that represents how favourably a person feels towards a particular behaviour. Subjective norm represents the social pressures on a person to perform or not to perform an action. The theory is not appropriate because the concepts do not discuss how attitudes and subjective norms are formed, or how intentions lead to particular behaviour. The theory assumes that the attitudes and norms of a person are present and then affect behaviour. However it does not explain how changes in the world affect the attitude and norms of the actor, and so has nothing to say about the reactivity of the agent. 20  2) The systems approach that, according to Churchman (1979), is a viewpoint that looks at problems in the world as the problems of an entire system. Therefore, in this approach a system is any entity that has ―a set of parts coordinated to accomplish a set of goals‖ (p. 29). The us of the system approach is appropriate because it explains the workings of any phenomena as a system and makes it possible to analyse the interaction between different parts of the environment as different systems and subsystems. In our work, we use system approach to determine the components of the organisational actor modeling construct and how it interacts with the environment. 3) Ontology, as stated by Wand and Weber (1990), is a branch of philosophy that models the existence of things in the world. Rather than use psychological literature that may describe exactly how humans think, we use ontology in our work because it provides an epistemological foundation and common language for discussing the different functions of a system which mimics human behaviour. In our work, we use ontology to determine the components of the organisational actor modeling construct and how they interact with each other. 4) Theoretical software-agent literature techniques that describes, in abstract terms, the software agent's structure, behaviour, and interaction. We use this literature because we surmise that it can conceptually represent certain aspects of actors to create software that can mimic actor behaviour. In our work, we use the literature to determine whether our research is compatible with the software agent field, since our work could be used in the system analysis phase of agent-systems development. These foundations theoretically ground the design process of building the organisational actor method, which is split into six activities: Identifying the actor's characteristics related to its behaviour, determining the components of the actor, determining organisational actor concepts, determining the relationships between the actor concepts, determining the features of a valid organisational actor model, and determining the correct steps for building an organisational actor model. 1.3.2 Overview of Design Activities In the first design activity, assuming that employees are actors that perform goal-oriented tasks, we use specific works in the theory of affordances as the theoretical foundation to determine the characteristics of a conceptualization that can represent employees in a business. These works are Gibson (1977), Turvey (1992), and Chemero (2003). The product of the activity is an abstract definition of the organisational actor modeling construct, which will be used to 21  determine the features of the organisational actor's behaviour. In the second design activity, we use specific works in the systems approach: Ackoff (1971), Miller (1978), and Churchman (1979). We use these studies to determine the components of the organisational actor modeling construct. The product of the activity is the organisational actor modeling construct, which describes the mechanics of how the organisational actor behaves in the environment. In the third design activity, we use the modeling construct as an input and use the systems approach, specific works in ontology, Bunge (1977, 1979) and Wand & Weber (1990, 1995), and specific works in the conceptual basis of software agents, Wooldridge (1999), Bratman (1987), Newell (1980), and Huhns & Stephens (1999), as theoretical foundations to determine how to describe the behaviour of the organisational actor. The product of the activity is a set of concepts used in conceptual modeling to represent organisational actors. In the fourth design activity, we use the concepts from the third design activity as input and again rely on the systems approach, ontology and software agent literature as theoretical foundations to determine relationships between the concepts. The products of this activity are the Organisational Actor Metamodels, which show how the concepts can represent important aspects of the actor. In the fifth design activity we use the theoretically grounded metamodels as inputs to determine the features of a valid Organisational Actor model. The products of this activity are the integrity checks, which act as a validation tool for organisational actor models that can be used by someone who has no knowledge of what the model represents. The last design activity also uses the metamodels as inputs, but in this activity the metamodels are used to determine the correct steps for building an organisational actor model. The product of this activity is a step-by-step method for creating an organisational actor model, which can be used by analysts to easily translate a user's description of their work into an organisational actor model. A graphical representation of theoretical foundations, design activities and their justifications can be found in Figure 2.  22  Figure 2: Design Process of the Organisational Actor Method  23  1.3.3 Overview of Artifact Testing Along with contributing to and drawing from theoretical foundations, according to Hevner, March, Park, and Ram (2004), a design science study also tests the artifacts designed in the study; however, we will test only the organisational actor concepts and the organisational actor method and will not test our definition of an actor, the organisational actor modeling construct, the organisational actor Metamodels and the integrity checks. These four IT artifacts are not directly tested in this work as they are not directly used by modelers and readers; however, this is not a concern for the design study because these artifacts are indirectly tested through the validation of the organisational actor method and the organisational actor concepts. Our definition of an actor and the organisational actor modeling construct is used to identify the organisational actor concepts. So if the organisational actor concepts do not properly represent actors in the domain it will be due to issues with the other IT artifacts. For example, if we find that organisational actor concepts do not cover all of the aspects of an actor in the domain, the organisational actor modeling construct is missing a component. If the organisational actor modeling construct does not accurately represent our definition of an actor, which means our definition of an actor is incorrect. However, if the organisational actor modeling construct is not an accurate representation of an actor then the definition may be correct and the organisational actor modeling construct needs to be modified so that it can accurately represent our definition of an actor. We can also indirectly test the organisational actor metamodels and the integrity checks by validating the organisational actor method. If the organisational actor method is not effective in producing readable and understandable models then the organisational actor metamodels incorrectly represent a domain. We can make this assertion because the organisational actor method will be developed to create organisational actor models that reflect the relationships between the organisational actor concepts as identified in the organisational actor metamodels, so if there is a problem with the organisational actor method it automatically means there is a problem with the organisational actor metamodels. Also, if the organisational actor metamodels are inaccurate then the integrity checks are inaccurate because the integrity checks reflect the rules stated in the organisational actor metamodels. So, if we find that the organisational actor method creates models that do not accurately represent the internal view of the actor, we can say that the metamodels incorrectly represent the internal view of actors and that the integrity checks pertaining to the internal view of the actor must be changed.  24  So in this study, we will test only two IT artifacts from the organisational actor method; the organisational actor concepts and the organisational actor method. We will test the organisational actor concepts in two ways. Firstly, we determine if nontechnical people use the organisational actor, or analogous, concepts, when describing a work process. This is important, since one of the main reasons for the language is to describe employees' descriptions of their work. Secondly, we test the concepts by creating an organisational actor model of a domain and comparing it to a model of the same domain based on another agent-based modeling language. The models are judged by domain experts, who choose which model better represents the domain. If the domain experts judge the organisational actor diagram to be a better representation than the other model and the concepts are usable and understandable to non-technical users then the use of the concepts to represent the domain is justified. We also test the organisational actor method in two studies. Firstly, we determine if a method is needed to use the organisational actor concepts to represent a domain, since researchers have hypothesized that employees use the actor concept in their description of their work. We must test if modelers actually need guidance in creating these models. In the study, we provide modeling novices and experts with a subset of the organisational actor concepts to represent a domain, and in another group of experts and novices we provide the subset of organisational actor concepts and a method to represent the same domain. If we find that those who use a method create more representative models and have fewer problems during the modeling process than those who do not use a method then we can say that a method is needed for the organisational actor concepts. Secondly, we test if the organisational actor method can be used for knowledge acquisition. Knowledge about a job is the same as someone's description about his / her work. We use a disaster management professional as our subject, since he has acquired knowledge about the job that is not in the job description and has not been recorded. If the method can create a representation of the manager's knowledge that is useful to the manager and the manager's supervisor then the method can correctly gather requirements. We also use the integrity checks to validate and further develop the model. An overview of the studies, their research questions, subjects and results can be found in Table 4.  25  Table 4: Overview of Artifact Test Studies Study Artifact Research question  Type of study  Subjects  Study 1  Organisational actor concepts  Can non-trained individuals use the organisational actor concepts?  A case Nonstudy technical people.  Study 2  Organisational actor concepts  Do the organisational actor concepts better convey the domain than concepts from other agent-based languages?  Expert Domain Evaluation experts of the diagrams that use the concepts  Study 3  Organisational Actor Method  Does a method derived from the theoretical foundations help modelers to more effectively and efficiently build an organisational actor Model?  A study of Modeling model novices creators and Experts  Study 4  Organisational Actor Method  Can the organisational actor method be used to represent an employee's work?  Case study  Domain expert  Results Individuals intuitively used the organisational actor concepts to represent the domain. The organisational actor concepts were judged to represent important details of the agent that the other agent-based language could not. Identified that a method should be used by modeling novices to more effectively build organisational actor models and should be used by experts to more efficiently and effectively build organisational actor models. Captured a disaster management professional's knowledge about how he performs his work and was judged to be useful by the expert and his supervisor.  1.4 Conclusion In this dissertation, we will create the organisational actor method and test if it can be used to efficiently and effectively represent actors in the domain. In Chapter 2 we use the design process to develop the design artifacts of the organisational actor method, in Chapter 3 we test the organisational actor method to ensure that it will be used by practitioners, and in Chapter 4 we summarise our work, explain the findings, and discuss future research.  26  2. The Development of the Organisational Actor Method  2.1 Introduction As discussed in the previous Chapter, the organisational actor method will be created to represent the aspects of the actors needed to describe their behavior in the domain. Specifically, we will need to represent the internal states, internal processes, external states, external processes, goal oriented behaviour, social ability and reactivity of the actor. Current agentmodeling techniques do not represent all these actor traits, so we propose to create a conceptual modeling method that can be used to represent these aspects of the actor. To aid us in the development process of the organisational actor method we will conduct a design science study, in which the researcher creates IT artifacts, based on an academic foundation that can be useful to IT practitioners. For this study, we create six IT artifacts, used to represent actors in the domain. The first artifact is a definition of the actor and actor behaviour that will help us identify which entities in the domain can be represented as actors. The second artifact is the organisational actor modeling construct that will provide an illustration of the actor's structure and processes so that we can specify the details of the actor. The third artifact is the set of organisational actor concepts that will be used in the organisational actor method to represent the actor and its behaviour. The fourth artifact is the set of organisational actor metamodels that will specify how the concepts represent important aspects of the actor. The fifth artifact is the set of organisational actor integrity checks that will provide rules to validate an organisational actor model without using knowledge about the model's domain, and lastly, the organisational actor method will provide step-by-step guidelines for defining, scoping and representing a domain using the organisational actor concepts. We develop these artifacts using six design activities and four theoretical foundations. In this Chapter we will introduce the study's theoretical foundations, conduct its design activities, and present a graphical representation of the organisational actor concepts.  27  2.2 Theoretical Foundations A design science study bases its design process on theoretical foundations. In this study, our design process is informed by four theoretical foundations: ecological psychology, systems approach, ontology, and agent literature. In the remainder of this section we will discuss in detail each of our theoretical foundations. 2.2.1 The Theory of Affordances Gibson (1977) developed the concept of affordances to explain how animals engage in prospective control. Prospective control is a type of action, similar to planning, where the animal must know what actions are available and choose one to achieve a particular goal (Turvey 1992). Gibson (1977) stated that affordances are actions that individuals can conduct in the environment and that individuals may not be aware of their own affordances. A more developed theory of affordances than Gibson's was developed by Turvey (1992), which is based on work conducted by Bunge (1977). According to Turvey's theory, the world is composed of objects which have properties that can be changed. One property, named effectivity, is defined as a ―causal propensity for an animal to effect or bring about a particular action‖ when a particular situation arises. According to Turvey (1992), an affordance is a property of an object that has effectivity as a complement; for instance, the stairs provide the affordance of reaching the second floor of a building if the animal has the effectivity to climb stairs. Chemero (2003) creates another theory of affordances, which is similar to Turvey's but incorporates two main changes. The first change is the definition of an affordance to be from a property of the environment to a combination of a feature in an environment and the ability of an animal. So according to Chemero (2003), affordances cannot exist without the animal or the environment. The second change is the proposition that animals perceive affordances in their environment by relating the situation to a particular type of behaviour. For instance, if someone wanted to walk out of a room then they would relate the situation of the room to the action of leaving the room. This would result in the person perceiving that the door affords him/her the ability to walk out of the room. 2.2.2 Systems Approach According to Churchman 1979, in the systems approach, problems in the world are viewed as problems within a system. A system is defined, by Ackoff (1971), as any entity composed of ―a 28  set of interrelated elements‖ and according to Churchman (1979), a system has: a purpose, an environment, components, resources, and management. The system's purpose is the reason that the system exists. The system's environment affects the system but lies outside of it. The system's resources are ―things the system can change and use to its own advantage‖, the system's components are the ―sets of parts" within the system, and the system's management decides how the system affects its environment. Since we are interested in representing actors, in this study we focus on systems that interact in the environment; these systems are referred to as living systems. According to Miller (1978), all living systems are feedback systems. A feedback system defined by Bertalanffy (1968), is a system that has three elements; a receptor that receives input from some feedback mechanism, a control apparatus that decides how the system should act based on feedback, and an effector which changes the environment. The feedback system is relevant to the study because it reacts to the world and is aware of its environment. This makes it similar to the agent as defined by Wooldridge (1999). Miller (1978) used the feedback system as a template to describe all existing living systems. Specific to our work, he presented a detailed illustration of the system components for processing information, which has seven components: the input transducer, decoder, associator, memory, decider, encoder and output transducer. The input transducer receives information from the environment and the decoder converts the external input for use by the internal components of the system. The associator has the ability to learn and make associations between various signals decoded by the decoder and these decoded signals are put into memory. Sometimes the associator will also use information from memory to make associations. The decider takes information inputs from the associator and memory to determine what to do, and sends these commands to the encoder. These signals are transformed by the encoder to a form that entities in the environment can interact with, and then sent to the output transducer that produces signals as output to the environment. A graphical representation of this can be found in Figure 3.  29  Figure 3: Subsystems for Information Processing (Adapted from Miller 1978)  2.2.3 Ontology: Bunge-Wand-Weber Ontology The area of ontology ―deals with modeling the existence of things in the world‖. An ontology provides concepts which can be used to describe all aspects of a particular domain. The domain of this study is best described using an ontological approach that is an adaptation of Bunge‘s ontology (1977, 1979) as applied to information systems, called the Bunge-Wand-Weber (BWW) ontology. This ontology is appropriate because it provides concepts for defining information system components and processes and includes many of the concepts found in the systems approach. According to the BWW ontology, the world is composed of things which have properties. A collection of a thing's properties is the state of a thing. Things can interact with each other by changing each other's properties. Properties that can be changed by things that do not own those properties are called mutual properties. Properties are perceived as attributes of a thing because people do not recognise the properties of things. A change in a set of attributes, or state, is called an event and it has conditions called laws. If the conditions are not met then the event does not occur.  30  Table 5 outlines the concepts of the BWW ontology, their formal definitions, and symbols that represent the concept. Table 5: BWW Ontology Concepts Ontological Construct  Definition (from Wand & Weber 1995)  Symbol (from Wand & Weber 1995)  Thing  The elementary unit in the BWW ontology. A composite thing may be made up of other things (composite or primitive).  T  Property  A property is modeled via a function that maps the thing to Intrinsic : p(T) some value. A property that is inherently a property of an Mutual: p(T1,T2) individual thing is called an intrinsic property. A property that is meaningful only in the context of two or more things is called a mutual property.  Attribute  An attribute is a human representation of a property of a thing.  Ap  State  The vector of values for all attribute functions of a thing.  s=<A1…An>  Transition Law  The rules governing the changes of state over time.  L: s s  State law  Restricts the values of the property functions of a thing to a subset that is deemed lawful because of natural or human laws.  LT  Event  A change of state of a thing. It is affected via a transformation.  e=<s1,s2>  Internal A mapping from a domain comprising states to a co-domain Transformation comprising states. Lawful Defines which events in a thing are lawful. Transformation Stable State  A state in which a thing, subsystem or system will remain unless forced to change by virtue of the action of a thing in the environment.  L(s)=s  2.2.4 Software Agent Concepts As mentioned in Section 1 we will develop a conceptual modeling method that can be used to represent actors in the domain but also can be used to develop software agents, since agents mimic and represent human actors. So, to ensure that the method is compatible with software agents, we use two types of software agent research from the literature as theoretical foundations for the organisational actor method. The first type describes the software agent's functions. The second type provides theories and frameworks that detail a ―conceptual‖ agent, which is not a piece of software that 31  can be used to explain the software agent's behaviour. To describe the software agent's functions, we investigate a general overview of software agents, presented by Wooldridge (1999), which explains their components and how they work. We also use Huhns and Stephens (1999) that describes how software agents interact with each other and the environment, and Miller's (1978) specification of an intelligent entity, since it provides insight into a software agent's behaviour. To understand the 'conceptual' agent we use work by Newell (1982) that proposes a new ―level‖ of representation in system analysis and design called the knowledge level, and Bratman (1987) that outlines a conceptual framework to explain planning and decision making. Both Newell and Bratman are important to the development of software agents. In Newell, the knowledge level describes an agent that uses knowledge to make decisions, and Bratman (1987) is the foundation of the beliefs-Desire-Intention (BDI) model, which according to Wooldridge (1999), is used to design many software agent systems.  2.3. Design Activities To develop the organisational actor method we follow a design process which has six distinct design activities: 1) identifying the characteristics of actors, 2) determining the components of the organisational actor modeling construct; 3) identifying the organisational actor concepts, 4) determining the relationships between the organisational actor concepts, 5) determining nondomain specific rules to check the validity of an organisational actor conceptual model, and 6) identifying how to create actor conceptual models that accurately represent the domain. The design process is illustrated in Figure 4. Lastly, we will develop a set of symbols to create a graphical representation of the organisational actor concepts and use it to model a scenario.  32  Figure 4: Design Process to Develop the Organisational Actor Method  33  2.3.1 Defining the Organisational Actor Modeling Construct To determine the characteristics of the organisational actor modeling construct, we analyse the theories of affordance put forth by Gibson (1977), Turvey (1992) and Chemero (2003). These theories, according to Sahin et al. (2007), view affordances from three perspectives: the environmental perspective, agent perspective, and observer perspective. The environmental perspective views affordances to be assigned to objects and as features of the environment that are affected by agents. The agent perspective views affordances to be assigned to the agent's abilities and used by the agent in planning and achieving its goals. And lastly, the observer perspective views affordances to be assigned to the entire system of actors and objects. To explain these three perspectives, Sahin et al. (2007) use the example of a robot dog pushing a ball. Using the environmental perspective, we would say that the ball offers a pushability affordance and the ball affords the robot dog to push it. Using the agent perspective, we would say that the robot dog has a push-ability affordance and that the robot-dog decides to use its affordance to push objects when it needs to achieve a goal. And using the observer perspective, we would say that the dog and ball together have a ―push-ability‖ affordance, meaning that the act of the ball being pushed is afforded by the unique ability of the robot-dog and the particular features of the ball. An example in information systems would be an inventory management system being used by a manager to monitor inventory in a warehouse and order supplies when needed. The environmental perspective would state that the system provides the affordance of ordering supplies because it can send the order to customers. The agent perspective would state that the manager has the affordance to order supplies because he or she can make the decision of when to order the supplies based on the level of inventory. The observer perspective would state that together the manager and the inventory management system have the affordance to order supplies, because the manager makes the decision based on the information provided by the system and the supplies are ordered when the systems sends out the order to suppliers. Using the three views of affordances as guidelines, we propose that an actor has to able to perform four activities to proactively interact with its environment. An actor must be able to: 1) affect its environment (agent perspective), 2) decide when to effect its environment (agent perspective), 3) perceive environmental features (environmental perspective) and, 4) perceive its possible actions by forming relationships between its abilities and the environment (observer perspective). 34  These characteristics correspond with the agents functions mentioned in Section 1.2. The thoughts of the actor are achieved through perceiving its environmental features, its interaction with the world is achieved through affecting its environment, and its ability to perform thoughtful actions are achieved by forming relationships between what it can accomplish and the environment, as well as the actor‘s decision about when to affect the environment. 2.3.2 Determining the Components of the Organisational Actor Modeling Construct To determine how the organisational actor modeling construct can represent the characteristics of the actor, we simplify Miller's (1978) illustration of how an informationprocessing system works using the specification of a generic feedback system from Bertalanffy 1968. We propose that the receptor component performs the functions of the input transducer and decoder; the control apparatus performs the functions of the associator, memory, decider, and some functions of the encoder; and the effector performs some functions of the encoder and all of the functions of the output transducer. These comparisons are explained in Table 6; and Figure 5 graphically shows the reconciliation between the two works.  Table 6: Reconciliation of Miller 1978 and Bertalanffy 1968 Feedback Definition Miller Definition (Miller 1978) system (Bertalanffy1968) Component Receptor  ―'sense organ', be it a photoelectric cell, Input Transducer a radar screen, a thermometer, or a sense in organ in the biological meaning.‖ (p.42) Decoder  Notes  ―the sensory subsystem which brings markers bearing information into the systems, changing them to other matterenergy forms suitable for transmission within it‖ (p. 56)  Both the receptor and the input Transducer deal with the sensing of data.  ―the subsystem which alters the code of information input to it through the input transducer or internal transducer into ―private‖  The Decoder is also involved in interpreting Information from  35  Table 6: Reconciliation of Miller 1978 and Bertalanffy 1968 Feedback Definition Miller Definition (Miller 1978) system (Bertalanffy1968) Component  Control Apparatus  Effector  Notes  code that can be used internally by the system‖ (p. 64)  the environment.  ―the subsystem which carries out the first stage of the learning process, forming enduring associations among items of information in the system‖ (p.65)  This component, like the Control Apparatus, manipulates the messages from the environment.  Memory  ―the subsystem which carries out the second stage of the learning process, storing various sorts of information in the system for different time periods.‖ (p. 66)  Once again, this component transforms the incoming information from the environment.  Decider  ―the executive subsystem which receives information inputs from all other subsystems and transmits to them information outputs that control the entire system.‖ (p.67)  Unlike the Control Apparatus, is more than just something that combines messages it decides how to perform actions.  Encoder  ―the subsystems which alters the code of information input to it from other information processing subsystems, from a ―private‖ code used internally by the system into a ―public‖ which can be interpreted by other systems in its environment‖ (p.68)  Has some processes that belong to the Control Apparatus since it manipulates information input.  ―is a center Associator recombining the incoming messages and transmitting them to an effector‖ (p.43)  ―consisting of a machine like an electromotor, a heating coil or solkenoid, or a muscle responding to the incoming message in such a way that there is power output of high Output energy‖ (p.43) Transducer  Since it sends a ―public‖ code message to the other parts of the system the Encoder also performs some actions of the effector.  ―The subsystem which puts out The output markers bearing information from Transducer the system ― (p.69) produces output just like the effector.  36  Figure 5: Reconciliation of Miller 1978 and Bertalanffy1968  Based on our analysis of the feedback system and the information processing system, we propose that the organisational actor modeling construct consists of three components that interact with each other: the receptor, simulator, and effector. The receptor and effector have the same definitions in our work as they do in feedback systems. The simulator is defined as a control apparatus that contains a model of the environment that the organisational actor uses to make decisions. Since it is has these components, the organisational actor modeling construct can represent the actor as defined in Section 2.3.1. The effector gives the organisational actor the ability to affect the environment; the simulator gives the organisational actor the ability to decide when it affects its environment and the ability to relate how its abilities and the environment may lead to a particular consequence in the environment. Lastly, the receptor gives the organisational actor the ability to perceive the environment. 2.3.3 Identifying the Organisational Actor Concepts To identify the organisational actor concepts that can be used to represent the features of the actor, we will use the BWW ontology to link thought, interaction, and thoughtful action. In this design activity we do this by formalizing the link between the environment and the 37  organisational actor modeling construct's components. Secondly, we will analyse the formalisation to identify the concepts that describe how the organisational actor modeling construct interacts with the environment. We begin the formalisation by identifying the entities that are present when actors interact with the environment. Let W be the actor's world or environment, R the actor's receptor, Sim the actor's simulator, E the actor's effector, and let ―→‖ mean ―cause‖. We propose that a change in the ―world‖ can affect a change in the actor's receptor. The receptor may then cause a change in its simulator, which may cause another change in its effector. This in turn, will lead to a change in the world. In the BWW ontology, these changes are called events, and are defined as changes of the state of things. Using symbols from Wand and Weber (2002), a generic event of a thing T would be shown as e(T). For the formalisation of organisational actor interaction we state that: e(W) → e(R) → e(Sim) → e(E) → e(W) The formalisation can be used as follows. Assume an event occurs in W. If a mutual property of W and R changes then R might reach an unstable state that causes it to change. This new change might cause a mutual property of R and Sim to change, which causes a change in the mutual property of Sim and E. Thus, an event in W will be propagated to an event in E via R and Sim. How R, Sim, and E will change States, depends on their Laws. In the BWW ontology for a given thing, a change in a thing's state to another state, or an event, can only occur if it is allowed by the transition law of the thing or more formally: e = <s,s‘> where s‘=L (s) or, briefly: e = <s,L(s)> where e, s, L all relate to the same thing. We can extend this to the formalisation of actor behaviour by specifying how attributes change during the actor's interaction. The set of attributes that change in an event 'e' can be denoted as C(e). According to the BWW ontology, a change will propagate from a thing T1 to a thing T2 if and only if there exists a mutual property p(T1,T2) such that Ap(T1, T2)C(e[T1]). So, an event in a thing can only affect another thing if there is a mutual property between the two things that is involved in the event. Specifically, for the organisational actor modeling construct, the propagation of changes can be formally described as:  38  (1) An event e(W) occurs. (2) For e(W) p(W,R)C(e[W]) and the state of R after e(W) is unstable bringing about an event e(R): e(W) e(R). (3) For e(R) p(R,Sim)C(e[R]) and the state of Sim after e(R) is unstable bringing about an event e(Sim): e(R) e(Sim). (4) For e(Sim) p(Sim,E)C(e[Sim]) and the state of E after e(Sim) is unstable bringing about an event e(E): e(Sim) e(E). (5) For e(E) p(E,W)C(e(E)) bringing about an event e(W): e(E) e(W) This formalisation states that there are mutual properties between; the world and the receptor, the receptor and the simulator, the simulator and the effector, and the effector and the world; so there must be mutual attributes between these pairs. We call these mutual attributes input, beliefs, intentions, and output, respectively. Secondly, the BWW ontology states that there must be events that change these attributes; we call these events: Perceiving, learning, reasoning, and action. Thirdly, based on the characteristics of actors developed in Section 3.1, we posit that the actor's awareness, objective, and abilities are internal properties of the receptor, simulator, and effector and are called: perception, goal, and capability, respectively. The terms used for the organisational actor concepts are terms already used by some of the conceptual agent modeling language discussed in Section 1.2, so the names are not new. However we still present the terms as new because, as stated shown by Arazy and Woo (2002), the definitions of these terms in existing agent conceptual modeling languages have not been formally defined. For instance the concept of resources is defined many different ways in the literature and includes skills of the agent as well as things outside of the agent. Using the precise ontological definition of the agent we can identify that these are two distinct concepts that must be represented separately. In Figure 6, we graphically show how the organisational actor concepts are related to the world, receptor, simulator, and effector. In Table 7 we show the BWW ontological description and the definition of the organisational actor concepts based on the theoretical foundation of agent conceptual modeling.  39  Figure 6: Concepts Linked to the Organisational Actor Modeling Construct In this  An italicized concept in Figure 6 is a process and is directly related to the concept above it. In other words, perceiving changes input, learning changes beliefs, reasoning changes intentions, and actions change output. Table 7: Organisational Actor Concepts and Definitions Organisational Actor Concept  Ontological Definition  Notes  Reference  Input  Attributes of things Miller (1978) Ap(W, R) An attribute of a mutual property of the world in the world that the and the receptor. organisational actor is aware of.  Perceiving  e(W) such that  Ap(W,R) C(e[W) A change in the Attribute which represents a mutual property of the world and the receptor and a following event (Lawful Transformation) in the receptor.  Perception  If something occurs Miller (1978) in the world without the organisational actor perceiving it, it will be impossible for the organisational actor to know about that event. The encoded input Miller (1978) Ap(R) such that sSR, LR(s)≠s and that the ApC(s,LR[s]) organisational actor An attribute which represents an Intrinsic property of the receptor which changes as the receives from the result if certain transformations in the receptor environment. occur.  40  Table 7: Organisational Actor Concepts and Definitions Organisational Actor Concept Belief  Learning  Goal  Ontological Definition  Notes  Reference  The assumptions Bratman (1987) about the world which are based on the actor's observations of the world. The mechanism Miller (1978) LR, e(R) such that Ap(R,Sim) C(e[R]). which makes it A lawful transformation of the receptor which changes a mutual property of the receptor and possible to update the simulator. An simulator. organisational actor can only learn if the change is aligned to the laws of the receptor. If the organisational Newell (1982) s S(Sim) , LSim(s)=s actor is agitated, the A stable state of the simulator. simulator will try to find an intention which will lead to the goal scenario. Ap(R,Sim) An attribute which represents a mutual property between the receptor and simulator.  Intention  Ap(Sim,E) A mutual property between the simulator and effector.  It is possible that the Bratman organisational actor (1987) intends to perform an action but may not be able to do so.  Reasoning  Lsim, e(Sim) such that  Ap(Sim,E) C(e[Sim]). A lawful transformation of the simulator which changes a mutual property of the simulator and effector.  Specific conditions Miller (1978) need to hold before the organisational actor will reason to intend to perform an action.  Capability  Ap(E) such that sSE, LE(s)≠s and ApC(s,LE[s]) An attribute which represents an intrinsic property of the effector which changes as the result of certain events in the effector.  When the Newell (1982) organisational actor interacts with its environment, it must use its capabilities.  Output  Ap(E, W) An attribute of the mutual property between the effector and the world.  Represents attributes Miller (1978) of things that are manipulated in the world by the effector. Only Attributes that are directly changed by the organisational actor are output.  41  Table 7: Organisational Actor Concepts and Definitions Organisational Actor Concept Action  Ontological Definition LE, e(E) such that Ap(E,W) C(e[E]). A lawful transformation of the effector which changes a mutual property of the effector and the world.  Notes  Reference  Changes in the Bratman world created by the (1987) organisational actor. It is through these actions that the behaviour of the organisational actor is seen.  An important distinction should be made about the belief concept: beliefs represent the mental-model of the world that is constructed by the actor. As they represents the connections between the receptor and the simulator, beliefs are directly affected by changes in the perceptions of the actor and act as interpretations or assumptions about the world based on these interpretations. Another way of naming our belief concept would be as ―interpreted inputs‖. Even though there are beliefs that are not changed by factors ―outside‖ of the actor, they are still changed by the perceptions of the actor since perceptions represent things in the domain that are part of an agent‘s awareness, including itself. If the perceptions of the actor do not change then, by definition, its beliefs cannot change. Rather than incorporate beliefs directly into learning and reasoning, we model them separately so that model readers are aware of the actors‘ beliefs. By modeling them separately it is easier to identify whether we are missing learning criteria and how the belief is being used by the actor. For instance, if we were to model the reasoning and separate out beliefs of the waiter we might write a rule stating that ―The waiter will pick up food when it realizes that it is finished‖ with the belief being ―status of food‖ then we can ask how the status of the food belief is updated or changed. Without separating out the belief we may not realize that we need to determine how the waiter learns about the food. Since the organisational actor concepts are based on the characteristics of the organisational actor and a formalisation of its behaviour, we posit that these are the only concepts needed to represent all features of an actor that interacts with its environment. 2.3.4 Determining the Relationships Between the Organisational Actor Concepts To determine how to use the concepts to represent actors in the domain, we first identify different aspects of the actor that must be represented by the concepts. Secondly, we use the 42  BWW ontological definition of the concepts and the formal description of actor behaviour developed in Section 2.2.3 to identify the relationships between the concepts for each aspect of the actor. Thirdly, we use the theoretical foundation of software agents to verify that the relationships between the concepts so that the concepts can be used to describe software agents and understand how software agents represent human actors. To identify the aspects of actors to be modeled by the organisational actor method, we look at the perspectives used in general system analysis, which according to Olle et al. (1991) are the data, process, and behaviour oriented perspectives. Data-oriented models show the data in an information system and their relationships, and process-oriented models represent the activities of the system, and behaviour-oriented models outline transactions between entities. Similarly, for the organisational actor concepts we will develop: a structural metamodel that describes the composition of the organisational actor and its environment, a dynamic metamodel that describes the behaviour of the organisational actor, and the interaction metamodel that describes how organisational actors interact with each other and the environment. Before we determine their interrelationships, it should be stated that there are some concepts that will not be discussed in the analysis. We will not be discussing the input and perceiving concepts, since we assume that organisational actors accurately perceive the world. Assumption 1: Actors always correctly interpret changes in the world when they are perceived. In the artificial intelligence research field, representing the perceiving process is important since it is not simple to develop mappings between the input received by the software agent and the perceptions of the agent. However, because in our study we are representing the description of work in an organisation, the information gathered from individuals are the perceptions of the input in their environment rather than the actual change in the environment, so we must treat these perceptions as the same as the input unless we found contradictions between many different actors in the domain. If this does occur we could determine that the perception/input exists, but the beliefs about the perception/input will be different for other actors. We refer to these perfectly formed perceptions as perceptions/inputs. Below we will outline the three metamodels showing how the organisational actor concepts can represent the actor in the domain.  43  2.3.4.1 Structural Metamodel In the structural metamodel we show the attributes of organisational actors and its environment as well as the events that are related to the environment. The metamodel does not show how these attributes and events are related to each other. To develop a structural metamodel of organisational actors, we must first understand the environment in which the actor is situated. The BWW ontology states that the environment is composed of things and that these things have attributes. We refer to things as entities and attributes as states. We propose that there are two kinds of entities: dynamic entities, which have attributes called capabilities; and perform actions which change the states of entities; and static entities, which do not have capabilities and cannot perform actions. The difference between dynamic entities and static entities is similar to the difference between active objects and passive objects in object-oriented design. Active objects "exhibit some behaviour without being operated upon by another object" (Booch 1994, p. 51) but a passive object "can only undergo a state change when explicitly acted upon" (Booch 1994, p. 51). If a dynamic entity is similar to an active object then the dynamic entity must be able to take actions, produce output, and use its capabilities and resources to perform actions. However, we cannot say that organisational actors are like active objects because active objects are not capable of "flexible autonomous behaviour" (Wooldridge 1999, p. 35). Instead, we propose that the organisational actor is a type of dynamic entity which is capable of other activities. We define an activity as an event that is caused by an entity. A dynamic entity can only cause actions to occur, which are changes in the environment outside of the dynamic entity because it has no thoughts. However, the organisational actor has thoughts and can perform thoughtful action and therefore can perform other activities, namely learning and reasoning. Organisational actors also have specialized states that dynamic entities do not have which are related to thought and thoughtful action: perceptions/inputs, beliefs, intentions, and, goals. We also identified the events related to the organisational actor and its environment. As mentioned previously, events related to the organisational actor and its environment are called activities, and have specializations: learning, reasoning, and action. Since these activities are lawful events, there are transition laws that the event cannot violate. In our work, these transition laws are called rules. Table 8 presents and verifies the interrelationships implied by these explanations, and Figure 7 shows the relationships graphically.  44  Table 8: Structural Relationship Between Organisational Actor Concepts Statement  Verified By  Dynamic Entity has Capability Dynamic Entity can perform Actions.  ―An action can actually be taken only if it is physically possible‖ Newell 1982 (p. 102). ―Objects are able... to perform actions‖ Wooldridge (1999, p. 34)  Dynamic Entity has Output  ―Control or rates of outputs of various sorts of matter-energy... is exerted by many types of living systems at all levels.‖ Miller (1978, p. 75).  Organisational actor has perception/input.  ―An agent's decision function [is separated] into perception and action subsystems‖ Wooldridge (1999, p. 38)  Organisational actor has Goal.  ―Agent has general goals... the concept of a goal [includes] goal preferences, that is, specific preferences for one state over another‖ Newell (1982, p. 103)  Organisational actor has Intention  ―Much of our understanding of ourselves and others is rooted in a commonsense psychological framework, one that sees intention as central. Within this framework we use the notion of intention to characterize both people's actions and their mind‖ Bratman (1987, p. 1).  Organisational actor has Belief.  ―Internal associations between inputs and outputs are built by storing cues‖ Miller (1978, p. 495)  Organisational actor performs Activity  ―An agent can be viewed as a function which maps sequences of environment states to actions‖ Wooldridge (1999, p. 37)  Activities have Rules.  ―A function is a correspondence between two variables, x and y such that for each value of x there is a definite value of y‖ Miller (1978, p. 16). The quote tells us that we can predict when actions occur (changes in state) since these changes have rules.  45  Static Entity  Entity  Dynamic Entity  Capability  has  Output  has  has  can perform  Intentions  Organisational Actor  Goal  has  Action Perception/ Input  has  performs  Belief  has  Rules  Activity  has  Learning  Relationship  Thing  Attribute  Event  Reasoning Transition Law  Direction of Relationship  Specialisation  Figure 7: Structural Metamodel of the Organisational Actor  2.3.4.2 Dynamic Metamodel To develop a dynamic metamodel of the organisational actor, we analyse the formalism mentioned in Section 2..3: e(W) → e(R) → e(Sim) → e(E) → e(W). We do this by using the BWW ontology to determine the relationships between organisational actor concepts that are attributes and events. According to the BWW ontology, all events change attributes but events occur because of unstable states. Therefore, in the organisational actor modeling construct, an event changes an intrinsic attribute in one component (receptor, simulator, or effector) of the organisational actor that leads to an unstable state in another component. The result of this event is another event in 46  the other component that changes a mutual property between this component and the first component. We call this sequence of events an event chain. For each event chain in the formalism there is an attribute that is changed (an output attribute) and an attribute that triggers the event chain (an input attribute). As mentioned, we assume that the actor's perspective is perfect and so do not analyse the input or perceiving concepts. Since we do not use the concepts, rather than analysing how the receptor is changed by the world, we assume that an actor's behaviour begins with a change in its receptor.. Firstly, we begin by analysing the formalism: e(R) → e(Sim). The perception/input is the input attribute of this event chain because it is an attribute of the receptor, while the belief is the output attribute because it is a mutual attribute between the receptor and simulator. The event chain itself is what we call learning in Section 2.3.3. Secondly, for the formalism e(Sim) → e(E), we can determine that the goals will be the input attributes of this event chain, since goals are the only attributes that belong exclusively to the simulator. The output variable for this event chain is the intention of the organisational actor, since intentions represent mutual properties between the simulator and effector. We call this event reasoning. Lastly, for the transition e(E) → e(W), there is only one effector attribute, so the capability is the input variable for this event chain. The output variable is the output since it is a mutual property between the world and the effector. This event is referred to as an action. We further analyse the event chains to determine how they affect each other. We first begin with the event chains: e(R) → e(Sim) and e(Sim) → e(E). The e(R) → e(Sim) event chain has belief as its mutual attribute. A change in this attribute leads to a change in the simulator, which leads to the e(Sim) → e(E) event chain, which we call reasoning. So because the belief led to the e(Sim) → e(E) event chain, we propose that belief is an input attribute for reasoning. Secondly, the e(Sim) → e(E) and e(E) → e(W) event chains are analysed. The e(Sim) → e(E) event chain has intention as its mutual attribute. A change in this attribute leads to a change in the effector, which leads to the e(E) → e(W) event chain, which we call action; therefore we propose that intention is an input attribute for action. Also, beliefs are part of the learning process because Miller (1978) states that prior facts about the world can influence the creation of new facts discerned about the world by the intelligent system. This leads to a feedback loop where the perceptions/inputs change the beliefs of the organisational actor, and those beliefs may change other beliefs of the organisational actor until it has a belief which leads to an intention to perform an action. 47  Since beliefs are used in learning as well as reasoning, we decide they should be identified in the model so that individuals are aware how beliefs are used in the learning and the reasoning of the actor. Without separating the concept it would be difficult to make these distinctions. These relationships, and the literature verifying them, are summarized in Table 9 and are shown graphically in Figure 8.  Table 9: Organisational Actor Concepts in Relation to Actor Behaviour Statement  References  Our Interpretation  Perceptions/input used by Learning criteria.  ―The chief variables in the associating process concern the number, and sort of, repetitions of the information inputs‖ Miller 1978 (p. 407)  We refer to the ―associating process‖ as learning and ―information inputs‖ as perception/input.  Learning criteria changes Beliefs.  ―[the associator] carries out the first stage of the learning process, forming] enduring associations among items of information in the organism‖ Miller 1978 (p. 407)  We refer to ―associations‖ as beliefs.  Beliefs used by Learning criteria.  ―stored information concerning previous experience with the same or similar inputs may be associated with an input, creating a pattern of associations which can be quite complex‖ Miller 1978 (p. 410)  Changes in beliefs can change other beliefs of the organisational actor.  Goals used by Reasoning rules.  ―Our desires… give us reasons for actions‖, ―our interest is in By incorporating determining what sort of action is recommended by the agent‘s the goal we can relevant desire-belief reasons‖ Bratman 1987 (pp. 24 and 47) select the correct action.  Reasoning rules use Beliefs.  ―The background framework against which practical reasoning Reasoning rules use and planning typically includes not only prior intentions and assumptions (i.e. plans but also flat-out beliefs‖ Bratman 1987 (p. 36) beliefs) about the outcome of actions to choose intentions.  Reasoning rules ―an overall program which determines what alternatives to changes Intention. select in each single choice of the sequence. For instance in working on a mathematical problem, an algorithm which is a rule for solving all problems of a certain kind‖ Miller 1978 (p. 433)  Intention can direct Action.  These rules are conditional statements of what the organisational actor wants to do based on beliefs and its goal.  ―Plans as I shall understand them are mental states involving We call ―plans‖, an appropriate sort of commitment to action‖ Bratman 1987 (p. intentions. 29)  48  Table 9: Organisational Actor Concepts in Relation to Actor Behaviour Statement  References  Our Interpretation  Capability is used in Actions  ―All adjustment processes have their costs, in energy of nonliving or living systems" Miller 1978 (p. 41)  Action changes Output  ―[Behaviour] is a function which takes the current state of the Anything in the environment and an action (performed by the agent), and maps environment that them to a set of environment states‖ Wooldridge 1999 (p. 37) the agent changes the state of is considered to be its output  Organisational actors must use capabilities for actions to occur.  Figure 8: Dynamic Metamodel of the Organisational Actor  2.3.4.3 Interaction Metamodel To develop an interaction metamodel of organisational actors, we use the BWW ontology and the information from the previous metamodels to analyze the organisational actor and the environment. 49  According to the structural metamodel, the environment has dynamic entities that have capabilities and perform actions. However, for the interaction metamodel, we state that dynamic entities that start actions are called initiators and that the actions of initiators causes changes in the state of other entities which we call recipients. We can use the BWW ontology to determine how initiators and recipients interact. According to the BWW ontology, for entities to interact with each other there must be a mutual attribute between them, so there is a mutual attribute between the initiator and the recipient. From the initiator's perspective this is its output, which also must be part of the state of the recipient. When the recipient is an organisational actor we refer to it as the receiving actor, and from its perspective the attribute being changed by the initiator is its perceptions/inputs, which are also a specialization of states. Table 10 shows the relationships implied by the discussion and and the supporting literature, while Figure 9 shows a graphical representation of the relationships. Table 10: Relationship Between Organisational Actor Concepts for Representing Interactions Statement  References  Notes  Initiator performs Actions.  ―[A]n agent is composed as a set of actions‖ Newell 1982 (p. 100)  Newell states that only agents can be initiators but we state that all dynamic entities can be initiators.  Action produces Output.  ―[Behaviour] is a function which takes the current state of the environment and an action (performed by the agent), and maps them to a set of environment states‖ Wooldridge 1999 (p. 37)  We refer to environment states as states.  Entity has States.  From Structural Metamodel  By changing the entities' states via output the initiator can interact with the environment.  Receiving actor has ―Every agent, active or passive, must have the Perception/input. ability to accept information‖ Huhns & Stephens 1999 (p. 85)  From the structural metamodel we know that perceptions/inputs are reflections of external states.  50  Figure 9: Interaction Metamodel of the Organisational Actor  2.3.4.4 Conclusion The organisational actor metamodels define how the organisational actor concepts can be used to represent the important aspects of the actor. Currently, we are unaware of a more precise definition of modeling concepts which represent the structure, behaviour, and interaction of actors in a domain. The metamodels also show how the concepts can represent both the internal view as well as external view of the actor. This means that the organisational actor concepts can represent an individual involved in organisational work, how they think about that work, and how their work impacts the business environment. 2.3.5 Determining Rules to Validate Organisational Actor Models The integrity checks are supposed to be a non-domain specific way to ensure that an organisational actor model is valid.  51  To develop these integrity checks, we analyse the dynamic metamodel by identifying the input and output attributes of the organisational actor's activities: learning, reasoning, and action. These descriptions will inform us about the proper use of organisational actor concepts when representing these behavioural processes. We can use these descriptions to create rules that determine if a concept is missing from an organisational actor model, which we call completeness checks, and rules which determine if an organisational actor concept is irrelevant and should be removed from the model, called minimality checks. When determining the completeness checks we identify concepts that are used by learning, reasoning, and actions but also those concepts which are changed by these Activities. For learning, the dynamic metamodel states that learning changes beliefs and that beliefs and perceptions/inputs are used in learning, so only the actor's perceptions/inputs and beliefs should be used in its learning criteria and only beliefs should be changed by learning. In the case of reasoning, the dynamic metamodel states that the intentions are changed by reasoning and the that goals and beliefs are used in reasoning; therefore, only the actor's beliefs and goals should be used in the reasoning rules and intentions should only be changed by reasoning. Lastly, for actions the dynamic metamodel states that to produce output and use capabilities, therefore, only capabilities should be used to perform actions, and output should only be produced by actions. The dynamic metamodel also shows that the constraints on the activity is reciprocal, meaning that the Activities can only change the concepts shown in the metamodel. So, learning criteria can only change beliefs, reasoning rules can only change intentions and actions can only change output. When determining minimality checks we determine the organisational actor concepts that should not be present in an organisational actor model because they are irrelevant. A concept would be irrelevant if it was not used by, or produced by, the learning, reasoning, and/or, actions performed by an organisational actor in the model. It would also be irrelevant if a concept representing learning, reasoning, and/or, actions did not change an attribute of the organisational actor. Again, we analyse the dynamic metamodel for attributes that are used by the organisational actor's activities (learning, reasoning, and/or, actions) and those changed by activities. We propose that we must have rules to state if an organisational actor's attribute is relevant and should be represented and if an activity is relevant and should be included in the model.  52  We can use the dynamic metamodel to determine these rules. Perceptions/input and beliefs are used in learning criteria and learning criteria changes beliefs, goals and beliefs are used in reasoning rules and reasoning rules changes intentions, and capabilities are used in actions which are directed by intentions and produce output. So, there should be: no perception/input that is not used in learning, no intention that is not changed by reasoning and does not direct actions, no capability that is not used in actions, and no intention that does not direct actions. We can also see from the dynamic metamodel that there should be no belief that is not used in reasoning and/or learning AND changed by learning but, for modeling purposes, we make a slight change to the rules. From analysing the agent conceptual modeling languages we found that actors may use knowledge, what we call beliefs, in their interpretation of the world or in deciding to perform an action, but how they acquired the knowledge is not represented since it may be outside the scope of the model. This means that beliefs in an organisational actor model may not have a corresponding learning criterion, even though technically the beliefs must have been formed by learning at some time. Therefore we state that a belief has to have been used in reasoning and/or learning to be modeled but does not have to be changed by learning to be in the model. We can also state that only activities that change their correct attributes should be included. So, since learning changes beliefs, reasoning changes intentions and actions change outputs, we state that only actions that produce output, reasoning that changes intentions, and learning that changes beliefs should be represented in the model. The list of integrity checks developed in the previous paragraphs, and their sources in the dynamic metamodel, can be found in Table 11.  53  Table 11: Integrity Checks Check  Dynamic metamodel Statement  Check Type  Notes  Only the actor's beliefs and goals should be used Reasoning Rules change in the reasoning rules and intentions should Intentions, Reasoning only be changed by reasoning. Rules use Beliefs, Goals are used in Reasoning Rules. Only the actor's perceptions/input and beliefs should be used in learning criteria and only beliefs should be changed by learning.  Completeness Each of the checks behavioura l processes of the organisatio nal actor: Perceptions/Input used by reasoning, Learning Criteria, Beliefs learning used by Learning and actions Criteria, Learning Criteria changes Beliefs  Only capabilities should be used to perform actions and output should only be produced by actions.  Capabilities are used in Actions, Actions change Output  Only reasoning rules that changes intentions should be modeled.  Reasoning Rules change Intentions  Only learning criteria that changes beliefs should be modeled.  Learning Criteria changes Beliefs  Only actions that produce output should be modeled.  Actions produce Output  There should be no perception/input that is not part of a learning criterion.  Perceptions/Input used by Minimality Learning Criteria. checks  There should be no belief that is not used in the reasoning rules and / or the learning criteria.  Beliefs used by Learning Criteria, Reasoning rules use Beliefs  There should be no capability that is not used in Capabilities are used in an action. Actions There should be no intention that is not changed Intentions can direct by reasoning and does not direct actions. Actions Goals should be used by at least one reasoning rule.  Goal used by Reasoning Rule  Organisati onal actor concepts should only be included that are used in the model. Of course it is possible that the organisatio nal actor has more perception s/inputs, beliefs, etc., but they would lie outside the domain of the model.  54  As can be seen in Table 11, when representing the domain we assume that any change in the world that the actor is aware of will eventually lead to an action. Even if the conditions modeled in the diagram never occur, the model should show the actor‘s reaction in those circumstances. For example, when modeling the actions of a firefighter we would state that if the firefighter saw that someone needed to be rescued from the top floor of the building then he/she would have the intention of saving the person by climbing a ladder. If, in the actual situation, no ladder is present then the action would not take place but the model would still tell the reader what would have happened if the ladder was present. It is also possible that the actor in the domain perceives things that it will not act upon, but we propose that these perceptions are irrelevant when representing the domain since these perceptions cannot be connected to the actor‘s behaviour. For example, the firefighter might see that there is a pawn shop, a grocery and a shoe store on fire but if this information does not eventually lead the firefighter to make a choice about which building to save, or any other action, then it would not be modelled. This leads to our second assumption: Assumption 2: All concepts that model the internal view of the actor must eventually lead to the actor’s actions. Since the rules can be used to determine what is missing from the model and what should be taken from the model, we propose that the integrity checks can be used to determine the validity of an organisational actor model. 2.3.6 Determining a Process for Developing Organisational Actor Models To develop a step-by-step method for creating an organisational actor model we first review the organisational actor metamodels to determine what parts of a domain need to be modelled in an organisational actor model. We then analyse the details of the organisational actor metamodels to determine each step of the method and the order in which the steps occur. Also, throughout the design activity we use the process of customers ordering food in a restaurant as an example to illustrate the modeling process. By reviewing the organisational actor metamodels, we propose four distinct modeling tasks that analysts must perform in order to use organisational actor concepts to represent the domain: 1) define the scope of the model, 2) identify actors, 3) represent actor's behavioural processes, and 4) represent interactions.  55  These tasks should be supported by the organisational actor method, because they ensure that the model will be relevant to model readers and that the modeler captures the relevant details about the actors in the domain. When the modeler defines the scope of the model and identifies the actors that he or she will represent, the modeler is laying the foundations of what the model will capture. If the modeler chooses the wrong scope, or models the wrong actors, the model will not be useful to a model reader. When representing the behavioural processes and interactions of the actors, the modeler is representing the internal and external view of the actor. These views need to be represented to accurately capture the relevant information about actors in a domain. Below we provide a brief overview of each of the tasks and show how steps in the organisational actor method help perform each of the tasks: 1) We define the scope by identifying parts of the environment that are relevant to the modeler and/or potential readers of the model. The model's users will want to have an accurate and useful representation of the environment, which according to the interaction metamodel includes many different entities. To define which entities in the domain should be modeled we suggest defining at least one stakeholder in the domain. As is in scenario-based engineering, as stated by Alexander and Maiden (2004), a stakeholder is defined as someone who has an interest in the 'System', which in this case means an actor that has an interest in the domain. The scope of the domain can be identified by using the goal of the stakeholder. For example if we use the restaurant case as an example, our stakeholder could be the customer or the owner. If the owner were the stakeholder then the business partners might be included in the model because they provide money and support for the restaurant which is important to the goal of the owner; however it does not make sense for the partners to be part of the model if the customer is the stakeholder because the partners do not affect the quality of customer service. But sometimes it does not matter which stakeholder you choose. For instance, the kitchen would be included in the model if either of the actors were stakeholders because the kitchen affects the customer's goal and the owner's goal; food that the customer eats is made by the kitchen and ingredients that the owner pays for are used by the kitchen. 2) We identify actors by determining how actors are different from other entity types in the domain. This structural metamodel shows that the organisational actor is different from the static entities and dynamic entities, since the concepts of beliefs, intentions, goals, learning, and reasoning are unique to actors and are not shared by other types of dynamic entities. However, out of these concepts, we propose that the analyst only focus on learning and reasoning, because according to the dynamic metamodel, learning and reasoning concepts change or use the 56  perception, belief, goal and intention concepts. From the structural metamodel we can see that the organisational actor can perform any activity, but the dynamic entity can only perform actions and static entities cannot perform any type of activity. Therefore we state that if an entity can learn or reason, and those abilities are relevant to the conceptual model, then the entity should be modeled as an actor. For example, in a restaurant the waiter, kitchen staff, and customer can be modeled as actors. 3) We represent the behavioural processes of the actor by analysing the dynamic metamodel, which highlights how the organisational actor concepts represent an actor's behaviour. As mentioned previously, there are two types of actor behaviour, internal and external, and the organisational actor concepts connect both types of behaviours. We suggest that the modeler can begin representing either the external or internal behaviour of the actor since they are connected. However the modeler must determine two concepts first, the intentions and the goals of the actor; we suggest that the choice of a stakeholder should help define the goals of other actors in the model. This limits the scope of the domain but also ensures that the behaviour being represented is important to the model user. For example, from the perspective of a customer, the kitchen's job is to get high quality food to the customer on time. For the owner, the kitchen's objective is to produce the most food for the lowest cost, this means that when modeling the kitchen's goal from the owner's perspective it is important to cut costs and order adequate quality food. This goal can then be used to determine the details of the actor's behaviour based on what types of actions it will perform to what types of objects it is aware of in the environment. Once the goal of the actor has been determined, the intentions of the Actor can be derived because intentions are defined as what the Actor wants to do to achieve its goals. Once the intentions have been determined then the modeler can determine the rest of the organisational actor concepts that represent either internal or external behaviour. 4) We represent actor interaction by analysing the interaction metamodel, which states there are static entities and dynamic entities that actors interact with. However, we propose that since we are using an actor-focused conceptual modeling, that the non-actor entities should only be represented when their attributes are either changed or used by the actor. Therefore, if attributes of non-actor entities are used by or changed by the organisational actors then those non-actor entities should be modeled. For example, the food ordered by a customer in a restaurant would be an important non-actor entity that is represented in the model because the customer wants the food; the kitchen has to make the food; and the waiter has to deliver the food.  57  By analysing the details of the structural, dynamic and interaction metamodels we develop the step-by-step method which will guide the modeler in translating the domain into a full organisational actor conceptual model. The list of steps in the method and the source, including the organisational actor metamodels, used to derive the steps can be found in Table 12. In the rest of this section we will provide more details of how the steps were created and use the method in a restaurant example to illustrate the use of the use of the method. Table 12: Actions to Model a Domain Using the Organisational Actor Method Step  Derived From  1) Identify the stakeholder(s).  Alexander and Maiden (2004)  2) Identify goals of stakeholders and choose appropriate stakeholder(s) for the model.  Structural metamodel: Organisational actors have goals  3) Identify actors that impact the goals of the Structural metamodel: Organisational actors perform stakeholder(s) and include them in the model. activities. Interaction metamodel: Actions affect perceptions/input, initiator performs actions 4) Choose an actor. 5) Identify the actors' goals and determine those that have an impact on the goal of the stakeholder(s).  Structural metamodel: Organisational actors have goals  6) Based on the goals of the actor, determine the intentions of the actor that are part of the domain.  Dynamic metamodel: Intentions direct actions  7) Determine the circumstances under which the intentions will be enacted.  Dynamic metamodel: Beliefs are used in reasoning rules, intentions are changed by reasoning rules  8) Identify beliefs from circumstances and determine reasoning rules for intentions.  Dynamic metamodel: Beliefs are used in reasoning rules  9) Determine how beliefs change, and Identify Dynamic metamodel: Perceptions/inputs are used in perceptions/input or beliefs that may be learning criteria, beliefs are used in learning criteria needed to achieve this and model only "complex" learning. 10) Determine the tasks (actions) needed to carry out intentions.  Dynamic metamodel: Intentions direct Actions  11) Determine the output of the actions.  Dynamic metamodel: Actions produce Output  12) Determine the capabilities needed to perform the task (action).  Dynamic metamodel: Capabilities are used in Actions  13) Determine the non-actor dynamic entities that indirectly interact with the actor.  Interaction metamodel: Initiators are a subclass of Dynamic Entities, Initiators perform Actions, Actions change States, Perceptions/Input is a subclass of State, Recipient Actor has Perceptions/Inputs./  58  The development of the organisational actor method begins with defining the scope of the model, which involves identifying stakeholders of the model. A stakeholder is an actor that is not part of the business process. An actor is also considered to be a stakeholder when it provides important input to the business process and/or is an important user of the process's output. This leads to the first step: Step 1 Identify the stakeholders. An example of this step is that in a restaurant, many people have a goal that can be fulfilled by the restaurant's business processes or trigger events in a restaurant (the casual customer, the owner, the health inspector, food critic, etc). Each of these people could be a stakeholder for the restaurant. If there are multiple stakeholders for a particular business process then the modeler may want to choose only one of them. One way to begin evaluating the stakeholders is to determine if there are differences between them, which can be determined by identifying the stakeholder's goals. The goal of the stakeholder is used to determine the scope of the model; if stakeholders have similar goals then picking either one will make no difference to the model. If the stakeholders have different goals, it is left to the modeler's discretion which stakeholder should be included. This leads to second step: Step 2. Identify goals of stakeholders and use the goals to choose appropriate stakeholders for the model. For an example of this step, let us assume in Step 1 we identified the owner of the restaurant and the health inspector as possible stakeholders for the model. In Step 2, we decide whether we will include the owner, health inspector, or both as stakeholders for the restaurant model. Each stakeholder has very different goals, so the scope of the model can change depending on which one is included in the model. The continuation of business is the owner's main goal but the health inspector does not care about the business. So in Step 2, the modeler must decide which stakeholder best defines the scope of the domain for his/her purposes. The situation is not the same if we have to choose between the food critic and the casual diner, because these stakeholders have similar goals. Both stakeholders want to eat a good meal and receive good service. In this case both stakeholders can be included in the model and it does not make a difference to the scope of the model. By choosing our stakeholder we can now determine the actors in the model. An actor should be included in the model if there is an interaction between the actor and the stakeholder(s). According to the interaction metamodel, if the stakeholder has an effect on the perceptions/inputs of an actor or if the actor has an effect on what is relevant to the stakeholder's goal then stakeholder and the actor directly interact with each other. Also, we state that if the stakeholder and actor indirectly act with each other then the actor should be included. This means that if the actor's actions affect a non-actor entity relevant to the stakeholder's goal, or if 59  the stakeholder affects a non-actor entity that is the perception/input for the stakeholder, then the actor should be included in the model. This leads to the third step: Step 3. Identify actors that impact the goals of the stakeholder(s) and include them in the model. An example of this step is that if we choose the customer as a  stakeholder for the restaurant model then the waiter, hostess, and kitchen would be included in the model. The customer directly interacts with the waiter (the waiter greets the customer and brings food) and the hostess (who greets the customer and provides a table). The customer also indirectly interacts with the kitchen, since the kitchen prepares the food, which is important to the customer. As seen in the example, actors in the domain may be people or groups of people. An actor can represent a group only when the organisational actor concepts for the individuals in the group are the same, or if it is possible to represent collective organisational actor concepts. For instance, the kitchen is made up of many people performing many acts but their collective effort is creating food. Once the actors have been identified we must choose which actor we will begin to model. The choice is up to the modeler, since the organisational actor method provides no specific guideline on how to choose the actor. This leads to the fourth step: Step 4. Choose an actor. An example of this step is that the modeler has to choose between the hostess, waiter, and kitchen staff to begin the restaurant model. In this case, the modeler chooses to represent the waiter first because she is most familiar with this particular actor. When we have chosen the actor, we then start to represent their behaviour and begin by identifying the actor's goal. We begin by representing the goal because according to the definition of the goal all of the actor's behaviour is based on its goal; but we cannot choose all of the actor's goals. To keep within the domain of the model, we only represent goals that are relevant to the stakeholder. This means that the goal of each organisational actor must directly or indirectly affect the stakeholder's goal. This does not mean that the organisational actor must aid in the stakeholder‘s goal only that it must affect the goal. This leads us to the fifth step: Step 5. Identify the actors' goals and determine those that have an impact on the goal of the stakeholder(s). An example of this would be when we identify the  waiter's goals in a restaurant. It has many different goals that include keeping the customer happy, keeping their job, being on good terms with the kitchen staff, and receiving a good tip. However, there are only two goals which are important from the customer's perspective; the 60  waiter's goal to keep the customer happy and receive a good tip. Therefore, when representing the model we only represent that the waiter's goals to keep the customer happy and receive a good tip. However, if the waiter had the goal to quickly get out of the restaurant when its shift ends and this affected how the waiter treated the customer then it would be included as well, regardless of the fact that it does not aid in the customer‘s goal of getting good service. So when determining the goal, the modeler may not only have to pick from several of the actor‘s goals but also worry about conflicting goals and sub-goals. We propose that the modeler use their judgment to determine which goals to use. It is even possible for modelers to, if they choose, use the goal modeling techniques, as mentioned in Section 1.2.8, to help them link different goals and identify how these goals influence each other. When we know the actor's goals we can model the rest of the actor's' behaviour that will achieve those goals. We choose to begin with the intention of the actor since it is the concept closest to the goal. According to the dynamic metamodel, the intention is what the actor decides to do to achieve its goal. This leads to the sixth step: Step 6. Based on the goals of the actor we must determine the intentions of the actor that are part of the domain. An example of this step would be when we represent the waiter. We would say that the waiter may want to talk to the customer, bring food to the table, or put in a food order to achieve its goals. These are intentions because they will provide food and good service to the customer, thus achieving the waiter's goals of keeping the customer happy and receiving a good tip. Once we have identified the intentions of the actor, we begin to represent reasoning rules since, according to the dynamic metamodel, reasoning rules use goals and change intentions. Unfortunately, reasoning rules cannot be fully represented since we do not know the actor's beliefs, which are also used by reasoning rules. Since beliefs and reasoning rules are connected, we propose to identify the beliefs by identifying the circumstances that would make the actor enact the intention to achieve its goals. Formally, circumstances are attributes of the environment that, when present, would logically lead to the enacting of an intention. This leads to the seventh step: Step 7. Determine the circumstances under which the intentions will be enacted. An example of this step is when we identify that the waiter's intention to order food from the kitchen is used to achieve its goal to keep the customer happy. Knowing this, we can identify that the waiter will order food when it knows what the customer wants and when the kitchen can make that food. 61  Once we know the circumstances under which the actor's intentions change then we can use them to identify the beliefs of the actor, since beliefs are defined as representations of the domain. So, when an actor believes that a ‖circumstance‖ is true it will want to enact its intention. This will also create the reasoning Rule for the intention. This leads to the eighth step: Step 8. Identify beliefs from circumstances and determine reasoning rules for intentions. As an example of this step, assume that the circumstances that trigger the "order food" intention are knowledge of the customer's order and knowing that the food can be delivered. In this case, the actor would have beliefs about what the customer ordered and what kind of food the kitchen can make. This leads to the reasoning Rule: if the customer's order can be fulfilled by the kitchen then order food. Once the beliefs have been identified we must understand if and/or how they are changed. According to the dynamic metamodel, beliefs are changed by learning Criteria and the learning Criteria uses perceptions/input to change beliefs. So we must also identify the perceptions/inputs used in the learning Criteria. We propose that for the sake of minimality the simple learning is not modeled, just the perceptions/inputs which are used in simple learning. We define simple learning as learning that directly maps perceptions/input to a belief and complex learning is defined as transforming the perceptions/inputs into new beliefs. For instance, if an actor were to notice that a glass had clear water and believed that the water was clear then the actor engaged in simple learning. But if the actor were to assume that the water was safe to drink because it was clear, then that it would be engaged in complex learning. Since in simple learning perceptions/inputs and beliefs are the same, it follows that perceptions/inputs can be modelled as being used in the reasoning rules of the actor. This is done to prevent needlessly duplicating information in the model; however, conceptually it is still the belief that is being used in the actor's reasoning Rule. This leads to the ninth step: Step 9. Determine how beliefs change, identify perceptions/inputs or beliefs that may be needed to achieve this and model only "complex learning". In the example, the waiter determines the customer's order by perceiving the customer's order. The belief is a direct translation of the perception/input. However, the knowledge of what the kitchen can cook may be more complicated. Learning this belief includes knowing the customer's orders, what is on the menu, and the ingredients in the kitchen. Therefore the learning Criteria for the latter belief would be represented while the former's learning criteria would not.  62  Once we represent the actor's intentions, we can determine how the actor performs actions in the environment because according to the dynamic metamodel intentions direct actions. Intentions state what the actor wants to do and the actions, as shown in the interaction metamodel, describe the actor's effect on other entities in the environment. This leads to the tenth step: Step 10. Determine the actions needed to carry out intentions. An example of this step is representing that the waiter in the restaurant example writes down the customers' orders when it intends to take them and sends the written order to the kitchen when it intends to order food from the kitchen. When the actions of the actor are identified, we can determine the output of the actor. Output represents the result of the actor's actions according the dynamic metamodel, so we can use the actor's actions to determine its outputs by identifying the result of the actor's actions. This leads to the eleventh step: Step 11. Determine the output of the actions. An example of this step is representing the result of the waiter writing down the customer's order. The result of this action is a written record of the customers' orders which can be represented as an output of the waiter. Once we determine the action and output of the actor we can determine the capabilities used in the actor's actions. According to the Dynamic metamodel, actions use capabilities, so the actor's actions occur because it has the capability to perform that action. For the sake of avoiding clutter in the model, if the capability is obviously present in the actor then it is not modeled in the diagram. This leads to the twelfth step: Step 12. Determine the capabilities needed to perform the task (action). An example of this step is that when we represent the waiter writing down an order, it must have the ability to write (a capability). If we assumed that the waiter could write then the model would not represent that the waiter has a capability to write. Now all of the behaviour of the actor has been represented but the domain may still need to be further represented. As shown in the structural metamodel the domain consists of non-actor entities called dynamic entities and static entities. The static entities are directly related to the actors and are represented in the model as perceptions/inputs and outputs of the actor. Dynamic entities that are not actors may also be modeled. As stated in the interaction metamodel, a dynamic entity causes actions that affect other entities. The attributes of a dynamic entity may not interact with Actors in the domain, but if it interacts with an entity that is used by an actor, it should be represented.  63  This leads to the thirteenth step: Step 13. Determine the non-actor dynamic entities that indirectly interact with the actor. An example of this step is if the waiter in the restaurant model has a perception/input called "pay cheque" then it would be important to model the restaurant's payroll system because the pay cheque is an output of the payroll system. Even though the method is a step-by-step process, the modeler does have a choice of which steps to take after identifying the actor's intentions, since intentions are a bridge between the actor's view of the world and the world itself. At Step 6 the modeler has a choice of either moving  to  step  7,  which  represents  internal  concepts  (reasoning  rules,  beliefs,  perceptions/inputs, and learning criteria) or Step 10, which represents external concepts (actions, outputs, and capabilities). The modeler can choose which path to take based on available information or which type of concept will elicit more information about the actor. More specifically, if the modeler wanted to create the ―physical‖ concepts first, they would perform Steps 1 through 6, Steps 10 through 12, and Steps 7 through 9. However, if the modeler wanted to create the ―internal concepts‖ first, they would conduct Steps7 through 9 and move on to Steps 10 through 12. We also see that once the modeler is finished with one actor they go back to Step 4 and choose another actor. They do this until all actors are fully represented. Figure 10 shows all the possible sequences of steps that the modeler can take when they are using the organisational actor method.  64  Figure 10: Proposed Sequence of Organisational Actor Method In this  The organisational actor method can be used to represent the actual domain or the ideal domain. If representing the actual domain then the modeler must interview people who hold a position at the firm and understand how they perform their job. In this case it may be that several people who fulfil the same role, for example a waiter, may think very differently about how to achieve their goal. So, we suggest that when representing the domain there may need to be two subtypes of waiters. These subtypes might share the same beliefs and goals or other organisational actor concept but differ in other concepts. By using sub-types it is possible to represent that two actors have similarities but also highlight their differences. Practically speaking, it is unlikely that there will be a need to use these subtypes. Since the organisational actor method is suited towards representing actors who make complex decisions it is likely that it will be used represent individuals at managerial levels of the firm, where few of the actors share roles with each other. If representing an ideal domain then it may be best to represent the roles in the organization rather than the actors. By separating the roles from the actors it will be possible to identify whether a person should have two roles or if the current domain is the most efficient way for the roles‘ goals to be achieved.  65  Since the organisational actor method defines the scope of the model and guides the representation of actors and entities in the environment, we propose that it can help modelers use the organisational actor concepts to represent a domain. In Section 2.4 we will provide a graphical representation of the restaurant domain mentioned in this section. 2.3.7 Conclusion By using the design activities, we have created IT artifacts that can be used to represent actors and their functions in the domain, since these artifacts can represent the actors' traits. Specifically the artifacts can represent the actor's internal states, internal processes, external processes, and external states; and the artifacts can represent actors that are reactive, sociable, and goal oriented. The thoughts of the actor are related to its internal states and internal processes because the internal view represents how the actor forms a model of the domain. Any concept connected to the organisational actor‘s simulator can represent the thoughts of the actor since the simulator is the component that deals with the organisational actor‘s internal model of its environment. The interactions performed by the actor are represented by the external states, external processes and social ability of the organisational actor because these criteria deal with the organisational actor‘s relationship with things outside of itself. Any concept connected to the organisational actor‘s receptor and effector is considered to represent interaction since these are the components the actor uses to interact with the world. However any concepts that are mutual attributes of receptor and / or effector and the simulator do not represent the interaction with the actor because these concepts represent the internal view of the actor. Lastly the thoughtful action of the actor is represented by the goal-oriented behavior and reactivity of the actor. These aspects of the actor are related to thoughtful action because they deal specifically with the explanations of the actor‘s behaviour. Any concepts that are related to how the world affects, and is affected by, the internal view of the actor represent the thoughtful actions of the actor. So anything connected to the simulator of the actor represents the thoughtful actions of the actor. Table 13 shows which traits and concepts are connected to the function of the actor, as well as the integrity checks, and method steps that are connected to each of corresponding concepts.  66  Table 13: Actor's Traits Represented by the Organisational Actor Method Fuction  Traits  Organisational Actor Concepts  Integrity Checks  Method Steps  Thought  Internal states  Goals beliefs, and intentions  Step 6: Based on the goals of the actor, determine the intentions of the actor that are part of the domain. Step 7: Determine the circumstances under which the intentions will be enacted. Step 8: Identify beliefs from circumstances and determine reasoning rules for intentions.  Internal processes  Learning reasoning  There should be no belief that is not used in the reasoning rules and / or the learning criteria. There should be no intention that is not changed by reasoning and does not direct actions. Only the actor's beliefs and goals should be used in the reasoning rules and intentions should only be changed by reasoning. Only the actor's perceptions/input and beliefs should be used in learning criteria Only beliefs should be changed by learning. Only learning criteria that changes beliefs should be modelled. Only reasoning rules change intentions should be modelled.  Inte- External ractio processes n External states  Social ability  Actions  Perception/input Outputs, and capabilities  Perception/input and output (by representing the interaction between the initiator and the receiving agent in the interaction metamodel)  Only actions that produce output should be modeled. Output should only be produced by actions. There should be no perception that is not part of a learning criterion. Only capabilities should be used to perform actions. There should be no perception that is not part of a learning criterion. Only and capabilities should be used to perform actions and output should only be produced by actions.  Step 8: Identify beliefs from circumstances and determine reasoning rules for intentions. Step 9: Determine how beliefs change, and identify perceptions/input or beliefs that may be needed to achieve this and model only "complex" learning. Step 10: Determine the tasks (actions) needed to carry out intentions. Step 11: Determine the output of the actions. Step 12: Determine the capabilities needed to perform the task (action). Step 13: Determine the NonActor Dynamic Entities that indirectly interact with the actor. Step 3: Identify actors that interact with the stakeholder(s) and include them in the model.  67  Table 13: Actor's Traits Represented by the Organisational Actor Method Fuction  Traits  Organisational Actor Concepts  Integrity Checks  Method Steps  Thou ghtfu l Actio n  Goal oriented behaviou r Reactivit y  Goals and reasoning  Goals should be used by at least one reasoning rule.  Learning, reasoning, beliefs, and intention  There should be no perception that is not part of a learning criterion. Only learning criteria that changes beliefs should be modelled. There should be no belief that is not used in the reasoning rules and / or the learning criteria. Only reasoning rules that changes intentions should be modelled. There should be no intention that is not changed by reasoning and does not direct actions.  Step 6: Based on the goals of the actor, determine the intentions of the actor that are part of the domain. Step 7: Determine the circumstances under which the intentions will be enacted. Step 8: Identify beliefs from circumstances and determine reasoning rules for intentions. Step 10: Determine the tasks (actions) needed to carry out intentions.  2.4 Organisational Actor Modeling Diagrams Though the design process for developing the organisational actor Method is finished, we propose to develop a graphical representation of the organisational actor concepts, since individuals make sense of information by using map-like structures of cognition (Lakoff 1987). A generic example of this representation can be found in Figure 11.  68  Figure 11: Modeling Diagram for Organisational Actor Concepts  All concepts represented in Figure 11 are discussed in Section 2.3.4.2, except ―Actor Type‖. An actor type can be described as the name of a class of actors and has its own unique internal structure. Perceptions/inputs and outputs are represented as environment variables that exist outside of the actor. In Figure 11, the difference between output and perceptions/input is shown by the organisational actor's relation to the environment variable (ovals in the diagram). The arrows in the diagram are interaction arrows and represent how the actor is related to the environment. If an interaction arrow goes from the variable to the actor, then it is a perception/input. However, if the interaction arrow goes from an actor to an environmental variable, then the variable is output. 2.4.1 Using the Organisational Actor Diagram to Represent a Domain We can show an example of the organisational actor diagram by representing a scenario. According to Kruchten, Woo, Monu & Sootedeh (2007) and Monu & Woo (2009), concepts similar to the organisational actor were used to represent the disaster management domain. We, therefore, present an example of a disaster management scenario to be an example for representing the domain. In Figure 12, using the organisational actor diagram, we represent the case below. A hospital manager must decide if she will inform the water company that steam has shut down in part of the hospital after a small earthquake. She has a computer system which she uses to learn more about the damage to the hospital after a disaster. The system receives messages from sensors on various infrastructures in the building and sends this 69  information to an electronic map in the manager's office. This map shows where electrical, water, or steam, service is down and the corresponding infrastructure that has been damaged. Looking at the map, she realizes that the east wing of the hospital does not have electricity and that Powerline 5 is damaged. The hospital manager, with this information, could contact the power company to tell them which line is damaged and how urgent the problem is. If she has access to a generator then she could also look for alternative methods of lighting and heating the east wing.  Figure 12: Organisational Actor Representation of Disaster Management Example  As shown in Figure 12, we can represent the internal and external view of the actors. We have represented the internal view by illustrating how the hospital manager uses the electronic map to make inferences about the world and uses those inferences to decide which actions to perform. We have also represented the external view by showing the interaction of one actor with other actors and objects in the environment. The electronic map provides information to the hospital 70  manager, and communication between the hospital and the utility is maintained through a message from the hospital. We introduce a new symbol into the modeling language to represent the electronic map called the dynamic entity. This symbol represents the dynamic entities discussed in Section 2.3.4.1. The dynamic entity is a non-agent entity that can still perform actions autonomously, but does not have a goal, beliefs or other agent concepts. A dynamic entity is unlike an environmental variable because dynamic entities can autonomously create output, but an environmental variable needs to be acted upon to change the environment. Therefore the electronic map is represented as a dynamic entity, and not an environmental variable, because it can change its settings based on sensors which monitor the infrastructure. The utility, once it receives the message, will fix the infrastructure and the hospital manager will notice the repair based on the response of the electronic map to the change in the state of the infrastructure. We also show some parsimony by only representing that having access to the generator is a capability of the hospital manager rather than other capabilities such as contacting the utility. With this example we have shown that we can represent the internal and external views of the actor and the interaction between actors in a single diagram. 2.4.2 Using the Organisational Actor Method Using a scenario based on the restaurant example from Section 2.3.6, we show how a modeler uses each step of the organisational actor method to develop part of an organisational actor diagram. We use a scenario about a restaurant to start our example. Customers come to a restaurant looking for a meal. They are greeted by the hostess who brings them to a table (if available) or to their specific table if a reservation has been made and gives them menus. The waiter then comes by to take their order. The customers, based on their tastes, order what they want to eat and drink. The waiter takes the food orders to the kitchen and the drink menus to the bar. The bar takes the orders, prepares the drinks, and groups them by order. The kitchen does the same for the food. The waiter while waiting on other tables, checks with the kitchen and bar periodically to make sure that the food and drink for their orders is done. If so, the waiter takes the food and/or drinks to the table corresponding to the order. Once the customers have finished their meal the waiter presents the table with a bill. The customers then pay the bill through either cash and/or credit card. In Step 1 (Identify the stakeholders) and 2 (Identify goals of stakeholders and choose appropriate stakeholders for the model) the modeler does not create the diagram but must identify and choose  71  the stakeholder(s) that will guide the creation of the diagram. For this example, we assume that the modeler has chosen the customer as the stakeholder and that the goal of the customer is to receive good food on time. With the guidance provided by the stakeholder, the modeler moves to Step 3 (Identify actors that impact the goals of the stakeholder(s) and include them in the model) and identifies the actors that  interact with the customer. Based on the scenario, the modeler knows that the customer directly deals with the hostess and the waiter. The modeler also sees that the customer indirectly interacts with the bar and the kitchen, since they interact with the waiter to fulfill the customer's goal. The kitchen provides the food and the bar provides drinks. In Step 4 (Choose an actor) the modeler must choose the waiter, kitchen, hostess or bar. In this case, the modeler first chooses the hostess. In Step 5 (Identify the actors' goals and determine those that have an impact on the goal of the stakeholder[s]) the modeler identifies the goal of the hostess  based on the goal of the customer. From the customer's point of view the hostess's function is to provide tables for all customers, so the modeler writes that the goal of the hostess is to ensure that all customers get a table. In Step 6 (Based on the goals of the actor, determine the intentions of the actor that are part of the domain) the modeler identifies the personal intention of the hostess that will help achieve her  goal. The modeler learns that the hostess can seat customers to achieve her goal, so her intention will be to seat customers. In Step 7 (Determine the circumstances under which the intentions will be enacted) the modeler determines the circumstances when the intention will be enacted and finds  out from the hostess that a customer is seated when he or she requests a seat and when a seat is available. In Step 8 (Identify beliefs from circumstances and determine reasoning rules for intentions) the modeler identifies the beliefs of the hostess based on the circumstances used to enact the intention and identify the reasoning rules for the hostess. From the circumstances, we know that the hostess has to have a belief about whether a customer is requesting a table and whether there is a table available for the customer. This leads us to the reasoning rule: If customer requests a table and a table is available then seat the customer. In Step 9 (Determine how beliefs change, and identify perceptions/input or beliefs that may be needed to achieve this and model only "complex" learning) we have to identify how the beliefs of the hostess change. The first belief is changed  when the customer makes a request for a table and the second belief of whether a seat is available is affected by the seating schedule, which says how many reservations are there for that specific time of day and if a party is already at the table. If the seating schedule says that there is a seat open and enough tables are available for reservations, then the hostess will believe that 72  there is a seat available. This means that the perceptions/inputs of the hostess are the seating schedule and the customer's request for a seat. In Step 10 (Determine the tasks [actions] needed to carry out intentions) the modeler figures out the actions the hostess must perform to be able to fulfill her intention of seating the customer. The modeler determines through observation that when seating the customers, the hostess provides a menu to the customers, adjusts the seating schedule, and assigns a table to the customer. In Step 11 (Determine the output of the actions) the modeler determines the output of the actions identified in the previous step and indentifies the output of the hostess as a new seating schedule and a message to the customer that indicates where the table is for the customers, and a menu given to the customer. The modeler skips Step 12 (Determine the capabilities needed to perform the task [action]) and 13 (Determine the non-actor dynamic entities that indirectly interact with the actor) because of an assumption that it is common knowledge that the hostess can speak to the customers and write down changes in the seating schedule, as well that the hostess does not need to gain or will at some point lose these capabilities. Also there is no non-actor dynamic entity that indirectly interacts with the hostess. A representation of the model up to this point can be found in Figure 13. To finish the diagram the modeler would go back to Step 4 (Choose an actor) and develop a representation of either the waiter, kitchen or bar actors.  73  Figure 13: Organisational Actor Representation of Disaster Management Example  2.5. Conclusion In this Chapter, our objective was to develop a conceptual modeling method that could be used to directly represent the thoughts, interaction and thoughtful action of actors in the domain. The result of our work is a method that has six design artifacts that incorporate the internal states and processes, external states, external processes, and social ability of the agent and the goal oriented behaviour and reactivity of the agent. Internal states are elements of the agent's model (beliefs, et.) of the world; internal processes are the decision and thinking processes of the agent. External states are the states of things in the environment that the agent interacts with in some way, external processes are the changes that occur in the environment, and social ability 74  refers to interaction between agents. Goal oriented behaviour is defined as pro-actively performing actions and reactivity refers to the agent's ability to react to changes in the environment. The first artifact we developed was the abstract definition of the organisational actor modeling construct. This artifact incorporates the actor's traits since it states that the actor affects its environment, meaning that the external state of the actor and how it changes those states via processes is included in our definition of the actor. It also states that the actor must be able to make decisions about its actions and perceive the environment, which relates to the internal states and processes of the actor. Lastly, our specification of the actor's characteristics states that the actor must be able to link its perceptions of the environment to its possible actions which incorporates the reactivity of the actor. The second artifact was the set of components for the organisational actor modeling construct which are; the receptor which takes in input from the environment, the simulator which converts these signals into a model of the world used by the actor, and the effector which makes changes in the environment. All of the states and processes of the actor are incorporated into the organisational actor modeling construct since the construct is based on the systems approach, which views entities as containing states and performing processes. The organisational actor modeling construct incorporates the reactivity of the actor by having the receptor send signals to the simulator, which then sends commands to the effector. Due to this chain of events, a change in the world can affect the organisational actor that will, in turn, affect the environment. The social ability of the actor is also incorporated into the construct because the receptor can receive messages from other actors and the effector can create messages to other actors. The third artifact we created was the set of organisational actor concepts that represent all of the actor's traits. The internal view of the actor is directly represented by the states of the receptor and the simulator in the modeling construct. The beliefs, goals, intentions, and capabilities of the actor represent internal states, and learning and reasoning represent internal processes. The external view of actor is also represented since, the receptor and effector components perform the external processes of action and Perceiving and the output and perception/input concepts represent the external states important to the actor. The goal oriented behaviour of the actor is represented by the goal, reasoning and intention concepts because together they represent how an actor would proactively decide to perform a task. The reactivity of the actor is represented by the reasoning concept, since, through reasoning, changing the 75  beliefs of the actor leads to changes in the actor's behaviour. Finally, social ability is represented by the input and output of the actor. The fourth artifact was the set of metamodels which show how the organisational actor concepts are linked to represent the structural, dynamic and interactive aspects of the organisational actor. The structural metamodel describes the composition of the organisational actor and its environment, the dynamic metamodel describes the behaviour of the organisational actor, and the interaction metamodel describes how organisational actors interact with each other and the environment. The internal and external processes and states of the actor are identified in the structural metamodel since the model identifies the components of the actors. Goal oriented behaviour and reactivity are represented in the dynamic metamodel since it represents the behaviour of the actor. The social ability of the actor is represented in the interaction model since it shows exactly how the actor initiates and receives messages from other actors. The fifth artifact (integrity checks) and sixth artifact (the organisational actor method) helped to incorporate the actor's traits into the organisational actor diagrams. The integrity checks state the rules for a valid diagram and the organisational actor method ensures the modeling process creates a diagram that corresponds to rules. The integrity checks accomplish this by stating precisely how the organisational actor concepts should appear in the diagrams so that they are in accordance with the relationships found in the organisational actor metamodels and the organisational actor method guides the modeler to create models that adhere to the relationships found in the metamodels. Since the organisational actor metamodels incorporate all of the actor traits that should be represented, the integrity checks and organisational actor method ensure that the organisational actor diagrams include these traits. From these results we can say that the organisational actor method can directly represent the internal states and processes, external states and processes, goal oriented behaviour, reactivity and social ability of actors in the domain. In the next Chapter we will test whether practitioners will find the organisational actor method usable and useful for representing a domain.  76  Chapter 3: Validation of the Organisational Actor Method In design science the purpose of validation is to ensure that there is some relevance to the artifact that has been created during the design process. According to Hevner et al. (2004) the purpose of evaluating a design artifact is to identify flaws and determine ―when [the design artifact] satisfies the requirements and constraints of the problem it was meant to solve‖ (Hevner et al. 2004, pg. 85). Since the purpose of evaluating artifact is to explore how well the artifact meets its‘ requirements, we conduct studies in this Chapter to determine whether the organisational actor method can represent any of the aspects of the actor and if the method can be used to guide the use of these concepts. Though we will discuss validity of the studies to identify what can be concluded from the results of each study, we do not need to use statistical tests for the results because we are interested in exploring the usefulness of the method rather than proving its effectiveness. However, the results we obtain from the studies may direct future studies of the method‘s effectiveness. We have developed several artifacts, but we will test only the organisational actor concepts and organisational actor method and will not our definition of an actor, the organisational actor modeling construct, the organisational actor metamodels and the integrity checks. We only test the organisational actor concepts and the organisational actor method because they are the artifacts that should be directly used by practitioners. According to Hevner et al. (2004), in order to be considered as design artifacts, IT artifacts developed in design science studies must be used by practitioners, and so these artifacts must be tested to ensure that they will be used in the field. Practitioners will use the organisational actor concepts because they are the building blocks of the organisational actor method, and practitioners will use the organisational actor method itself. Another reason we only test the organisational actor concepts and the organisational actor method is that our definition of an actor, the organisational actor modeling construct, the organisational actor metamodels and the integrity checks act as foundations for the organisational actor concepts and organisational actor method. Therefore, if we find that the organisational actor concepts are not valid, we can determine whether the organisational actor concepts are incorrectly representing the organisational actor modeling construct, the organisational actor modeling construct is incorrectly representing the definition of the actor, or our definition of the actor is wrong. The same can be determined for the organisational actor 77  metamodels and the integrity checks. The organisational actor method is based on the organisational actor metamodels, and if the organisational actor method is invalid then something may be wrong with the organisational actor metamodels. If there are issues with the organisational actor metamodels then, by definition, the integrity checks must be changed since they are a direct interpretation of the rules found in the organisational actor metamodels. We will conduct two research studies to evaluate the organisational actor concepts and organisational actor method. The first research study will focus on whether the artifact is useable, or needed, for representing the domain. It is important to determine whether the artifacts have any use to practitioners because the novelty of the organisational actor method makes us unsure that representing the internal and external views of an actor can be done. The second type of study will test the usefulness of the artifacts in the domain; these are preliminary studies but they are designed to show that the artifacts provide some utility to practitioners. In this Chapter, Study 1 (Section 2) will determine whether the organisational actor concepts can be used by people to represent a domain, and Study 2 (Section 3) will investigate the usefulness of organisational actor concepts in representing a domain. Study 3 (Section 4) will test if there is a need for an organisational actor method, or if users can just use their own intuition to discern how to use the concepts. Study 4 (Section 5) will investigate the usefulness of the organisational actor method developed in Chapter 2. Table 14 shows an overview of what is evaluated in the studies and the criteria for evaluation. Table 14: Artifacts and Criteria for Validation Studies IT Artifact  Criteria for evaluation Usability  Usefulness  Organisational Actor Concepts  Study 1  Study 2  Organisational Actor Method  Study 3  Study 4  To validate the specific design of the studies, we consult the empirical framework for conceptual modeling created by Gemino and Wand (2004) that mentions two types of conceptual modeling studies; those that focus on the creation of conceptual models (script creation) and those that focus on how the conceptual model is interpreted (script interpretation). Script creation and interpretation have a product and a process. The product of script creation is the conceptual model itself. The process of script creation is the act of the analyst converting a domain into a conceptual model. The product of script interpretation is the understanding of the 78  domain that the reader gains from the model. The process of script interpretation is how the model reader uses their understanding of the conceptual modeling language to learn about the domain. In Study 1, we must focus on the product of the script creation of novice system analysts because we want to determine how usable the organisational actor concepts are for people who have little or no training in conceptual modeling and the organisational actor method. In Study 1 we will ask subjects to describe the ‗humans‘ they have read about in a scenario, which will simulate representing actors in a domain. We will then identify whether the concepts and terms used by the subjects correspond to the organisational actor concepts. By determining whether the novice system analysts‘ natural way of describing the domain is compatible with the organisational actor concepts, we can test the usability of the organisational actor concepts. In Study 2 we must focus on the product of the script creation of modelers using organisational actor concepts versus another agent-based conceptual modeling language, because we want to determine the usefulness of the organisational actor concepts. In Study 2 we will present domain experts with two sets of diagrams representing the same domain. One set will be using the organisational actor concepts and the other will use the i* modeling framework. The experts will judge which of the models is the most effective. To ensure that the presentation of the diagrams does not adversely affect the comparison, we also create organisational actor diagrams of the domain that only use organisational actor concepts similar to the i* concepts and have subjects compare these diagrams to i* diagrams. By judging the quality of the diagrams we can test the usefulness of the organisational actor concepts. In Study 3 we must focus on the process and product of the script creation of modelers because we want to determine whether a method for using organisational actor concepts is needed. In Study 3 we will give one group of subjects a method to represent the domain using some of the organisational actor concepts and give the other group only definitions of those same organisational actor concepts. In the study we identify any problems that the subjects have when representing the domain and also measure the quality of the diagrams they create. We conduct this experiment on modeling novices and experts to see whether there is a difference between the performances of these groups, or whether or not a method is needed to guide modelers to create organisational actor diagrams. We can test the possibility of practitioners using the organisational actor method. In Study 4 we must focus mainly on the process of script creation and also investigate the product of script interpretation because we want to determine the usefulness of the 79  organisational actor method. In the previous studies, script interpretation was not important because the purpose of the concepts was to correctly represent the domain and the minimum requirements for determining whether a method was needed to represent a domain were whether it could make the modeling process easier and whether its use led to diagrams that correctly represent the domain. However, in this study, script interpretation is important because the method must create diagrams that can be interpreted by others for it to be useful. In a study by Hunton and Beeler (1997), the authors found that users involved in the software development process are more satisfied with the finished result, and Kung and Sølvberg (1986) suggest that conceptual modeling diagrams can be used to explain the domain to stakeholders. Therefore, the reader's interpretation of the modeling diagram is extremely important to the software development process and a conceptual modeling method's ability to create easily communicated diagrams should at least be explored in a preliminary study about the usefulness of a conceptual modeling method. In Study 4, we use the organisational actor method to guide us in interviewing an expert about his work. We analyse how each step in the process elicits responses from the expert and whether the model can communicate the modeler‘s representation of the domain. By determining whether the organisational actor method can guide the creation of a representation of an employee‘s view of his work and communicate that information to another person, we can determine if the organisational actor method is useful to practitioner. Below in Table 15 we have a brief overview of each of the studies conducted in this Chapter. Table 15: Overview of Validation Studies Study Artifact Research question 1  Organisational actor concepts  2  Organisational actor concepts  3  Organisational actor method  4  Organisational actor method  Do non-trained individuals use the organisational actor concepts? Do the organisational actor concepts better convey the domain than concepts from other agent-based languages? Does a method help modelers to more effectively and efficiently build an organisational actor Model? Can the method be used to represent an employee's work?  Subjects Nontechnical people Domain experts  Modeling novices and Experts Domain expert  Focus of the Study Product of script creation Product of script creation  Process and product of script creation Process of script creation and product of script interpretation 80  We will also identify threats to the validity of each study and determine how these threats affect the interpretation of the study's results. We use the definition of validity threats presented by Runeson and Höst (2009), which are developed from Yin 2003, to systematically analyse the validity of our work. Runeson and Höst (2009) present four types of validity: construct validity, internal validity, external validity and reliability. Construct validity refers to whether the study analyses the phenomena that it is supposed to analyse; for instance, if a researcher were to study the effectiveness of a software development technique and measured it by the popularity of the technique then the study would have little construct validity because popularity does not measure effectiveness. Internal validity refers to whether the study identifies causal links correctly; for instance, if a study on the effect of 3D pictures on purchase behaviour were to find a causal link between the presence of 3D pictures and an intent to purchase the product, but the study did not control for the features of the product then the study would have little internal validity. The features of the product (its aesthetics, functionalities, purpose, etc.) may have an effect on a customer's purchase intentions and should be taken into consideration. External validity refers to whether the results of the study can be generalised to a larger population; for instance, if a study on the effect of electronic communication in the software design process were to use teams of undergraduate students to simulate software design teams, then the results of the study may not be generalised to all software development teams. Development teams with more work experience, or information about their organisation, may perform differently under the same conditions. Reliability is how the authors refer to whether others can replicate the study; for instance, if a study were to analyse the effectiveness of a software implementation technique but did not identify how the analysis was conducted then the study would have little reliability. It would be difficult for another researcher to replicate the study unless the procedures for implementing and developing the software were explicit and could be taught to someone else. Although we will discuss validity of the studies to identify what can be concluded from the results of each study, we do not need to use statistical tests for the results because we are interested in exploring the usefulness of the method rather than proving its effectiveness. However, the results we obtain from the studies may direct future studies of the method‘s effectiveness. Below we present our four studies and discuss their procedures, results, and validity.  81  3.1 Study 1: Determining the Usability of the Organisational Actor Concepts The purpose of this study is to determine whether individuals without technical training in system analysis or computer science can understand the organisational actor concepts. Alexander & Maiden 2004, when discussing scenario based methodology, state that nontechnical individuals intuitively describe their domain as a story, and focus their story on a person who performs actions in the story environment, called an actor. The organisational actor concepts have been developed to represent the actor, so they should be able to represent people‘s stories about their work. However, we do not know whether nontechnical individuals can use the organisational actor concepts themselves to represent their domain because the concepts are not exactly the same as the terms discussed by Alexander & Maiden (2004). If the organisational actor concepts are very different from the terms and ideas used in the users' narratives then it may be difficult for these individuals to use the organisational actor concepts to describe their work. Therefore, this study establishes whether the terms used by non-technical individuals to describe a domain are similar to the organisational actor concepts. 3.1.1 Subjects Since the objective of this study was to determine whether non-technical people tell their stories using organisational actor concepts or terms similar to organisational actor concepts, we asked graduate students from disciplines outside of the information systems and computer science disciplines if they would be subjects for the study. Ten individuals applied. They were recruited at a graduate residence in a North-western University and we ensured they had no knowledge of intelligent agent systems and / or system analysis and design. The areas of the subjects' expertise were law, accounting, journalism, and classical studies. 3.1.2 Method For the study, each of the subjects was asked to read a description of a business process and explain the details of the business process they had read. The specific business process involved a customer entering a restaurant. The description was not available to the subjects when they explained the business process. The description was:  82  A customer comes to a restaurant looking for a meal. They are greeted by the hostess who brings them to a table (if available) or to their specific table if a reservation has been made and gives them menus. The waiter then comes by to take their order. The customers, based on their tastes, order what they want to eat and drink. The waiter takes the food orders to the kitchen and the drink menus to the bar. The bar takes the orders, prepares the drinks, and groups them by order. The kitchen does the same for the food. The waiter while waiting on other tables, checks with the kitchen and bar periodically to make sure that the food and drink for their orders is done. If so, the waiter takes the food and/or drinks to the table corresponding to the order. Once the customers have finished their meal the waiter presents the table with a bill. The customers then pay the bill through either cash and/or credit card. We asked the subjects to describe the ―humans‖ in the process using their own words. We chose the term 'human' and not 'actor' because we did not want to influence subjects by providing a specialised definition for 'actor'. The subjects were told that a 'human' is something that takes in information from the environment, thinks about it, and changes the environment. This is a generalised definition of the organisational actor. Each of the subjects' explanations of the business process was recorded by the researcher. During the explanation, the researcher asked each subject to clarify and explain some of the terms used. After the subjects‘ explanations were concluded, the recordings were transcribed. Analysis of the transcriptions was conducted by two independent analysts who were given instructions to identify when subjects mentioned and used the organisational actor concepts and appropriate synonyms. Two types of analyses were conducted by the analysts. The first analysis was an objective count of when the organisational actor concepts and their synonymous terms were mentioned by the subjects. The synonyms for the concepts were identified by the analysts using a thesaurus and brief definitions of the organisational actor concepts found in Table 16. Table 16: Colloquial Definitions of the Organisational Actor Concepts Organisational actor concept Definition Goal Beliefs Learning Perception/Input Intentions Reasoning Actions Output Capabilities  The state that the actor wants the world to be in. What the actor thinks about the world. How the actor interprets the world. What the actor sees in the world. What the actor wishes to do in the world. How the actor decides to act in the world. How the actor changes the world. What the actor produces in the world. A part of the actor that must be present for an action to take place.  83  The analysts chose different synonyms for the organisational actor concepts based on the definitions in Table 16 using a thesaurus. The synonyms of the concepts and the synonyms' definitions can be found in Table 17. The analysts used the synonyms in Table 16 to identify the number of times the subjects indirectly used the organisational actor concepts.  Table 17: Synonyms of the Organisational Actor Concepts Identified by Coders Coder 1 Coder 2 Organisational Synonyms Actor Concept (Thesaurus 2009)  Definition  Goal  Destination, duty, end, intent, limit, mark, mission, object, objective, target, use  Aim, purpose Ambition, design, Aim, purpose of of action destination, objective, action target, mission, aim, purpose  Beliefs  Assumptions, concept, Something credence, idea, principle, regarded as doctrine, dogma, theory, true fundamental, hypothesis  Assumption, concept, Something regarded faith, idea, ideology, as true opinion, theory, hypothesis, tenet  Learning  Ascertain, detect, Discover, determine, discern, gain, find out gather, tumble, uncover, see, understand, unearth  Absorb, assimilate, comprehend, incorporate  Reasoning  Adduce, cerebrate, cogitate, conclude, contemplate, decide, deduce, deliberate, examine, solve  Conclude, analyze, Figure out, judge, figure, resolve, understand settle, solve, decide, decision  Capability  Competence, adequacy, Ability to aptitude, art, capacity, perform effectiveness, efficiency, means, potential, power, proficiency, skill  Ability, endowment, skill, talent, strength, aptitude, gift, proficiency, qualification, fitness, quality, adaptability  Intention  Desire, aim, animus, design, end, hope, motive, objective, plan, point, purpose  Goal  Cause, attempt, Work, exertion undertaking, venture, enterprise  Output  Achievement, amount, gain, product  Something produced  Achievement, Something produced accomplishment, acquisition, product, result, consequence, yield, harvest, turnout  Action  Act, doing, execution, move, step, procedure, making, take  Effects, influences, marks, reaction  Individual deed  Mentally analyze  Synonyms (Thesaurus 2009)  Definition  Discover find out  Capacity; character adeptness, effectiveness  impact, impression  84  Table 17: Synonyms of the Organisational Actor Concepts Identified by Coders Coder 1 Coder 2 Organisational Synonyms Actor Concept (Thesaurus 2009)  Definition  Synonyms (Thesaurus 2009)  Definition  Perceptions  Viewpoint, aspect, attitude, outlook, perspective, view  Understanding idea  Something understood, planned,  Acumen, apprehending, approach, attention, attitude, awareness, concept, grasp, image, impression, judgement  In the second type of analysis, the analysts used the definitions of the organisational actor concepts in Table 16 to subjectively identify phrases in the transcripts that correspond to the use of organisational actor concepts in the subjects' descriptions of the domain. Analysts kept track of each phrase and identified how it related to an organisational actor concept. 3.1.3 Results In the first analysis, the coders discovered that only reasoning, actions, and goals were directly mentioned by the subjects and that all concepts were indirectly mentioned by at least one subject. We also find that there are some discrepancies between the synonyms the coders chose for the organisational actor concepts. For instance, the first coder identified the action concept as an individual deed and the second coder viewed the action concept as an impression or impact. This affected the words they chose to be synonyms for the action concept so their analysis was slightly different. Table 18 lists the organisational actor concepts, how many times they were directly mentioned by the subjects and how many times synonyms of the concepts were used. The table also lists how many subjects directly mentioned the concepts, as well as how many of them used the synonyms of the concepts. In Table 18, we also record the different analysis from the coders when referring to the synonyms of the organisational actor concepts. The first number is the first coder‘s analysis and the second number is the second coder‘s analysis.  85  Table 18: Incidents of Organisational Actor Concepts in User Descriptions (Terms) Coder 1*  Coder 2*  Organisational Number of Actor Concepts times the concept was used by all subjects  Number of subjects who used the concept  Number of times the synonyms of concepts was used by all subjects  Number of Subjects who used the synonyms  # of times the synonyms of concepts was used by all subjects  Number of Subjects who used the synonyms  Intentions  0  0  4  3  0  0  Goal  15  2  17  4  15  3  Beliefs  0  0  3  3  0  0  Learning  0  0  2  1  0  0  Reasoning  3  3  14  7  30  8  Capability  0  0  2  1  5  3  Output  0  0  1  1  2  2  Action  3  3  36  9  9  3  Perception/input 0  0  0  0  2  2  *The coders used their definitions in Table 17 to determine which synonyms to use  The first coder found that the most common concepts were actions and reasoning with nine out of ten subjects directly or indirectly mentioning actions and seven subjects mentioned reasoning. The least salient concept was the perception/input, which was not mentioned by any subjects, followed by the learning, capability and output concepts, which were mentioned once by one subject. The second coder found that the most salient concept was the reasoning concept and that the goal was the second most salient concept since three subjects mentioned the concept directly and indirectly and was mentioned seventeen times. The least salient concepts were intentions, beliefs, and learning, which were not mentioned by subjects. The second least salient concepts according to the second coder were output and perception/input concepts that were mentioned once by two subjects. From the results in Table 18, we see that subjects intuitively focused on the rationale (reasoning, goals) for the business process and the performance of actors in the world (actions, capabilities) when describing the domain. However, subjects did not discuss how the environment affects the actor (learning, perceptions/inputs, and beliefs) and what is changed in 86  the environment (output). This means that the subjects focused on some of the agent‘s functions mentioned in Section 1.2; parts of the interactions and thoughtful actions of the actor were discussed by the subjects but not their thoughts. We also conducted a more subjective analysis where the coders had to determine the number of phrases in the transcripts which were related to each of the organisational actor concepts. In Table 19 we show the organisational actor concept, the number of phrases found in the transcript by the coders and an example of a phrase. For instance Coder 2 identified that a subject mentioned a goal when they said: "they want to eat healthy food." The coder indicated this by stating "goal of the customer". In Table 19 we show this as: they want to eat healthy food [goal of the customer].  Table 19: Incidents of Organisational Actor Concepts in User Descriptions (Phrases) Organisation1st Coder al Actor # of Examples of Phrases Concepts Phrases  2nd Coder # of Examples of Phrases Phrases  Intentions  4  What stage of their meal the customers are if they are just beginning to eat or at the end ['end' is used to understand the intention of the waiter] of their meal.  5  Brings the menus to their customers when to check on their food and drinks. And also when to check their table and when to bring their bill [Serving the customers is the intention of the server].  Goal  0  N/A  5  They want to eat healthy food [goal of the customer].  Beliefs  2  Each person probably has some idea [idea in this case is the participants belief about the waiter] based on what he or she thinks is more efficient or what's easiest.  3  He realizes that that order has to go in and he has to go pick it up [beliefs of the waiter].  Learning  5  He will take the food and the 7 drinks at the same time to the table so the waiter could determine [he will take the food and the drinks at the same time to the table so the waiter could determine when both of them are ready]when both of them are ready.  The hostess because they can also respond to what has been made before [The hostess is learning based on prior experience].  87  Table 19: Incidents of Organisational Actor Concepts in User Descriptions (Phrases) Organisation1st Coder al Actor # of Examples of Phrases Concepts Phrases  2nd Coder # of Examples of Phrases Phrases  Reasoning  7  For the first thing he's gotta do 9 is decide [decide is used to show the waiter is reasoning as to when to go to the table] when he wants to go over to the table.  To choose how to pay the bill [reasoning of the customer].  Capability  0  N/A  Displays social abilities by communicating with the customers and with the staff [Communication is identified as a capability].  Output  9  The decisions of other people 3 that ultimately lead her to take her own decisions [take her own decision is settling the output of the waiter].  Waiter needs to see there are people there so it is his job to make sure they got what they need. [output of waiter].  Action  7  People doing [doing is the action taking place] the dishes.  25  So he'll go and find out..uh.. what it is if they have questions for the menu, bring them water, bring them any drinks, answer their questions, then take their orders, bring them anything else that‘s supposed to be brought, [actions of the waiter].  Perception/Inp ut  0  N/A  3  To sense that when the food is finished [perception of the waiter].  5  In Table 19 we can see that the first coder found that the action and output concepts were the most prevalent concepts in the transcripts and the second coder found that the action and reasoning concepts were the most prevalent concepts in the transcripts. So, most of the phrases related to the organisational actor concepts concerned actors performing a task or an explanation of a task. Table 19 also shows that the first coder found that the perception/input, capability, and goal concepts were not mentioned in the transcripts and that the belief concept was only mentioned twice. It also shows that the second coder found that perception/input, output, and belief concepts each were mentioned only three times. Even though there is large disagreement 88  between the coders over the output concept, they do agree that the internal states of the actor, i.e. the perception/input and beliefs concepts, are rarely mentioned in the transcript. Looking at both analyses, we have discovered that all of the organisational actor concepts were mentioned at least once by the respondents. In the objective analysis, the first coder found that all concepts were mentioned at least once ,and in the subjective analysis the second coder found that each of the concepts was mentioned at least once. The study also determined that the most salient concepts for non-technical modelers when describing the domain were actions and reasoning concepts and the perception/input and belief concepts were the least likely to be mentioned by the non-technical modelers. 3.1.4 Threats to Validity In this exploratory study there are some threats to validity, specifically issues with reliability and external validity. There may also be some issues with construct validity. When we determined the salience of the concepts we assumed that a concept would be salient if the subjects mentioned a similar concept or mentioned a phrase that was similar to the definitions of the organisational actor concepts. However, there are some limitations to these measurements. The subjectivity of the coders is used to determine which synonyms to use and whether certain phrases in the transcript correspond to the organisational actor concepts. As we can see from the results, the two coders had disagreements between the meanings of the phrases as they pertain to the concepts even though both received the same set of definitions. Therefore, there is a threat to reliability in the study. Another threat to reliability is that the researcher asked probing questions when the subjects were describing the domain. These questions did not follow a procedure and another researcher may not ask the same probing questions. There are issues with external validity because the scenario in the study did not have many decision-making elements. It is possible that if the subjects were asked to represent another scenario that involved decision-making, such as choosing a college major, then the perception/input and belief concepts would be more salient or the actions would not be as salient. The study was designed, though, to ensure construct validity since we ensured that the salience of the organisational actor concepts were measured not just by specific terms uttered by the subjects, but phrases that they used as well. Internal validity was not an issue because no causal relationship was considered for this study. Even with these limitations, we can say that the organisational actor concepts are usable. According to the coders, all of the concepts were either implicitly or explicitly used at least once. 89  So, if a person were to learn about all of the organisational actor concepts the concepts should seem familiar. This means that with a little coaching most people should be able to use the organisational actor concepts to represent their domain.  3.2 Study 2: Determining the Usefulness of the Organisational Actor Concepts The organisational actor concepts were developed to describe actors and their behaviour in a domain through description of the actors‘ social ability, reactivity, goal oriented behaviour, internal view and external view of the actor. By representing these aspects of the actor, the concepts represent an individual in an organisational process in a way that no other agent-based conceptual models can because they show how the actor‘s individual thoughts about the domain can lead to its actions. Even though the organisational actor concepts are designed to represent actors, we do not know whether these concepts will be useful to practitioners for explaining the actor‘s behaviour. Practitioners use other conceptual modeling languages that do not have all of these concepts and it is possible that the organisational actor concepts will not represent anything that domain experts wish to communicate to model readers. Therefore, to determine the usefulness of the organisational actor concepts, in this study our research question is: How do the organisational actor concepts compare to other agent-based conceptual modeling concepts when representing actor behaviour in a domain? 3.2.1 Subjects In this study, we recruited ten undergraduate students who had experience in online media purchasing. The subjects had used an online commerce provider to purchase merchandise at least twice in the month before the study. The subjects also had little knowledge of conceptual modeling (one class on entity-relationship modeling) and no knowledge of intelligent agent systems. 3.2.2 Method For the study, we wanted to test the effectiveness of the organisational actor concepts compared to another agent-based conceptual modeling language, so we asked our subjects to judge the quality of the i* diagrams and organisational actor diagrams that represented an online 90  e-commerce scenario. We chose the i* conceptual modeling language because like the organisational actor method, it is an agent-based conceptual modeling language that was designed to gather early system requirements (Yu 1997) so it is the conceptual modeling language closest to the organisational actor method. The i* framework is also a widely recognised conceptual modeling framework, is part of an international standardised form of user requirement notation and has an annual conceptual modeling workshop at a major International academic conference on information systems (Lapouchnian 2010). As mentioned in Chapter 1, i* does not explicitly represent the internal processes of the actors or their social ability, and the reactivity of the actors only has a limited representation in the framework. The internal decision making of the actor is not represented using i*; the model reader must interpret the relationship between the actor's tasks and goals to determine the actor's decision-making process. The social ability of the actors is also not represented in i*, since the only relationship represented between actors is a dependency relationship; the framework does not represent messages being sent between actors. Lastly, how the actor reacts to the environment is only partially represented in i*. The framework represents the goals of an actor's task but the circumstances that trigger when an actor performs that task is not represented by i*. The internal processes, social ability and reactivity of the actor are represented in the organisational actor Method by the reasoning, learning and perception/input organisational actor concepts. We split our subjects into two groups; the control group and the treatment group. Both groups received training explaining the i* and organisational actor concepts. The training included an explanation of the symbols in the two languages and definitions of the concepts in both languages; however, the difference between the groups was the training and diagrams they received concerning the organisational actor method. The control group received organisational actor diagrams that were similar to the i* models. We call these organisational actor diagrams the 'translated models‘ and they also received only information about organisational actor concepts that were similar to the i* concepts. In the treatment group we developed an organisational actor diagram from the description of the domain using all of the organisational actor concepts and presented that diagram to the subjects. The subjects also received information about all organisational actor concepts developed in Chapter 2. We created these groups because we wanted to ensure that the presentation of the diagrams did not adversely affect the comparison between the i* and organisational actor diagrams. It is 91  possible that the presentation of the organisational actor concepts made them easier to read because the organisational actor diagrams present information in a semi-narrative form; and therefore closer to how people describe their domain than the graphical way in which i* concepts are presented. Table 20 shows the difference between the control and treatment groups. Table 20: Difference between the Control and Treatment Groups in Study 2 i* diagrams Control  Treatment  Organisational actor diagrams  Two diagrams: Strategic Dependency and Strategic Rationale Diagrams.  Two diagrams: Equivalent of Strategic Dependency and Strategic Rationale Diagrams using organisational actor concepts. Two diagrams: One diagram: Diagram using all Strategic Dependency organisational actor concepts. and Strategic Rationale Diagrams.  Expected results There should be no difference between the two sets of diagrams. This should show the difference between the two sets of diagrams.  There were several possible outcomes to the study. In both groups the subjects could clearly prefer either the i*diagramsor the organisational actor diagrams, or have no clear preference between the two diagrams; therefore there are nine possible outcomes to the study. The control group should determine whether the presentation of the diagrams affect the judgment of the domain expert. The concepts in the control group are the same, so the only difference should be how the concepts are presented in the diagram. If the experts prefer the i* diagrams then they prefer the i* presentation. If the experts prefer the organisational actor diagrams then they prefer how the organisational actor presentation of information about actors. If there is no clear preference between the two diagrams in the control group then we can say that the presentation of the concepts does not make a significant difference to how the model represents the domain. The interpretation of results from the treatment group is dependent on the results of the control group. If we can establish the effect of the presentation of concepts in the diagram then we can use this knowledge to make sense of what occurs in the treatment group. For instance, if we find that there is no clear preference for the diagrams in the control group, presentation of the concepts does not affect the judgment of the experts, and we find that the treatment group clearly prefers the i* diagrams then we can say that how the i* concepts represent the domain is better than how the organisational actor concepts.  92  To begin the study, each subject was given training that explained the concepts in the i* language and the organisational actor method as previously outlined. The control group was only shown organisational actor concepts that overlap with the i* concepts. The mapping between the organisational actor concepts and i* concepts was determined by a conceptual modeling expert. Therefore when the translated organisational actor diagrams were created they were missing the learning and reasoning concepts. The mapping between the i* and OA concepts are shown in Table 21. Table 21: i* Concepts Represented by Organisational Actor Concepts i* Concepts Organisational Notes Actor Concepts Goal Tasks Soft goals  Dependency link Decomposition link Means-end links  Goal Capabilities, intentions, actions Beliefs, capabilities  Output and perception/input Top task is intention, composed of actions None  There is a direct translation from goals in i* and actor goals. Together the organisational actor concepts form a task. Beliefs are modeled as the assumptions of another actor's soft goals, while capabilities represent the soft goals that the actor itself wishes to fulfill. Dependencies between actors through other i* concepts are modeled as interactions between the actors. Actions are just the details of intentions.  Reasoning represents the connection between goals and tasks like the means end links however reasoning also provides information such as the actor's rationale which is not directly represented by i*.  Once training was completed, the subjects were asked to read the i* and organisational actor diagrams for their respective groups. The scenario was taken from Castro, Kolp, and, Mylopolous (2002) and is about a media retail store (CD's, videos, etc.) that has setup an ecommerce system. We also use the diagrams in Castro et al. (2002) as the strategic rationale and strategic dependency diagrams in our study. The ―translated‖ organisational actor diagrams presented to the control group were created by an independent modeling expert who was able to create equivalents of the i* strategic dependency and strategic rationale diagrams in Castro et al. (2002) using the mapping between organisational actor and i* concepts in Table 20. The organisational actor diagram used in the treatment group was developed by the researcher based on the description provided by Castro et al. (2002) and information in the i* diagrams.  93  The i* strategic dependency, strategic rationale diagrams, the translated organisational actor diagrams of the i* strategic dependency and strategic rationale diagrams and the full organisational actor diagram can be seen in Figures 14, 15, 16, 17, 18, respectively.  Figure 14: i* Strategic Dependency Diagram of the Scenario (Castro et al. 2002)  94  Figure 15: i* Strategic Rationale Diagram of the Scenario (Castro et al. 2002)  95  Customers  Media@  Goal  Goal  Purchase media  Provide means for customer to purchase media  Intention  Intention  Place order Purchase media  Display catalogue Enable searching Provide search results Enable order placement  Beliefs Media @ and Media store stocks media  Actions  Actions  Place order  Display apporpiate catalogue  Select desired media Add media to cart Pay for media  Ordering Process Money Transfer  Capabilities  Purchase Media Take media to counter Pay for media  Capabilities Being able to use a catalogue for searching Being able to place an order Being able to locate media in store  Capable of supporting secure transactions Capable of allowing orders to be processed Capable of supporting money transfer Capable of finding new users Capable of allowing maintainability  Media Store Telecom Company  Goal Increase Market Share Make Customers Happy Enable continuing relationship with suppliers  Intention Purchase media from suppliers Sell media in store Support website Support third party payment transaction  Beliefs Believe that media and media store can increase market share and make customers happy  Supplier  Legend  Actions Find media customers interested in Sell media to Media store  Capabilities  Environment variable Interaction Arrow  Capable of identifying new users Capable of maintaining a continued business with media store  Figure 16: Translated Organisational Actor Diagram of the Scenario (Strategic Dependency)  96  Media@ Goal  Customers  Increase market share  Goal  Process Internet Orders Provide a secure website Provide a maintainable web site  Purchase media from website  Intention  Intention  Search for item Add item to shopping cart Pay for media  Sell Items to Customers Enable order placement Attract New customers Maintain through media shop  Beliefs Media@ stocks the item Media@ allows for item to be added to shopping cart Media@ supports secure transactions  Bank  Beliefs Attract new customers (to increase market share) Sell items to customers (to increase market share) Medi@ can secure its web site Medi@ can maintain its web site  Actions Select desired item Add media to shopping cart Pay for item  Actions  Capabilities  Sell Items to customers Display appropriate catalogue Enable customer to add item to shopping cart Enable customer to get identification detail Enable customer to check out  Capable of using the catalogue to search for item Capable of placing an order in shopping cart Capable of complete payment transaction  Enable Order placement Manage orders through the internet shop Allow phone and fax order Legend  Attract new customers Find new users needs Get catalogue consulting  Environment variable  Interaction Arrow  Maintain through media-shop Monitor system System evolution Update catalogue Update GUI  Media Shop  Capabilities Capable of increasing market share Capable of processing order Capable of securing a secure transaction Capable of maintaining its website Capable of finding user needs Capable of handling classic communication Capable of searching for item Capable of making website usable  Telecom Company Supplier  Figure 17: Translated Organisational Actor Diagram of the Scenario (Strategic Rationale)  97  Figure 18: Organisational Actor Diagram of the Scenario  The subjects reviewed the diagrams for their experimental group and were told that each diagram represented the same process, but from different ―viewpoints‖. Once the subjects reviewed the diagrams, the researcher asked the subjects to perform three tasks. First, we asked the subjects to describe the domain represented in the diagrams, so we could determine whether 98  the subjects understood the domain from viewing the models. Second, we asked the subjects to explain the strengths and weaknesses of each diagram, so we could determine their rationale for eventually choosing one set of diagrams. Lastly, we asked the subjects to select the set of diagrams that best represented the scenario for someone who was unfamiliar with the domain, but was familiar with both conceptual modeling languages, and to explain their choice of diagrams. This was done to determine which set of concepts best represented the domain. The subjects‘ verbalisations during the three tasks were recorded and any interesting insights from the subjects prompted the researcher to ask more detailed questions. 3.2.3 Results By comparing the answers provided by the subjects, we found that most people in the treatment group judged the organisational actor diagram to better represent the domain, but in the control group there was no clear preference between the organisational actor diagrams and the i* diagrams. In Table 22, we show each subject‘s comments on the strengths and weaknesses of the i* diagrams and the organisational actor diagrams, and which diagrams they suggested to show to domain novices to teach them about the business process. Table 22: Results of the i* and Organisational Actor Concepts Study Subject Group i* diagrams Actor diagrams Strengths Weaknesses Strengths Weaknesses 1  Treatment  Nice and simple.  Harder to identify actors.  More information about actors.  2  Treatment  Strategic dependency diagram is easy to read.  Takes too much time to determine the business process  3  Control  Provides a good overview of the process.  4  Control  Strategic rationale diagram is very complicated. Complicated.  More detailed and it classifies the scenario information (goals, beliefs, etc.). Easy to identify actors.  Splits the information into easy to see concepts.  Complicated and "scary to look at".  Suggested Set of Diagrams Actor diagrams  Actor diagram  Very hard to determine the relationship between actors.  I* diagrams  Translated Actor diagrams  99  Table 22: Results of the i* and Organisational Actor Concepts Study Subject Group i* diagrams Actor diagrams Strengths Weaknesses Strengths Weaknesses 5  Control  I* provides a basic overview of the process and can represent relationship s. Strategic dependency diagram is easy to read.  Does not show details of the actor.  6  Treatment  7  Control  Shows how actions lead to one another. Better represents the process.  8  Treatment  If you spend a lot of time on the models you can learn a lot.  Hard to understand the strategic rationale diagram. The goal of the actor is not clearly stated. It is also difficult to know where to start. Too much information in strategic rationale diagram.  9  Treatment  At a glance you can understand the relationship s and the Strategic rationale diagram are detailed.  Focuses too much on relationships and not the actors.  The strategic rationale diagram is too complex.  Suggested Set of Diagrams  Represents details of the actor which can be used to derive relationships between actors. You "know where to start" .You can progress from goals to intentions, and so on. You clearly see what the diagram represents. Actor details could be used to derive more about the domain.  Information is too "condensed" and relationships are not represented well.  Translated Actor diagrams  The diagrams seem too simple. Also it is difficult to determine how one action leads to another.  i* diagrams  Made the interactions more clear and provides more information about the actor. It can also explain the process better. It provides a good overview of the actor.  The interactions can sometimes be confusing.  Actor diagram  Does not represent the relationships between actors.  i* diagram  Actor diagram  100  Table 22: Results of the i* and Organisational Actor Concepts Study Subject Group i* diagrams Actor diagrams Strengths Weaknesses Strengths Weaknesses 10  Control  Relationshi ps are well represented .  Missing some details like intention so it is hard to know how the goal is achieved.  Informative and logical.  Relationships are not very well represented. It is also harder to read.  Suggested Set of Diagrams i* diagrams  The subjects‘ answers in Table 21 show that both the concepts and their presentation have an effect on the subjects‘ decision to choose one set of diagrams over the other. Subjects in both the treatment and control group chose the organisational actor diagrams when they were interested in understanding the actors‘ details, because they found the diagrams present an ―actor focused‖ diagram. Subjects in both studies also stated that the strength of the i* diagrams was that they better presented the relationship between actors than the organisational actor diagrams. There were also differences between the treatment and control groups which suggest that the organisational actor concepts are useful to modelers. In Table 21, we can see that even though most people in the control group stated that the translated organisational actor diagrams present an actor focused view of the domain, there was no preference for one set of diagrams over the other; however most domain experts in the treatment group judged the complete organisational actor diagram to be better than the i* diagrams. 3.2.4 Threats to Validity There is a threat to the internal validity of this study because there another difference exists between the i* and organisational actor diagrams beyond just the concepts. We tried to maintain internal validity by creating a control group that would show the same type of concepts as the i* framework, but use the organisational actor notation so that we could test if the presentation of the concepts or the concepts themselves led to subjects choosing one set of diagrams over the other. However, in the treatment group, subjects had to choose between using one organisational actor diagram and two i* diagrams to communicate with a novice. One possible criticism is that subjects chose the organisational actor diagram because it had only one diagram and was easier to read than the two diagrams in i*, and it was not because the organisational actor concepts were more representative.  101  Although there is an issue with internal validity, we suggest that the evidence indicates that the number of i* framework diagrams is not problematic. Of the four subjects in the treatment group who chose the organisational actor diagram, two (subject 6 and subject 8) implicitly mentioned that the learning and reasoning concepts were the strengths of the diagram. Subject 6 stated that he chose the organisational actor diagram because it was possible to trace how goals, intentions and actions were connected in the organisational actor diagram and Subject 8 stated that it was easier to explain the reason for the processes with the organisational actor diagram. In both instances learning and reasoning provided important information for the subjects to help understand the domain Also, there are no threats to the construct validity, external validity and reliability of the study. Construct validity is not an issue, since this study measured the domain experts' opinion on which type of diagram was more useful for communicating with a novice, and the study measured the experts' opinions. External validity is not an issue because the subjects chosen as domain experts were people with no technical background or special skill other than that they were experts in shopping online. Therefore, the study's results can be generalised to a larger population of experts involved in an organisational process. And lastly, the study is reliable because the researcher asked all subjects the same three questions in the same order, and the subjects were trained in the different conceptual modeling concepts through a slide presentation controlled by the subjects. If other researchers were to use the same presentation and questions in their studies then they should provide them with similar results. Therefore, the study shows that if domain experts are presented with a diagram that represents how an actor makes decisions (reasoning rules) and forms it assumptions about the world (learning criteria) then they will want to use this model over other models. The results also validate the organisational actor metamodels since some subjects liked to trace the behaviour of the agents, which could only be done with an organisational actor diagram that followed the dynamic metamodel discussed in Chapter 2.  3.3 Study 3: Determining the Need for an Organisational Actor Modeling Method Vessey (1991) states that, according to cognitive fit theory, if the analyst does not have a mental representation of the domain that fits with the problem solving task then it will be harder for the analyst to find a solution to the problem. Specifically, "for most effective and efficient problem solving to occur, the problem representation and any tools or aids employed should all 102  support the strategies (methods or processes) required to perform that task" (Vessey & Galletta 1991, p. 69). A method for organisational actor modeling may not be needed since using any structured method could be less efficient than using the intuitive process that a modeler applies to organisational actor modeling. As we have seen in Study 1, some of the organisational actor concepts are very intuitive, and it is possible that the use of an external method could be less suited than the intuitive process that modelers use. If a method is needed, then it must be more appropriate for representing a domain using organisational actor concepts than an intuitive process, meaning that using a method makes the modeling process more efficient and effective than not using a method. Therefore, in this study we will determine whether a method can aid modelers to more efficiently and effectively create representations of the domain using organisational actor concepts than not using a method. 3.3.1 An Organisational Actor Modeling Method for Study 3 To study the need for a modeling method, we developed an organisational actor modeling method that guided the use of only the action, reasoning, perception/input, and output concepts rather than use the organisational actor method developed in Chapter 2. We decided to develop this focused method for the study because we found that the organisational actor method led to cognitive overload for the subjects. We conducted a pre-test of this study using the organisational actor method. In the pre-test we wanted to determine if the organisational actor method was usable for the subjects. We presented a small example case of application for a meal plan at a graduate residence and also provided the Method to the subjects. For the test, we recruited four subjects who had extensive conceptual modeling experience and knowledge of organisational actors. The subjects spent, on average, 60 minutes modeling the domain. We found that the experts could use the organisational actor method and seemed to find it helpful for representing the domain. However, for a more extensive study, we could not use the pre-test format because if we were to replicate this study with subjects who had no previous experience with organisational actors and / or no modeling experience, each session would have lasted close to approximately two hours per subject. We deemed this too much for the subjects, and so decided to use a more focused conceptual modeling method for this study.  103  We then had to decide which organisational actor concepts the focused method would help modelers to use. We included the reasoning and action concepts in the method because, as shown in study 1, these are concepts that people intuitively use when describing the domains. If a method can be used to help modelers represent salient concepts, we can say that a method will be useful to modellers even when they intuitively know how to use the concepts. We included the perception/input and output concepts in the method because they are, according to study 1, not very salient organisational actor concepts. In fact, the perception/input concept is so nonsalient that we decided, for this study, to merge the perception/input and output concepts into a new concept called Interaction. As mentioned in Chapter 2, perceptions and output can be used to represent interactions with the world that are the direct result of actions. We chose to include these concepts because we wish to test whether the method can be used to help modellers represent non-salient concepts that describe an actor. To represent the actions, reasoning, and Interactions concepts, we developed five steps for the focused method. The first step was to identify the actors in the scenario. This is done by determining if the entity has the abilities of an actor, i.e. if it can learn, reason and act. The second step of the method was to identify and model the actions of each actor, and the third step was to represent the actor's reasoning. We identified these concepts first because, according to study 1, people are most likely to think about these concepts when describing actors in the domain. The fourth step was to identify objects in the scenario, which are defined as entities that cannot act, reason, or, learn because the perception/input and output concepts represent objects in the environment that the actor interacts with. We propose that once people identify the actors‘ actions, they will be able to recognize the objects that are involved in the action. The fifth step was to identify and model the actor's interactions, which are the consequences of the action on the objects. Each action must produce an interaction with an object or another actor. The actor also may interact with another actor by interacting with objects that interact with other actors. A summary of the focused method and how it can be used to represent a scenario is shown in Table 23. Figure 19 shows the resulting organisational actor diagram of the scenario in Table 21.  104  Table 23: A Method for Some Organisational Actor Concepts in a Scenario Method Step Example 1. Identify and model actor. 2. For each actor identify the actions and mention them in the actor details. Use action verbs. All actions should be mentioned in one box in the actor details. 3. For each action determine the rationale or reason for the action. All reasons should be mentioned in one box (below actions) in the actor details. 4. Identify and model objects.  5. For each action identify the interaction. Interactions can be connected through an object, directly to another actor or to another actor through an object.  Holly and Scott are actors as they can decide on on how to act. Holly gives a ball, Scott thanks her.  If a ball is present then Holly gives a ball, If given a ball then Scott thanks. Ball is an object since it is something in the environment but does not decide how to act. Holly interacts with the ball and Scott interacts with the ball. Scott interacts with Holly.  Figure 19: Organisational Actor Diagram of an Example Scenario  3.3.2 Experimental Design As mentioned, the purpose of this study is to determine whether a method can aid modelers to more efficiently and effectively create representations of the domain using organisational actor concepts in comparison to not using any method. In this study, we operationalise the efficiency of a method as how much effort is needed to use a method. If a method leads to less difficulties for the modeler and can provide the modeler with an easy and structured process to create the conceptual modeling diagrams, the modeling process is efficient. We operationalise the effectiveness of a method as the accuracy, completeness, and organization of the conceptual modeling diagrams developed using a method. We define accuracy as the ability of the diagram to correctly represent the domain in the model, completeness as the diagram's ability to represent all phenomena in the domain needed to describe the actor in the domain, and organization as the aesthetic value of the diagram. If the user misrepresents the scenario using the method, then the method is not effective. We divided the investigation of the effectiveness and efficiency of the focused method into two experiments. The first experiment tested whether the focused method was useful for modeling novices, and the second experiment tested whether the focused method was useful for 105  expert system analysts. In both experiments, subjects represented an Internet shopping scenario using the organisational actor concepts. Below is the description of the scenario given to the subjects: The Internet Sales System will have a database of basic information about the CD's that it can sell over the Internet Every day, the Internet Sales System will receive an update from the distribution system that will be used to update this CD database. Some new CDs will be added, deleted, and revised (e.g., a new price). The Electronic Marketing Manager will also have the ability to update information (e.g., prices for sales) and create summarized weekly reports of sales to the General Manager. The General Manager gets reports from managers of all departments to determine the financial health of the company and the budgets of all departments for the following year. The Internet Sales System will also maintain a database of marketing materials about each CD that will help Web Users learn more about them. Vendors will use their discretion to decide which CDs they want to market and will be able to e-mail marketing materials (e.g. sample sound clips) to the manager. The EM Manager will go through the e-mails and the information will be added to a marketing materials database (or revise it or delete old information), which will be linked to the Web site. Customers will access the Internet Sales System to look for CDs of interest. Customers will be able to search for CDs by name, artist or genre. When the customer has found all the CDs he or she wants, the customer will be able to purchase the CDs through the Internet Sales System. Once the payment has been made the order is sent to the order database and every hour the distribution system pulls out orders from the order database and handles the actual sending of the CDs. We developed this scenario based on the Internet Shopping scenario given by Castro et al. (2002) for several reasons. First, we decided to build a scenario that had all of the elements that we wanted to test, actions, Interactions and reasoning. Second, we wanted to use a scenario that was familiar to most people, but not so familiar that they were able to use their domain knowledge alone. Third, the scenario involved many actors who had to interact with each other in multiple ways. Fourth, we wanted to ensure that subjects would have to think about the interactions between the different actors. Finally, the scenario also included an actor that was not human; therefore the subjects would have to understand precisely what an actor was to correctly represent the domain. After the subjects modeled the scenario, we analysed the subjects‘ modeling process through protocol analysis which identified and measured the inefficiencies of the subjects‘ modeling process. According to Ericsson and Simon (1984), in protocol analysis participants verbalize their thought processes while conducting a task. This verbalisation is referred to as a verbal protocol, and protocol analysis is a qualitative method that analyses these protocols. Some 106  studies use protocol analysis to "examine the content and sequence of information that is contained within the verbal protocol, while others might focus on the content alone" (Green 1998, p. 2). We conducted two types of protocol analyses; the first analysis identified problems in the subjects' modeling processes and the second analysis identified the sequences of tasks used by the subjects to model the domain. In the first analysis, we identified which modeling tasks caused difficulties for the subjects, and whether the subjects explicitly or implicitly stated having problems with the task. We classified that a subject had an explicit problem when the subject mentioned that there was a problem with the modeling process. We classified implicit problems as when the subject was obviously struggling with the task, such as adding and deleting the same concept, but did not state that there was a problem with the modeling process. When the subjects implicitly had problems, the subjects sometimes corrected their mistake or solved their issue, and we classified this as an ―implicit-recovered problem‖. The second efficiency analysis traced the subjects' modeling processes by identifying when the subject created, modified, or deleted an action, organisational actor, reasoning, interaction, or object in their diagram. The criterion for efficiency in the first analysis was how many problems the modelers had while representing the scenario. In the second analysis; if the modeling process was erratic then it was identified as inefficient. We also analysed the organisational actor diagrams created in the experiments to measure the effectiveness of the focused method. Two modeling experts judged the quality of the diagrams using a questionnaire. The questionnaire consisted of six questions with questions 1 and 2 evaluating the accuracy of the diagrams, questions 3 and 4 evaluating the completeness of the diagrams, and questions 5 and 6 evaluating the organization of the diagrams. We asked two questions for each category so that we could record how accurate, complete and organized the actors were represented. The first question in the set is used to determine how accurate, complete, and organized the relationships are between the actors. We want to measure the quality of the relationships because we want to ensure that the connections between actors in the domain are well represented. The second question in each set measures the general accuracy, completeness and organisation of the diagram itself. The judges used a 7-point Likert scale ranging from ―not at all‖ to ―to a great extent‖ when answering each of the questions. Below is each specific question in the questionnaire:  107  1. To what extent do you think the relationships among agents represent the relevant aspects of the case description accurately? 2. To what extent do you think the diagram represents the case description accurately? 3. To what extent do you think the relationships among agents represent the relevant aspects of the case description completely? 4. To what extent do you think the diagram is a complete representation of the case description? 5. To what extent do you think the connections among the agents are well organized visually? 6. To what extent do you think the diagram is well organized visually? In the rest of this section we will identify the specific propositions, subjects and method of the two experiments and mention the results of the research. 3.3.3 Experiment 1: Exposing Novice System Analysts to a Method Alexander and Maiden (2004) state that people intuitively use concepts similar to the organisational actor concepts when describing their domain, so modeling novices should be able to use the concepts to represent a domain. But modeling novices may also need guidance to efficiently and effectively represent the domain using the organisational actor concepts, because the concepts are not as intuitive as simply describing the domain. Unfortunately, teaching a detailed method to modeling novices may overload the modelers and be very time-consuming. So if providing an example of the method being used, rather than a detailed process, could help modelers to better represent the domain then this would be a very simple way of helping novice modelers. Therefore, the objective for the first experiment is to determine whether exposure to a modeling method aids non-technical analysts in using organisational actor concepts to represent a domain. In this section we will discuss this propositions, subjects, method and results of this experiment. 3.3.3.1 Propositions For this experiment, we propose that if non technical modelers are exposed to an example of a modeling method being used to represent a domain then the modelers will more efficiently and 108  effectively use the organisational actor concepts than modelers not exposed to a method. We measure efficiency by how many breakdowns the subjects have and the erratic nature of the modeling process. We measure effectiveness by how well the diagrams created by the method can represent the domain. More specifically, we propose that: P1: Novice system analysts who are exposed a method will be more efficient than those who are not exposed to a method when modeling actions. P2: Novice system analysts who are exposed to a method will be more efficient than those who are not exposed to a method when modeling interactions. P3: Novice system analysts who are exposed to a method will be more efficient than those who are not exposed to a method when identifying actors. P4 Novice system analysts who are exposed to a method will be more efficient than those who are not exposed to a method when modeling reasoning. P5: Novice system analysts who are exposed to a method will be more likely to follow a pattern than those who are not exposed to a method when modeling the domain. P6: Novice system analysts who are exposed to a method will create more complete diagrams when representing a domain than those who are not exposed to a method. P7: Novice system analysts who are exposed to a method will create more accurate diagrams when representing a domain than those who are not exposed to a method. P8: Novice system analysts who are exposed to a method will create more organised diagrams when representing a domain than those who are not exposed to a method. 3.3.3.2 Subjects We recruited sixteen undergraduate students, who had taken a maximum of two courses involving conceptual modeling and system analysis, from a large Northwestern University in North America. The subjects had also shopped online within the last month and, therefore, would be very familiar with the scenario used in the experiment. 3.3.3.3 Method In the experiment we split our subjects into a control and treatment group. The control group was not exposed to the method and the treatment group was exposed to the method. Both groups were given learning material that taught them how to use a specialized version of a modeling program (Microsoft Visio) to use actions, reasoning, and interactions to represent 109  actors in a domain. All subjects were also taught about the action, reasoning, and Interaction concepts in the teaching material. The difference between the groups was that the treatment group received material that showed the process of an organisational actor diagram being built according to the focused method. Those in the treatment group were not told that this was a method, only that it was an example of creating an organisational actor diagram. Those in the control group were also shown an example of an organisational actor diagram but were not shown the process of creating the diagram. After training, subjects were given a practice scenario to model. During the practice session they could ask questions and be corrected on any mistakes they made. The subjects were given the Internet shopping scenario discussed in Section 3.3.2. Theycould not ask questions, and all sessions were videotaped. As mentioned, in Section 3.3.2 we conducted protocol analyses to study the modeling process of the modelers and a questionnaire to judge the quality of the diagrams developed by the modelers. In this experiment, for both efficiency analyses the two coders had an inter-rater reliability of 0.75 and for the questionnaire the two judges had an inter-rater reliability of 0.77. 3.3.3.4 Results The first analysis of the efficiency of the subjects' modeling processes showed that subjects in the control group suffered more problems during the modeling process than those in the treatment group. Examples of the explicit problems were: "I think that the customer is an object... no wait agent" "I'm really having problems with figuring out how this interaction happens." "There probably is an interaction here" We also identified the number of times the subjects had difficulties with the modeling process and the type of breakdown, but we did not include the reasoning concept in our analysis. Only one subject in the treatment group modeled reasoning. In Table 24 we show the number and types of problems for each subject and each modeling task.  110  Table 24: Breakdowns in Subjects' Modeling Process (Experiment 1) Actions Subject Group  Subject  Expli -cit  Implicit (recove -red)  Treatment  1 2 3 4 5 14 15 16 Total 6 7 8 9 10 11 12 13 Total  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0  0 0 0 0 0 1 0 0 1 0 0 0 1 0 3 0 1 5  Control  Interactions Implicit (not recover -ed) 1 1 1 1 0 2 2 0 8 2 3 7 0 1 1 3 2 19  Explicit  0 0 0 0 0 0 1 0 1 0 0 0 0 0 0 0 0 0  Implicit (recove red) 0 0 1 1 1 1 1 0 5 1 0 2 2 0 0 1 2 8  Organisational Actor Identification Implicit (not recover ed) 1 0 2 2 1 2 0 0 8 0 0 1 0 0 1 1 0 3  Explic it  Implicit (recove red)  0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1  0 0 0 0 1 0 0 0 1 1 1 0 0 0 0 0 0 2  Implicit (not recover ed) 1 2 0 0 0 1 0 0 4 9 0 2 0 0 0 1 1 13  The results in Table 24 provide some support for P1 and P3; more subjects in the control group suffered implicit breakdowns than those in the treatment group when modeling actions and identifying organisational actors. However we did not find support for P2 because the treatment group suffered more breakdowns when representing interactions than the control group. This means that exposing novice modelers to a new method may hinder their confidence in representing the interaction between actors. As mentioned previously, we could not find evidence for or against P4 because only one subject in the treatment group represented reasoning in his model. For the second analysis of the subjects' modeling efficiency we produced graphs of the modeling process for some subjects in the control and treatment groups. In the graphs, the x axis represents the number of the task in the modeling sequence. Each action that the modeler took was recorded and the x axis presents the number of the action in the sequence. For instance, if the modeler performed fifty actions to model the diagram then the line would end at 50 along the x axis. The y axis does not measure a particular variable but acts as a way of visualizing how the modeler‘s 111  actions evolved during the modeling sequence. As a modeler switched from one task to another, the line would move up or down on the y axis. For example, if the fourth action that the modeler took was to represent an actor and the fifth step was to represent an action, then the line at 4 on the x axis would be at a different level of the y axis then the line at 5 on the x axis. However if the modeler represented an actor in the 4 and 5 step of the modeling sequence then the line would be at the same level. The graphs in Figure 20 show the sequence of random subjects in the control and treatment groups.  Sub7 Sub 9 Sub10  1  4  7  10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58  Number of Task in the Sequence  Sub1 Sub 3 Sub 2  1  3  5  7  9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49  Number of Task in the Sequence  Figure 20: Subjects’ Modeling Processes (Experiment 1) Above: Control Below: Treatment  112  Due to the difficulty in visually determining if there are more straight lines in the treatment graph in Figure 20 than in the control graph, we found some support for P5. This means that typically, those in the treatment group performed a series of the same modeling task. On the other hand, those not exposed to the method moved erratically from one modeling task to another, for example, modeling an actor, then an action, and then an actor again. When analysing the effectiveness of the modeling process we discovered that there was no support for P6 – P8. Table 25 shows the average quality of the diagrams in the control and treatment groups based on the questionnaire.  Table 25: Average Quality of Organisational Actor Diagrams (Experiment 1) Accuracy Completeness Organization Average Quality Control Treatment  Q1 4.19 4.0  Q2 4.44 4.25  Q3 4.63 4.38  Q4 4.38 3.88  Q5 4.56 4.25  Q6 4.44 4.25  4.44 4.17  Table 24 shows that the diagrams created by those who were exposed to the method were less complete, accurate, and organized than those who were not exposed to the method. However, since the sample size is small, it is difficult to know whether this is a significant difference between the two groups. From these results we see that being exposed to the method leads to a more efficient modeling process for modeling novices, but that simply exposing them to the method is not enough to help them build better models, in fact it may confuse them. We also discovered that most of the novice modelers did not represent the reasoning concept. We did not ask specifically why the subjects did not represent reasoning. However, looking over the transcripts we found that most modelers were exhausted with the exercise and may have decided it was something they did not have to represent. 3.3.4 Experiment 2: Giving Expert System Analysts a Method To ensure that the results from this Study were robust we also tested whether expert system analysts needed a method. Sutcliffe and Maiden (1992) have shown that expert system analysts are better at building conceptual models of a domain than novices; therefore, we assumed that even if a method helped novices, only a very useful method would increase the efficiency and effectiveness of the modeling process for expert system analysts.  113  The objective for this second experiment was to determine whether giving a modeling method to expert system analysts helps them to use the organisational actor concepts to represent a domain. In this section we will discuss the propositions, subjects, method, and results of this experiment. 3.3.4.1 Propositions In this experiment we test whether expert system analysts find a method useful when representing a domain using organisational actor concepts. We propose that expert system analysts will not need a method to more efficiently and effectively represent a scenario than those who do not use a method. More specifically: P1: Expert system analysts who use a method will not be more efficient than those who do not use a method when modeling actions. P2: Expert system analysts who use a method will not be more efficient than those who do not use a method when modeling interactions. P3: Expert system analysts who use a method will not be more efficient than those who do not use a method when identifying actors. P4 Expert system analysts who use a method will not be more efficient than those who do not use a method when modeling reasoning. P5: Expert system analysts who use a method will not be more likely to follow a pattern than those who do not use a method when modeling the domain. P6: Expert system analysts who use a method to represent a domain will not create more complete modeling diagrams than those who do not use a method. P7: Expert system analysts who use a method to represent a domain will not create more accurate modeling diagrams than those who do not use a method. P8: Expert system analysts who use a method to represent a domain will not create more organized modeling diagrams than those who do not use a method. 3.3.4.2 Subjects We recruited ten management information systems graduate students from a large South Central University in North America, with 2-3 years software development experience and who had completed at least three courses involving conceptual modeling and system analysis. 114  With their extensive background in management information systems and conceptual modeling, we regard these subjects as conceptual expert system analysts. 3.3.4.3 Method In this experiment we split our subjects into a control and treatment group. Both groups were given learning material that taught them how to use a specialized version of a modeling program (Microsoft Visio) to use actions, reasoning, and interactions to represent actors in a domain. All subjects were also taught about the action, reasoning, and interaction concepts in the teaching material. The difference between the groups was that the treatment group received material which explained, step-by-step the focused method from using actions, reasoning, and interactions to represent a domain. Those in the control group were shown an example of an organisational actor diagram but were not shown any process of creating the diagram. After training, subjects were given a practice scenario to model. During the practice session they could ask questions and be corrected on any mistakes they made. The subjects were given the Internet shopping scenario shown in Section 4.2. They could not ask questions, and all sessions were videotaped. 3.3.4.4 Results In the analysis of the subjects‘ efficiency, we first identified the number of modeling problems that the subjects suffered, and classified the problems based on the modeling tasks and how the subjects' dealt with the confusion. Unlike Experiment 1, the experts did represent reasoning in their diagrams. In Table 26 we show the number and types of problems that the subjects suffered.  115  Table 26: Breakdowns in Subjects' Modeling Process (Experiment 2) Actions Interactions Organisational Actor Identification Subject Subj group ect  Expli cit  Control  1 2 3 4 5 6 Tot al Treatm 7 ent 8 9 10 11 12 Tot al  Implic it - not recove red 1 2 0 2 1 1 7  Expli cit  0 0 0 0 0 0 0  Implic it – recove red 0 0 3 0 0 1 4  Implic it - not recove red 1 0 0 0 0 0 1  Expli cit  0 0 0 0 0 0 0  Implic it – recove red 2 0 1 0 2 1 6  1 0 0 0 0 0 1  1 1 1 1 0 0 4  0 0 0 0 0 0 0  0 0 0 0 0 1 1  1 1 0 1 0 1 4  0 0 0 0 0 0 0  Reasoning  0 0 0 0 0 0 0  Implic it recove red 0 1 0 0 0 1 2  Implic it - not recove red 0 0 0 0 0 0 0  Expli Implic Implic cit it it - not recove recove red red 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0  0 0 0 0 0 0 0  0 1 0 1 1 1 4  0 0 0 0 1 0 1  0 0 0 0 0 0 0  0 0 0 0 0 0 0  0 0 0 0 0 0 0  From the results in Table 25, we do not see evidence for P1, since those in the treatment group had less implicit non-recovered breakdowns than those who did not use the method when representing the actors‘ actions. However, there is some evidence for P2, P3 and P4, since the treatment group had a similar number of problems when representing interactions and reasoning and identifying organisational actors as the control group did. In the second efficiency analysis, as in Experiment 1, we graphed the modeling process of six random subjects from the control and treatment groups. And as in Figure 20, if the graphs showed more straight lines it indicated that the modeler did not follow an erratic pattern when representing the domain. These graphs can be found in Figure 21.  116  Sub 4 Sub 2 Sub 3  1  4  7  10 13 16 19 22 25 28 31 34 37 40 43 46 49 52  Number of Task in the Sequence  Sub 7 Sub 9 Sub 8  1  4  7  10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55  Number of Task in the Sequence  Figure 21: Subjects’ Modeling Processes (Experiment 2) Above: Control Below: Treatment  Figure 21 does not support P5, since the graphs for the control group have more peaks and valleys which indicate more erratic modeling processes than the graphs for the treatment group. When analysing the effectiveness of the modeling process we found that P 6 – P8 were not supported. Table 27 shows the average quality score of the organisational actor diagrams for the treatment and control groups. Table 27: Average Quality of Subjects’ Diagrams (Experiment 2) Accuracy Completeness Organization  Control Treatment  Q1 4.25 5.58  Q2 4.08 5.42  Q3 4.25 5.5  Q4 4.25 5.42  Q5 4.33 5.33  Q6 4.5 5.33  Average Quality 4.28 5.43  117  Table 27 shows that the average quality of the diagrams created by those in the treatment group were judged to be more accurate, complete, and organized than diagrams created by those in the control group. 3.3.5 Threats to Validity As in the previous studies we will discuss the threats to the validity of the two experiments. External and internal validity of the study was threatened in this study. The scenario used by the subjects was a very simple example. It is possible that the results cannot be generalised to a more complicated scenario. Also one of the main ways of gathering information about the domain is to interview people. However, in the study, the subjects used a pre-existing description of the domain to model it. It is possible that results would change if modelers, unrestrained by a method, were able to ask questions about the domain and clarify their understanding of the domain. There is also the issue of whether agent modeling languages other than i* would compare favourably against the organisational actor diagrams. Looking at the discussion in Section 1.2, we would state that other languages would fair just as well as or worse than the i* framework. Gaia, ROADMAP and AORML are used to represent the domain for designing purposes and may include notations and symbols that would confuse the model readers more than i* or the organisational actor diagrams. The MibML language can also be used to represent actors in the domain, but would not be able to represent this case because it only represents changes in information and not actual changes in the environment. Study 2 also shows that when the i* framework was chosen it was because it was simple and the organisational actor diagrams were chosen because it was easy to identify actors and trace their behaviour. ROADMAP and Gaia do not represent the internal processes of the actor so like i*, they have a disadvantage in tracing the behaviour of actors. AORML is also an issue because it has many different diagrams to show how to trace the behaviour of actors involved in many processes in the domain. For each process an interaction pattern diagram would have to be created to represent the domain or the same processes will have to be on the same diagram. However this leads to another problem since many individuals found the multiple processes to be confusing when represented in the i* strategic rationale diagram and these diagrams would be just as complicated. Therefore the modeling languages discussed in 1.2 would either not represent the domain as well as i*, or the resulting diagrams would be more complicated than i* or the organisational 118  actor diagram. However, for future research it would be interesting to determine the strengths and weaknesses of these other languages and determine how non-technical individuals rate the efficacy of the languages‘ diagrams. Internal validity is threatened by the novices being too exhausted to represent the reasoning in the diagrams. This may be an issue because if novices did represent reasoning then it may have shown that a method provided significant help for novices when modeling the domain. There are no issues with the construct validity and reliability of the study. Construct validity is not violated because we tested the effectiveness of the model by asking modeling experts to judge how well the models represented the domain. Efficiency was measured by breakdowns, which represent problems with using the method and by graphing the modeling process which shows the pattern of actions the modelers used during the process. Reliability is also not violated since the procedures for training the users and analysing the data are very clear and can be followed by another researcher. Even with these limitations, we can state that the first experiment showed that non-technical users can intuitively use some of the organisational actor concepts to model the domain. It also verified that some guidance can make the process easier. Exposure to a method can help modeling novices to represent the domain more efficiently and less erratically. Unfortunately, being exposed to a method does not provide modeling novices with enough guidance to create more effective representations of the domain. From the results of the second experiment, we can state that a method can provide guidance for expert system analysts by making the modeling process slightly more efficient and by helping them to create more representative models than expert system analysts not using the method. We found that a method aided in reducing the number of implicit and recovered problems that modelers suffer when representing actions, made the experts‘ modeling processes more stable and increased the accuracy, completeness, and organization of the diagrams. From these results we propose that modelers should use a method when representing a domain with organisational actor concepts.  3.4 Study 4: Determining the Usefulness of the Organisational Actor Method As mentioned in Table 14, in this study we determine whether the organisational actor method developed in Chapter 2 can be used to gather domain information from an expert to determine whether the method is useful for representing the domain. This is an appropriate 119  validation of the organisational actor method because, according to Bolland (1978), traditionally much of the information gathered in system analysis is from employee interviews. We propose that the organisational actor method will guide us in systematically gaining the knowledge from individuals and organizing it in a coherent way. This process is similar to the expert systems analysis technique called knowledge acquisition and we will use the organisational actor method as a way to guide our acquisition of the expert‘s knowledge. Knowledge acquisition is technique used to build expert systems, which are information systems that mimic a ―human expert's problem solving behaviour‖ (Takashima 1986, p. 31). According to Scott, Clayton, and Gibson (1991), knowledge is defined as the information needed to perform a problem solving task, and knowledge acquisition as the gathering of information ―to achieve a coherent understanding of the process of which another person carries out some activity‖ (Scott et al. 1991, p. 485). The knowledge acquisition process has four steps (Scott et al. 1991); Step 1: the initial interview, Step 2: a review of a particular case, Step 3: understanding the expert's reasoning, and Step 4: obtaining in-depth understanding of the case for the expert system. In Step 1, the knowledge engineer gives hypothetical cases to the expert and the expert responds with what he or she would do in the situation. According to Scott et al. (1991) most of these questions are concerned with what the expert wants to do on the job and their knowledge about the job. In Step 2, the knowledge engineer observes the expert performing a task. In Step 3, the knowledge engineer infers the expert's strategy (what the expert does in a situation and when). Finally, in Step 4 the knowledge engineer uses the information gathered in Step 2 to walk through the process with the expert and determine important characteristics of the expert system such as, specific examples that the expert system will have to deal with, ways that the expert system will obtain information, and the output of the system's results. We propose that the organisational actor method can be used for knowledge acquisition because it identifies concepts which are elicited in the knowledge acquisition process. In Step 1, the intentions and perceptions/inputs are identified because the knowledge engineer is determining the type of things the expert sees on the job and what things they want to do on the job. In Step 2, the knowledge engineer identifies the actions, capabilities, and output of the expert, since the knowledge engineer observes the expert performing a task and can see all of the external states and processes of the expert. In Step 3, the knowledge engineer identifies the beliefs, reasoning rules, goals, and intentions of the expert since these concepts represent the 120  expert‘s decision-making and strategy for solving problems. In Step 4, the knowledge engineer identifies the learning, beliefs, perception/inputs and outputs of the expert system so that the developers know how the system will obtain and interpret information, and what type of outputs it will provide to the user. In Table 28, we list the knowledge acquisition steps outlined by Scott et al. (1991) and present the organisational actor concepts that are elicited by each step. Table 28 Organisational Actor Concepts Elicited in the Knowledge Acquisition Process Knowledge Acquisition Steps (Scott et al. 1991)  Organisational Actor Concept  Step 1: Initial Interview  Intentions, perceptions/input  Step 2: Case observation  actions, capabilities, output  Step 3: Understand the Expert's reasoning Process  reasoning rules, intentions, beliefs, goals  Step 4: In depth expert understanding  learning, perceptions/input, beliefs, output  Table 27 shows that the organisational actor concepts can be elicited from the knowledge acquisition steps, but the information gathered in the process is put together as cases and not as specific characteristics of the expert. This is very similar to the problem scenarios as mentioned in Chapter 1 where a narrative was created to represent the domain. Unfortunately, a narrative is difficult to analyse so some knowledge engineers create flowcharts of events in the cases. However, flowcharts alone cannot capture the context of the situation and researchers have determined that when representing work processes in flow charts, more is needed to represent the domain (Hwang & Tang 2004). So, in this study we used the organisational actor method to create a knowledge acquisition technique that could gather information from an expert performing unstructured organisational processes. We used the disaster management domain in this study since we were already conducting work in this area and it fit the purpose of this study. It is an ideal domain for representing actors performing unstructured work, who must interpret the world and make decisions (Monu & Woo 2009). Also, very few people have been in an actual disaster and it would be beneficial to capture the knowledge of departing professionals before they are no longer available. 3.4.1 Subject We interviewed a senior disaster management professional in the Emergency Operations Centre at a large Northwestern university. The expert is responsible for campus emergency planning and consulting on safety and emergency matters throughout the university.  121  3.4.2 Method In this study we created a knowledge acquisition technique that is guided by the organisational actor method and determined how we would use this modified knowledge acquisition technique in our study. 3.4.2.1 An Organisational Actor Guided Knowledge Acquisition Technique As shown in Table 29, there are thirteen steps to the organisational actor method; however we only used eight of the steps. We did not need to use Steps 1 – 4 for this study since we had identified the actor to be modeled. We also did not use Step 13 because we did not need to identify non-actor dynamic entities that do not affect, or are not affected by, the expert. Table 29: Organisational Actor Method Method Steps 1) Identify the stakeholders 2) Identify goals of stakeholders and choose appropriate stakeholders for the model 3) Identify actors that interact with the stakeholder(s) and include them in the model. 4) Choose an actor 5) Identify the actors' goals and determine those that are appropriate for the model based on the stakeholder(s). 6) Based on the goals of the actor, determine the intentions of the actor that are part of the domain. 7) Determine the circumstances under which the intentions will be enacted. 8) Identify beliefs from circumstances and determine reasoning rules for intentions. 9) Determine how beliefs change, and identify perceptions/input or beliefs that may be needed to achieve this and model only "complex" learning. 10) Determine the tasks (actions) needed to carry out intentions. 11) Determine the output of the actions 12) Determine the capabilities needed to perform the task (action). 13) Determine the non-actor dynamic entities that indirectly interact with the actor  For this study, we planned that our knowledge acquisition technique would be a set of questions which will be able to elicit the organisational actor concepts from the expert. Once the expert had answered the questions, we could use the answers to develop an organisational actor diagram of the expert‘s work. We had two options for developing the questions; we could train the expert to understand the organisational actor concepts or we could develop specific questions that used colloquial language to elicit the organisational actor concepts. We decided not to train the expert, since the 122  training could have biased how he described his work. Instead we developed a question that used everyday language to elicit information for each step of the organisational actor method. To ensure the questions elicited the right concepts, we asked someone familiar with the organisational actor concepts which concept was related to each question. Table 26 shows these interview questions, examples of answers to each question, the method steps the interview questions are attached to, and the concepts that are supposed to be elicited by the questions. Table 30: Questions to Elicit Organisational Actor Concepts Method Step  Interview Question  Example Answers  Organisational Actor Concepts Elicited  Identify the actors' goals and determine those that are appropriate for the model based on the stakeholder(s).  What are the My job is to make sure that responsibilities of your the customer has an job in the process? enjoyable dinner.  Goal  Based on the goals of the actor, determine the intentions of the actor that are part of the domain.  What do you want to do to ensure that your responsibilities are taken care of?  I make sure that the customers get their food on time.  Intention  Determine the circumstances under which the intentions will be enacted.  How do you decide what you want to do?  I get the customers' food when it is ready.  Reasoning  Identify beliefs from What knowledge circumstances and determine and/or assumptions do reasoning rules for intentions. you use in your work?  I assume that the food is ready within 15 minutes.  Beliefs  Determine how beliefs change, and Identify perceptions/input or beliefs that may be needed to achieve this and model only "complex" learning.  I check to make sure that the Learning and cook is working on time. If Perception/Input the cook is having a slow day then I change my assumption.  Do your assumptions change as you work? Are these changes important when doing the things you want to do that you talked about before? Is there anything you need to monitor, or are given, to perform your tasks? Is there anything that will change your assumptions about your work?  Determine the tasks (actions) What tasks do you need I need to get food from the needed to carry out intentions. to perform to fulfill kitchen to the customer. I your job obligations? take the customers' orders. Determine the output of the actions.  What sort of things do you change/use when you perform a task?  Action  The location of food. I use a Output notepad to take down orders.  123  Table 30: Questions to Elicit Organisational Actor Concepts Method Step  Interview Question  Determine the capabilities and Is there anything that needed to perform the task you would need to have (action). before you could perform one of these tasks? If you wanted to perform a task would you still need to gain access to something before you could do it?  Example Answers  I need a pen to write down the order. I need to be able to carry the food to the customer. Sometimes it is too much food so I use a tray.  Organisational Actor Concepts Elicited Capabilities  3.4.2.2 Empirical Procedure When performing the study, we asked the expert the interview questions listed in Table 29. The questions were asked over three one-hour sessions. There were no follow-up questions during these sessions, and the interviewee was not interrupted when he went off topic. We also had one session to finalize the model where, using the integrity checks to identify gaps in the diagram, we asked the interviewee to provide specific information about his work. We split the focus of the Study‘s analysis into two parts; we analysed the technique itself and the result of the technique. By investigating the use of the technique, we could determine whether the organisational actor method efficiently gathered domain information from the expert. By investigating the results of our knowledge acquisition technique, we could validate the organisational actor method's ability to effectively gather domain information from an expert. We tested the technique itself by identifying the organisational actor concepts elicited by specific questions in the interview. We kept track of when a specific Concept was elicited and which question in the interview elicited it. If the interview questions did not elicit the correct organisational actor concepts or if the questions elicited too many other organisational actor concepts then the Method could be considered inefficient. We tested the result by using the expert and the expert's supervisor to judge the accuracy and organisation of the final model. We asked them whether the model reflected the knowledge of the expert and whether there was anything that was useful about the presentation of the organisational actor concepts. If they found that the representation of the knowledge was faulty or that it missed important parts of the domain then the organisational actor method would be considered ineffective. 124  3.4.3 Results In the analysis of the knowledge acquisition process, we found that the interview questions did not always elicit the "correct" organisational actor concepts. The analysis is presented in Table 30 which shows a percentage of the organisational actor concepts elicited from a particular question. For instance, when trying to elicit intentions we discovered five beliefs, which made up 50% of the total beliefs discovered in the interviews. Table 31: Breakdown of Organisational Actor Concepts Elicited by Interview Questions Number of Organisational Actor Concepts Elicited Knowledge Acquisition Question  Goal  Beliefs Intentio Reasoning Learning Action Capa- Perception Output ns bilities /Input  Goal Question  1 1 (10%) (33%)  Intention Question  1 5 (50%) 7 2 (50%) (33%) (100%)  Reasoning Question Action Question Output Question  1 (10%)  1 (25%)  1 (50%)  3 (50%) 3 (43%)  1 (25%)  1 (50%)  2 (28%)  1 (33%)  1 (100%)  Capabilities Question  3 (50%)  Learning perception/ input Question Belief Question Total  2 (28%)  3 (30%) 3 10 100% (100%  7 4 (100%) (100%)  2 (100%) 0  6 7 (100%) (100%)  1 (100%)  *Percentages in table refers to the percentage of an organisational actor concept that was elicited in the study  Table 31 shows that questions meant to elicit a specific organisational actor concept led to several other concepts being elicited. The most informative question in the technique was the intention question which elicited four different organisational actor concepts: goal, intention, belief, and reasoning. This is consistent with the dynamic metamodel discussed in Chapter 2, since intentions are connected to reasoning rules and to the goal and belief concepts through the reasoning rules. Another question, which is meant to deal with reasoning not only covers this 125  concept, but also learning, perceptions/input and capabilities. Although reasoning does not directly link to the other concepts it is interesting that the interviewee involved concepts which represent thought and interaction when being prompted to elicit reasoning which represents thoughtful action. This means the interviewee knew that the question was prompting a connection between what he thought and his actions. So, in this study we found that the process itself was not as structured as we had hypothesized. The interviewee did not simply state a type of organisational actor concept but provided a story, much like how Alexander and Maiden (2004) stated that people usually provide descriptions of their work. We also analysed which instances of the organisational actor concepts were elicited by their specific interview question. We did this to determine which organisational actor concepts were easy to elicit, and to identify which concept could be best elicited using only its specific interview question. In Table 31 we show the number of times an organisational actor concept was elicited by its specific question and by the other interview questions. For instance, the interview question for the goal concept elicited one goal, and the other interview questions elicited two goals. Table 32: Identification of Organisational Actor Concept by Question Organisational Actor Concept  Concept Question  Goal  1 (33%)  Intention  7 (100%)  Reasoning  1 (25%)  Other Concept Question 2 (66%) 3 (75%)  Action Output  1 (100%)  Capabilities  3 (50%)  3 (50%)  Perception  2 (29%)  5 (71%)  Belief  3 (30%)  7 (70%)  Learning  2 (100%)  *Percentages in table refers to the percentage of an organisational actor concept that was elicited in the study  Table 32 shows that the intention and output question elicited all of the necessary intentions and outputs from the expert but the learning and action concepts were not identified by their specific interview questions. In fact, the action concept was not elicited at all. We also validated the results of the method by presenting the organisational actor diagram to the disaster management professional and his supervisor. The disaster management professional 126  was able to understand the representation of his knowledge and even used it to inform us of where we misinterpreted some of his answers. Interestingly, when we asked the disaster management professional what knowledge and assumptions he used to perform his job he stated many of his assumptions as questions that are answered in a different way depending on the context. For instance, he mentioned that he would ask himself how to proceed in a disaster planning meeting by answering the question "What is the best way to politically handle this?‖ The model can be found in Figure 22.  Figure 22: Initial Organisational Actor Diagram of Disaster Management Professional  127  During this session we also used some of the integrity checks developed in Chapter 2 to identify problems with the diagram. With the help of the expert we modified the diagram such that it did not violate the integrity checks. For instance, we were able to identify actions that the interviewee performed that he failed to mention initially, and identify that a previously stated intention on his part was not related to his official duties. The finalized diagram can be found in Figure 23.  128  Figure 23: Finalised Organisational Actor Diagram of Disaster Management Professional  The expert's supervisor told us that the diagram was a very accurate representation of how the disaster management professional would describe his job. The supervisor also stated that the capabilities section of the diagram was useful, since he could use it to evaluate a new job hire when the disaster management professional decided to retire.  129  3.4.4 Threats to Validity There are some threats to the construct validity and external validity of the study. Construct validity is violated because the method was not directly tested in the study. The results show that many of the questions elicited concepts that were different from those originally intended. However, it is difficult to determine whether the questions were incorrect or whether the method is not efficient for gathering concepts from the interviewee. External validity is violated because the case study involved one interviewee. The interviewee is not a typical person in an organisation since he is in a top position with many years of experience. It is possible that someone in a position with more defined tasks or less decisionmaking duties would find the diagram less useful. Also it is difficult to generalise the experience with one person to entire population. There may be idiosyncratic characteristics of the interviewee that made gathering information from him difficult or easy. There were few issues with reliability in the study since the researcher only asked the questions in Table 30 when initially gathering information from the interviewee, and did not interrupt or ask probing questions to the interviewee. Another researcher should be able to replicate the procedures of the study. However, if the researcher wants to replicate the proofreading session between the modeler and interviewee then there may be some issues with reliability, since there were no precise procedures for working with the interviewee. Also, there may be some issue with the interpretation of the information given by the interviewee. If this study is to be replicated it may need a second modeler to represent the domain. Internal validity is not an issue since no causal factors were discussed in this study. The purpose of the study was to determine how the presence and use of a technique guided by the organisational actor method affected the modeling process, and was not to test specific hypotheses. Even with these limitations, we can say that when we used the organisational actor method to create a representation of an individual's work, that the diagram acted as a useful communication tool between the modeler, the expert and his supervisor. This shows that the organisational actor method has potential use for creating effective representations of experts' knowledge. Unfortunately, the questions developed by using the organisational actor method did not efficiently gather information from the expert. The questions did not always elicit the appropriate concepts and the expert would move away from the topic, so we propose that the interviewer will have to use the questions to keep the interviewee on track. Even though each question did not elicit the appropriate concepts, the set of questions did structure the interview process and 130  could provide guidance for the interviewer to focus the interview on specific concepts.  3.5 Conclusion In this Chapter we conducted four studies to test the usability and usefulness of the organisational actor concepts and organisational actor method. As mentioned in Table 14, we conducted the four studies to determine the usability and usefulness of the organisational actor concepts and organisational actor method. From the results of the four studies we conclude that these artifacts can be, and will be, used by practitioners to represent the domain. In Study 1 we found that the organisational actor concepts are familiar to non-technical individuals because when these subjects were asked to describe a situation using their own words, they directly or indirectly used all of the organisational actor concepts. So if people are in some way familiar with the organisational actor concepts then it will be easier for them to use the actual organisational actor concepts and they will be likely to use the organisational actor concepts to represent a domain. In Study 2 we found that domain experts judged organisational actor diagram to be a better representation of a domain than the i* diagram of the same domain. The reasons they gave for choosing the diagram were that it is easier to focus on the actor in the organisational actor diagram and that they could use the diagram to trace the actor's behaviour. So if domain experts judge that the organisational actor diagram better represents the domain than another agentbased modeling framework then the organisational actor concepts used in the diagram should be useful to practitioners. In Study 3, we found that novice and expert system analysts need a method to more efficiently and / or effectively represent a domain using the organisational actor concepts. More specifically, we found that simply exposing the method to novice analysts brought some improvement to their modeling process but did not help them to develop better representations. But using the method helped the expert system analysts to efficiently model the domain and was even more instrumental in helping them to represent the domain. So if a method is needed by novices and experts to better model the domain then it is likely that the organisational actor method will be used by practitioners. In Study 4, we found that the organisational actor method developed in Chapter 2 can gather information from a domain expert about his work and create a representation that communicates this understanding to others. From the study we found that questions guided by the Method can 131  be used to elicit most of the organisational actor concepts but the questions did not always elicit the appropriate Concept. The diagram created from the results of the interview was able to relay our understanding of the domain to the expert, who changed a few details of the initial diagram, and by the expert's supervisor who could use the data to better understand the expert's job. So if the organisational actor method can be used to collect information from an expert, and form that information into a representation that captures and communicates an experts understanding of a domain then the organisational actor method is useful to practitioners. There are also some limitations to the studies. In Study 1, one reason why perception/input and beliefs may not have been mentioned by the subjects is that these concepts deal mostly with the simulator. Nonaka and Takeuchi (1995) state that is difficult to elicit the internal behaviour of actors from users, so it is consistent that organisational actor concepts which represent the internal behaviour of actors are not salient to non-technical individuals. The action and reasoning concepts are salient because they are related the effector, which the actor uses to produce external behaviour. Another difference between the most and least salient concepts is that actions and reasoning are processes and perception/input and beliefs are states. So individuals are focused more on the processes of the effector than the states of the simulator. Another limitation of the study was the scenario provided to each subject. Even though it did include brief descriptions of the internal behaviour of some actors, the overall focus of the scenario was on the interaction between actors. This focus may have biased the subjects towards describing the external behaviour of the concepts. However it is important to point out that the internal processes of the actor were still mentioned by many subjects, just not as many as the external processes. A limitation of Study 2 is that we did not actually test whether model readers, without knowledge of the domain, could understand the model. We simply asked experts to judge whether novices would be able to understand the models of the domain. It is possible that the organisational actor diagrams represent sufficient information for a domain expert to understand the domain but it might be difficult for a novice to actually read the diagram to understand the domain. For future study we must determine whether the model can communicate the domain to someone with no knowledge of the area. A limitation of Study 3 is that we did not test the actual organisational actor method but a shortened version of it. We chose to focus on only a few concepts so as not to give our subjects cognitive overload but because of this the study does not tell us whether modelers representing internal view concepts like beliefs, learning and goals would benefit from using a method to 132  model the domain. There are also several limitations to Study 4. First, we only represented one employee in the study. It would be interesting to see if the organisational actor method can help the modeler to make sense of several interviews of interacting actors. Another limitation is that the expert interviewed in the study worked in a management position and was very autonomous; therefore, understanding exactly what he did in the job was harder than someone with a more well-defined position and the insights gathered from interview. Lastly, we did not guide or interrupt the interviewee when he went off topic. A gentle reminder of the question might have yielded more efficient results. Based on the results of this Chapter, we also know how we could have improved the studies. We could have improved Study 1 by developing several scenarios which emphasised a particular set of the organisational actor concepts. This could help us determine whether the type of salient concepts in the case would affect how non-technical individuals described the domain. For instance we could determine the influence of the depiction of internal concepts on non-technical individuals‘ descriptions. It may be that focusing on decision-making in the case could make reasoning more salient for readers but we do not know if it would be as salient as actions were for those who read a description which focused on actions. We could have improved Study 2 by investigating how novices read the model. It would be interesting to see which diagram could best inform novices about the domain. As exploratory studies, we propose that we could do little to improve Studies 3 and 4. It would have been better to include more concepts in Study 3 but, as stated before, we did not want to create a large cognitive load. Also as stated previously, we could have improved Study 4 by representing one more employee who did not share the same characteristics as the disaster management expert. In this way we could make some inferences of how useful the method is in representing a certain type of employee. However we did show that it was useful for representing one type of employee. Despite these limitations, from these results of the studies we can say that the organisational actor method is useful to practitioners because, in most cases, it can help them to efficiently create a representation of actors in the domain that communicates the actor's behaviour to its readers.  133  Chapter 4: Conclusion In this work we developed a conceptual modeling method that could be used to represent the users' descriptions of their domain. In this final chapter we provide a brief summary of the work, highlight some contributions of the research and limitations of the overall work. Finally, we conclude this Chapter by discussing future research in this domain.  4.1 Summary of Research The main source of understanding a domain in system analysis is the user. The user provides a narrative of how he or she works in the environment and the system analyst must represent the important elements of this narrative in a structured fashion. However, traditional conceptual modeling does not capture the context of the user's narrative. In this work, we proposed that to better represent business domains in system analysis, a conceptual modeling language is needed to capture the context of the user's narrative in a structured way. Agent-based conceptual modeling has been proposed for representing actors in business domains. Agent based conceptual modeling is based on the intelligent agent, which is a piece of software that is meant to mimic a human being, and is different from traditional conceptual modeling, since it represents the actor's behaviour in the environment. We surveyed the current agent-based modeling frameworks and found that no modeling framework could represent all the traits of the user needed to describe its behaviour, and therefore could not represent the context of the user's narrative, so we proposed that a new agent-based conceptual modeling method needed to be developed. In this work we called this new method the organisational actor method. We developed the organisational actor method by using the design science approach. In the design science approach, the researcher develops IT artifacts that are tools and/or methods for helping IT practitioners perform their jobs. A design scientist must draw from the theoretical foundations of the IS discipline and other research areas to design the artifacts and must also show that practitioners will be able to use the artifact and find it useful. In our work we conducted six design activities. In the first design activity we used the theory of affordances to determine the characteristics of our definition of an actor. The product of the activity was a formal definition of the organisational actor that stated an actor performs four activities to proactively interact with its environment; an actor is able to: affect its environment, decide when to effect its environment, perceive environmental features and, perceive its possible 134  actions by forming relationships between its abilities and the environment. In the second design activity, we used our definition of an actor and the systems approach to determine the components of the organisational actor. The product of the activity was a specification of the organisational actor modeling construct, which consists of three components that interact with each other: the receptor, simulator, and effector. The receptor is used by the organisational actor to sense the environment and relays these messages to the Actor's simulator. The simulator contains a model of the environment that the organisational actor uses to make decisions, and once it makes a decision it sends commands to the effector. The effector is the mechanism by which the organisational actor interacts with the environment. In the third design activity, we used the specification of the organisational actor modeling construct and the systems approach, ontology, and software agent literature to determine a description of the organisational actor's behaviour. The product of this activity was a set of concepts that can be used in conceptual modeling to directly represent all needed traits of actors in the domain. These concepts are called: input, belief, intention, output, perceiving, learning, reasoning, action, perception, goal, and capability. In the fourth design activity, we used the organisational actor concepts and the systems approach, ontology, and software agent literature to determine the relationships between the organisational actor concepts. The product of this activity was the organisational actor metamodels, which showed how the concepts can represent the structural, dynamic, and interactive aspects of the actor. In the fifth design activity, we used the organisational actor metamodels as inputs to determine the features of a valid organisational actor model. The product of this activity was the set of integrity checks, which act as a validation tool for organisational actor models that can be used without knowledge of model's domain. Table 11 shows the integrity checks developed in this activity. In the sixth design activity we also used the organisational actor metamodels, but in this activity the metamodels were used to determine the correct steps for building an organisational actor model. The product of this activity is a step-by-step method for creating an organisational actor model, which can guide analysts to easily translate a user's description of their work into the organisational actor concepts. In our validation we conducted four studies; two for the organisational actor concepts and two for the organisational actor method. In Study 1 and 2 we validated the organisational actor concepts, with Study 1 testing whether the organisational actor concepts were intuitive to non135  technical individuals ,and Study 2 testing whether domain experts found the organisational actor concepts and organisational actor metamodel useful for representing a domain. In Study 3 and 4 we tested the validity of the organisational actor method, with Study 3 testing whether modelers needed a method at all when using some of the organisational actor concepts and Study 4 testing whether the organisational actor method could guide the interview process when gathering information from an employee about his work. In Study 1 we found that the subjects explicitly and / or implicitly used every organisational actor concept. Specifically, we found that the action and reasoning concepts were the most likely to be mentioned by the subjects and the perception/input and belief concepts were the least likely to be mentioned. In Study 2 we found that the experts judged organisational actor diagrams to be useful because they presented an actor view of the domain. Also, the concepts provided a way to trace the behaviour of the actor. Specifically, we found that the learning and reasoning concepts are important for completing the picture of the agent's behaviour. The results from this study show that each concept is needed to create a useful representation of the actor's behaviour. In Study 3 we concluded that simply exposing novices to the use of a method is not enough for them to efficiently represent the domain and that even system analysis experts may find a method useful for using the organisational actors. In Study 4 we discovered that it was difficult to elicit all of the concepts from the employee, but the diagram was very useful since it helped to communicate with the employee about his job and was useful for identifying where we misidentified his knowledge. The diagram was also useful to the employee's supervisor for understanding the employee's job.  4.2 Contributions to Research and Practice In this section, we highlight practical, methodological and theoretical contributions of the development of the organisational actor method. The practical contribution of our work is a conceptual modeling method that is developed to increase non-technical user involvement in the system analysis process. Our conceptual modeling method focuses on the people in business. Since the organisational actor method was built to represent the users in an organisation, it provides a novel perspective on system analysis that is not shared by other conceptual modeling methodologies. The organisational actor method's representation of the thoughts and decision-making processes of the users means that the mental state of the user is represented by the system analyst, so the analyst not only looks at how the user acts in the domain but must also incorporate the internal thinking of a user. This 136  makes the analysis process very personal and idiosyncratic; a different person doing the same job may think differently about the position. As we saw in Study 4 with the development of the disaster management professional's job profile, this idiosyncratic modeling makes it possible to determine whether the work is appropriate for the person doing the task and whether the work has to be redefined to fit the beliefs and style of the employee. This idiosyncratic view also ensures that the model shows how people in the actual process perform their work, instead of how idealised workers perform their tasks. Since, the organisational actor method can be used to represent users, we also tested whether non-technical employees could use the organisational actor method to represent their own work. This is why usability was a criterion of evaluation in Chapter 3 and a group of novice modelers was one of the populations used in the studies. The results of the studies show that non-technical employees should be able to use the organisational actor method, with little or no supervision. We believe this is a significant contribution to practice, since user involvement in the system development process increases user satisfaction with the finished system. We propose that the organisational actor method can help to identify the requirements of an information system by representing the internal and external view of the actor provided by the user. For instance, if the modeler is interested in knowing what data an information system needs to support a business activity then the modeler could identify the perception/inputs that are used in the learning of the actors in that business process. As stated by Glinz 2007, there are several types of requirements of information systems. Functional requirements are related to the functionalities of the information system that are related to how it will operate. Performance requirements are related to how well the information system performs its functions. Specific quality requirements refer to other attributes of the information that are not related to performance or functionality. And lastly, constraints refer to characteristics outside of the information system that affect how the system must operate. In Table 33 shows how the organisational actor method can be used to determine requirements for information systems. In the table we will also use the example of a waiter notification system in a restaurant that will provide information to waiters about what orders have been completed by the kitchen.  137  Table 33: Identifying Requirements Using the Organisational Actor Method Information system requirement Functional Requirement  Definition  Using the organisational actor method  Example  Relates to the expected behaviour of the system  Performance requirement  Relates to timing, speed and throughput  Identify how the information system supports actors; gathering, using or communicating information and choosing the appropriate concepts for the function. If gathering then perception/input, if using then beliefs, learning, and reasoning, if creating then output and actions. Look at the goals and intentions of the actors using the system to identify the objectives of the actor and whether they are related to performance.  Specific quality requirement  Relates to specific attributes of the system beyond its function  Look at the goals and intentions of the actors using the system to identify the objectives of the actor and if they are related to attributes of the system not related to performance and functionality.  Constraint  Relates to things outside the system that affect the system  Look at perceptions/input and capabilities of the users who use the information system.  If a waiter wants to get information about when the food is ready in the kitchen then a requirement for the waiter notification system is the perception/input of the state of the order in the kitchen. If the intention of the waiter is to bring food out to all of its customers in a timely manner then a requirement for the notification system would be that it should multiple orders that are ready. If the goal of the waiter is to provide good tasting food to the customer then a requirement for the notification system would be that it notifies the waiter quickly enough that the food still tastes good. If the waiter needs the capability of moving around while performing other actions then this constrains how the notification system can be accessed.  There is a limitation to this aspect of our work. The notation developed for the organisational actor diagrams is in a textual style since we thought it would be best for focusing the readers‘ attention to the actors and explaining the actor's behaviour. However, this notation led to problems with showing interaction between well specified agents. According to the results from Study 2 in Chapter 3 this led to well represented actors, but confusion in the mind of the model reader as to the nature of the interaction between the agents. The methodological contribution of our work is our specific operationalisation of the design science approach for developing a conceptual modeling method. When developing the organisational actor method we created the organisational actor concepts by: 1) identifying the characteristics of its main conceptual modeling construct, 2) developing the conceptual modeling construct, 3) identifying the concepts that describe the construct and 4) identifying how the 138  concepts interact to represent the domain. A graphical representation of this operationalisation can be found in Figure 3 in Section 1.3.2. The model illustrates the different steps in the design process, the theoretical foundations used in each process, and the justifications for using the theories and conducting the activities in the design process. From the results of our work, we believe that the process illustrated in Figure 3 might be useful for developing other conceptual modeling methodologies. As long as the conceptual modeling construct that the method is built on has theoretical foundations, it will be possible to use the design science approach to develop the conceptual modeling method. In our work, we used theories from psychology, systems theory, philosophy, and software agent literature to develop the method. A benefit of using such a varied set of theories is that we developed a view of the actor that was not only based on the technical academic disciplines such as robotics and artificial intelligence, but also the more ―soft‖ side of academia, such as psychology and philosophy. With this less rigid view of the actor we could develop a set of concepts that would be intuitive to non-technical employees. It was difficult to integrate such varied theoretical foundations together, but we used connections between each of the theories to develop the organisational actor method. For instance, the theory of affordances provided the characteristics of the actor, which we used to determine the type of system in the systems literature that would best represent an actor. The other benefit of using the design science approach to develop a conceptual modeling method is its focus on practicality. Throughout the development of the organisational actor method we ensured that using the organisational actor concepts would not be too complicated or abstract, even if the changes were not theoretically correct. For instance, we chose not to make a distinction between input and perception concepts because we felt that the difference between the two concepts would create needless detail for the modeler. We also made modeling easier by creating rules such as; capabilities should only be modeled if they are not always available to the actor, and only 'complex' learning should be represented in the organisational actor diagrams. Without the design science philosophy of creating a useful tool we may not have focused on these practical instances, and instead presented a method that was just theoretically correct. One limitation of using the design science approach is that we are not sure how many other compromises need to be made to make the Method more practical and where to stop our pragmatic compromises. For example, some beliefs are exactly the same as the perception/input of the actor; if an actor sees a glass holds water then it has a belief that the glass holds water. In this case, can we use the perception/input directly in the actor's reasoning or should we represent 139  a belief that is just the same as a perception/input? Without a guide to determine what we can and cannot compromise, we may create so many changes that the organisational actor method is no longer based on its original theoretical foundations. The theoretical contribution of our work is the definition of the agent provided by the organisational actor concepts; input, belief, intention, output, perceiving, learning, reasoning, action, perception, goal, and capability. As mentioned in Chapter 2, these concepts are not new; however the contribution of this work is that we developed a specific definition for these concepts and showed how they can be used to represent a domain. The concepts provide a useful list for determining whether a modeling language can represent the behaviour of the actor. For instance, AORML does not contain a concept that is analogous to the capability concept. Since it does represent actions, the language assumes that the actor can perform an action when it wants to, so it can not represent the behaviour of an actor that wants to perform an action but is unable. The general definition of the actor also provides a common language for discussing the behaviour of the actor. For instance if we are told that a manager chose to allocate money to the marketing department and we want to learn more about their behaviour then, using the organisational actor concepts and Metamodels, we know to ask about the intention of the manager, the reasons for why the manager had these intentions, and the way that the manager's beliefs about the situation were formed. Without the organisational actor method as a guide, it would be difficult to determine exactly what to ask to better understand the behaviour of the manager. Though this work has stated that the organisational actor method would be useful for information system analysis, we suggest that the definition of an actor‘s behaviour could be used to better understand the domain for organisational or management consulting purposes. It is possible that the organisational actor method, such as business process modeling according to Kettinger, Teng, and Guha (1997), could be used by management consultants to help represent the domain and understand employees‘ behaviour. We did face some challenges with defining these concepts because we had to ensure that the definitions were general enough to cover concepts that already existed in other agent conceptual modeling languages, but the definitions had to be specific enough to explain and represent actor behaviour. For instance, we had to ask whether the dependency concept from the i* framework and the external object from AORML were part of the actor's behaviour. We also had to determine whether there was a concept that represents an actor's behaviour but was not present in 140  any agent conceptual modeling languages. To help us solve these issues we used the theoretical foundations as previously mentioned. Another limitation to our work is that we used cases with a low degree of complexity to illustrate the usefulness of the organisational actor method. We propose that there are two ways a case can be complex; the number of units of analysis, (ie. actors) and the complexity of the processes of the unit of analysis (ie. the internal and external view of the actor). In cases we are interested in, the unit of analysis is the actor and the actor can be complex in two ways; either it has many interactions with the rest of the world (a complex external view) and / or it has complex decision-making processes (a complex internal view). We define a case to be simple when it does not have many actors, the interactions between the actors are limited, and the learning and reasoning of the actors are limited. We used these simple cases to ensure that readers could understand the use of the concepts and that the concepts could at least adequately represent simple cases. A preliminary version of the organisational actor method has been used in a case that involved many interactions between many actors (Monu and Woo 2009). In Monu & Woo 2009 the organisational actor method was able to represent a large number of interactions between ten actors in the domain. But we have not tested it on cases with actors with complex decision-making processes, so we are unsure how well it will represent these cases. Lastly, we did not test the scalability of the method. Scalability refers to the ability of the method to be usable and useful when it is representing an entire organisation as well as it represents a process in the organisation. It is possible that the addition of many actors, and interactions may make the model unwieldy. To deal with this issue we could use computer aided software engineering (CASE) tool to manage the organisational actor diagram. One such CASE tool, MetaEdit+, has tools to help the modeler to create, view and edit a conceptual model of the domain (Kelly, Lyytinen, and Rossi 1996). The tool includes automated integrity checks programmed with the rules of the method, can help the modeler identify which concepts they have missed in a large diagram and diagram analysis tools can be used to provide insight into the domain through the model, information such as which object has the most relationships in the diagram. If model creators and readers use this, or a similar CASE tool, they should have fewer problems dealing with complex organisational actor diagrams.  141  4.3 Conclusion and Future Research The results of this work show that the organisational actor method can be used by novices and experts to effectively represent a domain. The organisational actor method represents the thoughts, interactions, and thoughtful actions of the actor; and the development of the method led to a practical, theoretical, and methodological contribution to research and practice. Even though there are some issues with the efficiency of the organisational actor method, the results have shown that it is useful for representing actors, but there is a limitation to the organisational actor method. In each validation of the organisational actor method we used scenarios which described individuals who made decisions, and were independent in how they made decisions but interdependent with others in the domain. We propose that the organisational actor method would only be useful in these situations. In a more structured environment, the usefulness of the model may not have been as evident. This limitation opens up the possibility for the organisational actor method to be an important conceptual modeling language in areas that traditionally have not used conceptual modeling; cooperative information systems and chaotic organisational processes. Cooperative information systems have been described as distributed information systems which can be used to support the collaborative work of several people. Current work in cooperative information systems assumes that the goal of the system and the system's users are common and that the information system helps people work towards this common goal. According to De Michelis et al. 1999, there are three facets of research in cooperative information systems; the system, organisational, and group collaboration. The system facet deals with the integration of information systems, the organisational facet deals with integrating the organizations' processes and goals, while group collaboration tries to find ways to support individuals working on a particular task or project. The systems facet has garnered a lot of attention from those who develop software agents. Software agents have "negotiating protocols" which are thought to be a good basis for integrating the distributed systems in CIS. For instance, in Bui and Lee (1999) an agent-based framework is used to analyse a cooperative information system used by the United States military. Specifically, a multi-user decision support system was proposed to deal with distributed military crisis management which would provide information to distributed decision-makers during a disaster. However, work in software agents has not penetrated the organisational and group collaboration research areas. Some have mentioned that in order to develop a CIS that is useful 142  to employees we should represent them as agents, to provide a better understanding of collaborative work. It has been suggested that using agent conceptual modeling can integrate the business requirements with the goals of the employees. Therefore, we propose that the organisational actor method should be uniquely qualified for analyzing a business in need of a CIS. The ability to represent not only the interactions between the collaborators, but also their rationale and internal decision-making processes will lead to CIS's that better fit the collaborative work of a group. Also, by representing the goals of the actors we can begin to reconcile the business goals with the employees‘ goals. To begin research in this area we propose analyzing an organisation in emergency management to help develop a multi-user decision support system for disaster planning. The other potential for the organisational actor method is for it to be the conceptual modeling language for complex organisational processes. Some organisations contain processes that are well structured and contain activities which are designed to interact with each other. In system analysis, the challenge in describing these processes is to represent the interaction between the processes' activities in a complete but comprehensible manner. For organisational processes that are not structured, many people in the organisation may not understand why activities in the process are performed and how these activities interact with other activities in the organisation. The challenge for system analysis when representing these chaotic organisational processes is to determine the purpose of the process, the efficiency of the process in relation to its purpose, and the reasons for performing the activities in the process. According to Yu (2001), organisational processes have become more distributed, which increases the chance that interconnected business activities are far removed from each other, but also makes it less likely that these processes can be simplified or eliminated. Therefore, if companies want to ensure that these activities do not interfere with their business, they will need some way to document these activities and handle the uncertainty in the processes. With the results from this research, we propose to study whether the organisational actor method can help businesses document these processes.  143  References 1. Ackoff, R.L. (1971). Towards a System of Systems organisational actor concepts. Management Science, 17(11), 661–671. 2. Ajzen, I., & Fishbein, M. (1973). Attitudinal and normative variables as predictors of specific behavior. Journal of Personality and Social Psychology, 27, pp. 41- 57. 3. Alexander, I.F. & Maiden, N. (Eds.) (2004). Scenarios, Stories, Use Cases: Through the Systems Development Life Cycle. Hoboken, N.J., USA: John Wiley & Sons. 4. Arazy, O., & Woo, C. C. (2002). Analysis and Design of Agent-Oriented Information Systems. The Knowledge Engineering Review, 17(3), 215-260. 5. Bartlett, C.A and Ghoshal, S. (1994). Change the Role of Top Management: Beyond Strategy to Purpose. Harvard Business Review, 72(6), 79 - 89. 6. Beath, C.M. & Orlikowski, W.J. (1994). The Contradictory Strcuture of System Development Methodologies: Deconstructing the IS-User Relationship in Information Engineering. Information Systems Research, 5(4), 350-377. 7. Bertalanffy, L. von (1968). General Systems Theory: Foundations, Development, Applications. New York, NY, USA: George Braziller. 8. Bolland, R.J, jr. (1978). The Process and Product of System Design. Management Science, 24(9), 887-898. 9. Booch, G. (1994). Object-Oriented Analysis and Design (2nd edition). Reading, MA: Addison-Wesley. 10. Bratman, M. E. (1987). Intentions, Plans and Practical Reasoning. Cambridge, MA, USA: Harvard University Press. 11. Bui, T. & Lee, J. (1999). An Agent-Based Framework for Building Decision Support Systems. Decision Support Systems - Special issue on decision support technologies for complex and open organizations, 25(3), 225-237. 12. Bunge, M. (1977). Treatise on Basic Philosophy. Vol 3, Ontology I: The Furniture of the World. Boston, MA, USA: Reidel. 13. Bunge, M. (1979). Treatise on Basic Philosophy. Vol. 4, Ontology II: A World of Systems, Reidel, Boston, Massachusetts, 1979. 14. Castro, J., Kolp M., & Mylopoulos, J. (2002). Towards requirements-driven information systems engineering: the Tropos project. Information Systems, 27(6), pp. 365-389.  144  15. Chen, P. (1976). The Entity-Relationship Model – Towards a Unified View of Data. ACM Transactions on Database Systems, 1(1), 9 – 36. 16. Chen, P. (2006). Suggested Research Directions for a New Frontier - Active Conceptual Modeling. In D.W. Embley, A. Olivé, S. Ram (Eds.): Conceptual Modeling - ER 2006, 25th International Conference on Conceptual Modeling, Tucson, AZ, USA, November 69, 2006, (pp. 1-4). Berlin, Heidelberg, Germany: Springer. 17. Chemero, A. (2003). An Outline of a Theory of Affordances. Ecological Psychology, 15(2), 181-195. 18. Churchman, C.W. (1979). The Systems Approach. New York, NY, USA: Dell Publishing. 19. Cohn, M. (2004). User Stories Applied: For Agile Software Development. Boston, MA, USA: Addison- Wesley Professional. 20. Cyert, R.M. & March, J.G. (1963). The Behavioral View of the Firm. Englewood Cliffs, NJ, USA: Prentice Hall. 21. DeMarco, T. (1979). Structured Analysis and System Specification. Englewood Cliffs, NJ, USA: Prentice-Hall. 22. De Michelis , G., Dubois, E., Jarke , M., Matthes , F., Mylopoulos, J., Papazoglou M., Pohl, K., Schmidt, J., Woo, C. & Yu, E. (1999). Cooperative Information Systems: A Manifesto. 4th International Conference on Cooperative Information Systems, Edinburgh, UK September 2 - 4, 1999. 23. Ericsson, K.A. & Simon, H.A. (2004). Protocol Analysis: Verbal Reports as Data. Cambridge, MA, USA: MIT Press. 24. Gibson, J.J. (1977). The Theory of Affordances. In R. Shaw and J. Bransford (Eds.), Perceiving, Acting, and Knowing. Hillsdale, N.J., USA : Lawrence Erlbaum Associates. 25. Giunchiglia, F., Mylopoulos, J., & Perini, A. (2003). The Tropos Software Development Method: Processes, Models and Diagrams. In Proceedings of the First International Joint Conference on Autonomous Agents and Multiagent Systems: Part 1 Bologna, Italy, July 2002. 26. Glinz, M. (2007). On Non-Functional Requirements. In Requirements Engineering Conference (RE’07), 21 – 26. 27. Green, A. (1998). Verbal Protocol Analysis in Language Testing Research: A Handbook. Cambridge, U.K.: Cambridge University Press. 28. Guizzardi, R.S.S. (2007). Agent-oriented Constructivist Knowledge Management. University of Twente. 145  29. Hevner, A.R., March, S.T., Park, J. & Ram, S. (2004). Design Science in Information Systems Research. MIS Quarterly, 28(1), 75-105. 30. Huhns, M.H. & Stephens, L.M. (1999). Multiagent Systems and Societies of Agent. In G. Weiss. (ed.), Multiagent Systems: A Modern Approach to Distributed Artificial Intelligence (pp. 79- 120). Cambridge, MA, USA: MIT Press. 31. Hunton, J.E. & Beeler, J.D. (1997). Effects of User Participation in Systems Development: A Longitudinal Field Experiment. MIS Quarterly, 21(4), 359-388. 32. Jacobson, I., Christerson, M., Jonsson, P. & Övergaard, G. (1992). Object-Oriented Software Engineering: A Use Case Driven Approach. New York, NY, USA: ACM Press Books. 33. Jacobson, I., Ericsson, M. & Jacobson, A. (1994). The Object Advantage: Business Process Reengineering With Object Technology. New York, NY, USA: ACM Press Books. 34. Jones, K.S. (2003). What is an Affordance? Ecological Psychology, 15(2), 107-114. 35. Juan, T., Pearce, A., & Sterling, L. (2002). ROADMAP: Extending the Gaia Method for Complex Open Systems. In C. Castelfranchi and W. L. Johnson (Eds.), Proceedings of the 1st International Joint Conference on Autonomous Agents and Multiagent Systems, Bologna, Italy, July 15-19, 2002 (pp. 3-10). 36. Kelly, S., Lyytinen, K. and Rossi, M. MetaEdit+ A fully configurable multi-user and multi-tool CASE and CAME Environment. In P. Constantopoulos, J..Mylopoulos, Y. Vassiliou. Advanced Information Systems Engineering. Lecture Notes in Computer Science, 1080, 1-21). 37. Kettinger, W.J., Teng, J.T.C. and Guha, S. (1997). Business Process Change: A Study of Methodologies, Techniques, and Tools. MIS Quarterly, 21(1), 55-80. 38. Krutchen, P., Woo, C.C., Monu, K., & Sootedeh, M. (2008). A Conceptual Model of Disasters Encompassing Multiple Stakeholder Domains. International Journal of Emergency Management. 5, 25-56. 39. Kung, C.H. & Sølvberg, A. (1986). Activity Modeling and Behavior Modeling. In T.W. Olle, H.G. Sol, A.A. Verrijn-Stuart (Eds.), Proceedings of the IFIP WG 8.1 Working Conference on Information Systems Design Methodologies: Improving the Practice (pp. 145-171).  146  40. Lakoff, G. (1987). Cognitive Models and Prototype Theory. In U. Neisser (Ed.), Concepts and Conceptual Development: Ecological and Intellectual Factors in Categorization. Cambridge, MA, USA: Cambridge University Press. 41. Lamsweerde, V.A. (2001). Goal-Oriented Requirements Engineering: A Guided Tour. Proceedings of the 5th IEEE international Symposium on Requirements Engineering, 249-262. 42. Lapouchnian, G. (2010). i*: An Agent and Goal - Oriented Modeling Framework. Retrieved from http://www.cs.toronto.edu/km/istar/. 43. Liddle, S.W. & Embley, D.W (2006). A Common Core for Active Conceptual Modeling for Learning from Surprises. In P.P. Chen & L.Y Wong (Eds.) First International Workshop on Active Conceptual Modeling of learning (ACM-L 2006), Tucson, Arizona, November 8, 2006, Proceedings. Berlin, Heidelberg, Germany: Springer. 44. Liu, L. and Yu, E. (2004). Designing information systems in social context: a goal and scenario modeling approach. Information Systems, 29(2), 187-203. 45. McKeen, J.D, Guimaraes ,T. and Wetherbe, J.C. (1994). The Relationship Between User Participation and User Satisfaction: An Investigation of Four Contingency Factors. MIS Quarterly, 18(4), 427-451 46. Miller, J.G. (1978). Living Systems. New York, NY, USA: McGraw-Hill. 47. Monu, K. & Woo, C.C. (2009). Conceptual Modelling in Disaster Planning using Agent Constructs. In A.H.F Laender, S. Castano, U. Dayal, F. Casati, and J.P. Oliveira. Conceptual Modeling -ER 2009. Lecture Notes in Computer Science, Vol. 5829 (pp. 374386). 48. Mylopoulos, J. (1992). Conceptual Modeling and Telos. In P. Loucopoulos & R. Zicari (Eds), Conceptual Modeling, Databases, and CASE. Hoboken, NJ, USA: Wiley, 49-68. 49. Newell, A. (1982). The Knowledge Level. Artificial Intelligence, 18(2), 87-127. 50. Nonaka, I. & Takeuchi, H. (1995). The Knowledge Creating Company. Harvard Business Review, 69(6), 96-104. 51. Olle, T.W., Hagelstein, J., Macdonald, I.G., Rolland, C., Sol, H.K., Van Assche, F.J.M. and Verrijn-Stuart, A.A (1991). Information Systems Methodologies: A Framework for Understanding. Wokingham, UK: Addison-Wesley. 52. Riedemann, C. & Freitag, R. (2009). Modeling Usage: Techniques and Tools. IEEE Software, 26(2), 20-24.  147  53. Robson, M.B. and Carroll J.M. (2002). Usability Engineering: Scenario-Based Development of Human-Computer Interaction. Burlington, MA, USA: Morgan Kaufmann. 54. Runeson, P., & Höst, M. (2009). Guidelines for conducting and reporting case study research in software engineering. Empirical Software Engineering, 14(2), 131-164. 55. Sahin, E., Cakmak, M., Dogar, M.R., Ugur, E. and Ucolu, G. (2007). To Afford or not to Afford: A New Formalization of Affordances Towards Affordance-based Robot Control. Adaptive Behavior, 447—472. 56. Scott, A.C.; Clayton, J.E. & Gibson, E.L. (1991). A Practical Guide to Knowledge Acquisition. Reading, MA., USA: Addison-Wesley Publishing Company. 57. Takashima, Q. (1986). Characteristics and Technical Challenges of Current Expert Systems. In T. Bernold (ed) Proceedings of the Technology Assessment and Management Conference of the Gottlieb Duttwiler Institute, Rüschlikon, Zürich, Switzerland, April 2526, 1985 (pp. 31-48). 58. Thagard, P. (2008). Cognitive Science. In E. N. Zalta (ed.) The Stanford Encyclopedia of Philosophy (Fall 2008 Edition). Available: http://plato.stanford.edu/archives/fall2008/entries/cognitive-science/ Accessed July 30, 2011. 59. Thesaurus.com in Roget's 21st Century Thesaurus, Third Edition. Source location: Philip Lief Group 2009. Available: http://www.thesaurus.com. Accessed: April 14, 2010. 60. Turvey, M.T. (1992). Affordances and Prospective Control: An Outline of the Ontology. Ecological Psychology, 4(3), 173 – 187. 61. Vessey, I. (1991). Cognitive Fit: A Theory-Based Analysis of the Graphs Versus Tables Literature. Decision Sciences, 22(2), 219–240. 62. Vessey I & Galletta D. (1991). Cognitive Fit: An Empirical Study of Information Acquisition. Information System Research, 2(1), 63–84. 63. Wagner, G. (2003). The Agent-Object-Relationship Metamodel: Towards a Unified View of State and Behavior. Information Systems, 28(5), 475-504. 64. Wand, Y. & Weber, R (1990). An Ontological Model of an Information System. IEEE Transactions on Software Engineering, 16, 1282–1292. 65. Wand, Y. & Weber, R. (1995). On the Deep Structure of Information Systems. Information Systems Journal, 5, 203 – 223.  148  66. Wand, Y. & Weber, R. (2002). Research Commentary: Information Systems and Conceptual Modeling - A Research Agenda. Information Systems Research, 13(4), 363– 376. 67. Wooldridge, M. (1999). Intelligent Agents. In G. Weiss (ed), Multiagent Systems: A Modern Approach to Distributed Artificial Intelligence. Cambridge, MA, USA: MIT Press (pp. 27- 77). 68. Wooldridge, M., Jennings, N.R., & Kinny, D. (2000). The Gaia Method for AgentOriented Analysis and Design. Autonomous Agents and Multi-Agent Systems, 3(3), 285 – 312. 69. Xu, X. (2006). To Support Emergency Management by Using Active Modeling: A Case of Hurricane Katrina. In P.P. Chen & L.Y. Wong (Eds.) First International Workshop on Active Conceptual Modeling of Learning (ACM-L 2006), Tucson, Arizona, November 8, 2006, Proceedings. Lecture Notes in Computer Science #4512, Springer. 70. Yin, R. K. (2003). Case study research, design and methods. Newbury Park, CA, USA: Sage Publications. 71. Yu, E. (1993). Modelling Organizations for Information Systems Requirements Engineering. In the Proceeding of the First IEEE Symposium on Requirements Engineering, San Diego, CA., USA, January, 1993 (pp. 34 – 41). 72. Yu, E. (1997). Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering. In the Proceedings of the Third IEEE International Symposium on Requirements Engineering, Annapolis, MD., USA, January 6–10, 1997 (pp. 226 – 235). 73. Yu, E. (2001). Agent-orientation as a Modeling Paradigm. Wirtschaftsinformatik., 43(2), pp. 123–132. 74. Zhang, H., Kishore, R. & Ramesh, R. (2007). Semantics of the MibML Conceptual Modeling Grammar: An Ontological Analysis Using the Bunge-Wand-Weber Framework. Journal of Database Management, 18(1), 1–19.  149  

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.24.1-0072052/manifest

Comment

Related Items