Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

A role clarity framework for gathering business activities Taghavi, Atefeh 2015

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

Item Metadata

Download

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

Full Text

A ROLE CLARITY FRAMEWORK FOR GATHERING BUSINESS ACTIVITIES   by    ATEFEH TAGHAVI  B.Sc., The University of Tehran, 2009 M.Sc., K.N. Toosi University of Technology, 2011    A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF  MASTER OF SCIENCE   in   THE FACULTY OF GRADUATE AND POSTDOCTORAL STUDIES  (Business Administration)     THE UNIVERSITY OF BRITISH COLUMBIA  (Vancouver)    July 2015    Atefeh Taghavi, 2015      ii  Abstract To date, requirement engineering (RE) studies have proposed several methods for efficiently gathering correct and complete requirements for developing information systems. As one of the most widely-used RE approaches, goal-oriented requirement engineering (GORE) determines requirements based on an organization's goals for its information system. GORE methods vary, but most do not clarify how they obtain the primary goals. To address this uncertainty, a few studies have introduced some guidelines. This researcher believes however that further investigation is required to improve organizational analysis, and thereby attain more accurate definition of goals for the information system. The first step in organizational analysis should be defining business activities of users. To achieve such understanding, this thesis develops a role clarity framework, that operationalizes the concept of role ambiguity drawn from two organizational theories: role dynamics (Kahn, Wolfe, Quinn, Snoek, & Rosenthal, 1964) and goal setting and task performance (Locke & Latham, 1990). According to the proposed framework, a role’s expectations, activities, and consequences are essential for describing a role’s business activities. Findings reveal that a role’s activities express the core of a role’s business activities. In addition, a role’s expectations and consequences contain contextual information supporting analysts in collecting and evaluating a role’s business activities. More specifically, expectations clarify the origin of business activities, and consequences enable analysts to verify current business activities and anticipate potential ones.    iii  Preface This study has been conducted by the author, A. Taghavi, in consultation with members of the supervisory committee. I am fully responsible for concept formation, as well as manuscript composition.  A summarized version of all chapters has been published in “A. Taghavi and C. Woo. A Role Clarity Framework for Gathering Business Activities. In Symposium on Research in Systems Analysis and Design (SIGSAND15), Richmond, Virginia, May 2015.” I wrote the manuscript and revised it based on the comments given by my supervisor and co-author, Prof. Carson Woo.                    iv  Table of Contents  Abstract ........................................................................................................................................ ii Preface ........................................................................................................................................ iii Table of Contents ..................................................................................................................... iv List of Tables ............................................................................................................................. vi List of Figures .......................................................................................................................... vii Acknowledgements .............................................................................................................. viii Dedication ................................................................................................................................... x Chapter 1: Introduction .......................................................................................................... 1 Chapter 2: Literature Review on Information Systems Requirements ................. 5 2.1 Overview ......................................................................................................................................... 5 2.2 Requirement Engineering (RE) .............................................................................................. 5 2.3 Understanding the Organization before the System Requirements ......................... 8 2.3.1 Shifts in the Requirements: From Yesterday to Today........................................................ 9 2.3.1.1 Information Requirements ..................................................................................................................... 10 2.3.1.2 Individuals’ Communications ................................................................................................................ 10 2.3.1.3 Type I and Type II Information Work Activities ........................................................................... 11 2.4 Some Popular Methods in Requirement Engineering ................................................. 12 2.4.1 Requirements Approaches: the Early Days ........................................................................... 12 2.4.2 The Emergent of Objects and Agents in Requirement Engineering ............................ 13 2.4.3 Goal-Oriented Requirement Engineering (GORE) .............................................................. 14 2.4.3.1 Position of Goals in Requirement Engineering .............................................................................. 15 2.4.3.2 Why is the Goal-Oriented Requirement Engineering Useful? ................................................. 15 2.4.3.3 Goals and Agents ......................................................................................................................................... 16 2.4.3.4 Where Do the Goals Come from? ......................................................................................................... 17 2.5 Our Research Motivation: A Deeper Organizational Analysis before Defining Goals of the Information System ................................................................................................ 19 Chapter 3: Two Fundamental Theories for the Proposed Framework .............. 22 3.1 Overview ...................................................................................................................................... 22 3.1.1 Introducing the “Vision Quest Auto Dealership” Case Study ......................................... 23 3.2 Theory of Role Dynamics and Concept of Role Ambiguity......................................... 24 3.2.1 Main Concepts in the Theory of Role Dynamics .................................................................. 24 3.2.2 Role Conflict ....................................................................................................................................... 26 3.2.3 Role Ambiguity .................................................................................................................................. 27 3.2.4 The Application of the Concept of Role Ambiguity to the Proposed Framework . 29 3.3 Theory of Goal Setting and Task Performance .............................................................. 30 3.3.1 Goals as Regulators of Actions .................................................................................................... 30 3.3.2 Feedback .............................................................................................................................................. 30   v 3.3.3 The Application of the Relationships among Goals, Actions, and Feedback to the Proposed Framework ................................................................................................................................ 31 3.4. Discussion .................................................................................................................................. 33 Chapter 4: The Role Clarity Framework ........................................................................ 35 4.1 Overview ...................................................................................................................................... 35 4.2 Main Components of the Role Clarity Framework ....................................................... 35 4.2.1 Expectations ....................................................................................................................................... 35 4.2.1.1 Rights, Responsibilities, and Duties .................................................................................................... 36 4.2.2 Activities .............................................................................................................................................. 38 4.2.3 Consequences .................................................................................................................................... 39 4.2.3.1 Three Types of a Role’s Consequences .............................................................................................. 39 4.3 How Does the Role Clarity Framework Work? .............................................................. 42 4.3.1 The Role Clarity Process ............................................................................................................... 45 4.4 Conclusion ................................................................................................................................... 48 Chapter 5:  Application of the Role Clarity Framework to a Case Study ............ 50 5.1 Overview ...................................................................................................................................... 50 5.2 The Role Clarity Process for the Sales Associate Role ................................................. 50 5.3 Discussion ................................................................................................................................... 63 5.3.1 Lessons Learned from the Case Study ..................................................................................... 63 5.3.2 Limitations of the Case Study ...................................................................................................... 69 Chapter 6: Conclusion .......................................................................................................... 70 6.1 Summary of the Thesis ........................................................................................................... 70 6.2 Contributions of the Thesis ................................................................................................... 71 6.3 Limitations of the Thesis and Directions for Future Research ................................ 72 Bibliography ............................................................................................................................ 75 Appendices ............................................................................................................................... 80 Appendix A: The Vision Quest Auto Dealership Case Study for Chapters 3-5 ............ 80 Appendix B: Rizzo et al. (1970) Questionnaire to Measure Role Ambiguity and Conflict for Chapter 3 ..................................................................................................................... 84           vi  List of Tables Table 1- Basics Definitions in the Theory of Role Dynamics (Kahn et al., 1964) ............................ 26              vii  List of Figures Figure 1- Relationships among the Business Activities, Information System Goals, and Information System Requirements ....................................................................................................... 20 Table 1- Basics Definitions in the Theory of Role Dynamics (Kahn et al., 1964) ............................ 26 Figure 2- A Meta-Model Describing the Fundamental Concepts in the Role Clarity Framework............................................................................................................................................................................. 36 Figure 3- A Meta-Model Describing How Expectations Develop Activities ....................................... 38 Figure 4- A Meta-Model Describing Three Types of Consequences ..................................................... 42 Figure 5- The Role Clarity Framework ........................................................................................................... 44 Figure 6- The Instance Diagram to Demonstrate the Role Clarity Process regarding the Sales Associate ......................................................................................................................................................... 52      viii  Acknowledgements I take this opportunity to express my enduring gratitude to my wonderful supervisor, Dr. Carson Woo, who has kindly trained me and immensely helped me to become an independent researcher. Without your supervision and constant support this thesis would not have been possible.  I wish to sincerely acknowledge Dr. Ning Nang, the other member of my supervisory committee, for providing me with all of her invaluable advice and constructive feedback. I am also extremely grateful to Dr. Yair Wand, my external examiner, for his brilliant comments and suggestions. I am indebted to him for our long discussions that truly helped me to enhance my accuracy in expressing arguments.  In addition, I would like to show my appreciation to Natural Sciences and Engineering Research Council (NSERC) of Canada for valuable funding to support my research. Besides, a warm thank you to Dr. Sandra Robinson and Kira Schabram, who kindly introduced the concept of “role ambiguity” to me. I place on record, my special acknowledgement to all of the MIS Department faculty members, Sauder School of Business MSc and PhD students, and dear Elaine Cho for their continuous encouragement during this study.  Moreover, my heartfelt thanks to Marjan, my most beloved sister, for her unceasing help and attention through this journey. I will never forget your kindness.    ix At the end, I wish to express my deepest appreciation to my parents. Words cannot describe my gratitude to my wonderful mother and father after what they have done for me. Thank you so much for your great patience and unwavering love.                                            x  Dedication   To my parents        1  Chapter 1: Introduction   In the past 40 years, many studies of information systems have paid particular attention to information system requirements (Mylopoulos, Chung, & Yu, 1999; Van Lamsweerde, 2000). Some studies show that to implement a successful information system, analysts must determine the complete and correct user requirements of a proposed system (Appan & Browne, 2012; Davis, 1982; Wetherbe, 1991). To facilitate accuracy of requirements, several approaches to requirement engineering (RE) have been introduced. Goal-oriented requirement engineering (GORE) is one of the most popular RE methods for ensuring that the goals of the information system will accurately reflect the requirements of users in the organization. The more well-known GORE models are GBRAM (Anton, 1996), KAOS (Dardenne, Van Lamsweerde, & Fickas, 1993), scenarios (Rolland, Souveyet, & Achour, 1998), and i* (Yu, 1997a, 2009, 2011).  The concept of “goal” in RE connects underlying organizational factors, such as intentions and motivations beyond the information system, to the expected features of the system (Yu, 1993). Current GORE methods propose a variety of techniques to process goals and develop system requirements; the scenario method uses refinement and AND/OR relationships, while the i* method uses means-ends links. However, most of these methods do not clearly explain how they obtain the primary goals of the information system. To address this concern, a few system requirements studies (Anton, 1996; Regev & Wegmann, 2005; Van Lamsweerde, 2001) have proposed some   2 guidelines. For example, they suggest that GORE focus on understanding a stakeholder’s problems and negating them and extract intentional keywords from a stakeholder’s interviews and organizational documents and statements. We believe however that further studies are needed to improve the ways in which organizational factors are used to define the goals of the information system. Information systems are embedded in organizations to help organizational members to perform their business tasks. In order to understand the goals for an information system, analysts need to ask, first, what business activities are performed by the users of the information system and second, why users require the information system to complete those business activities and finally, how the information system supports users in fulfilling their activities. Answering the second question produces the system’s goals, and answering the third produces the system’s requirements. The first step for analysts should therefore be describing with optimum accuracy the business activities performed by organizational users.  This study responds to the first question, on “business activities”. We define this concept as the organizational tasks required by each user, independent of any information technology solution, to support the organization in accomplishing its objective. It is expected that, after discovering an accurate list of business activities for each user, analysts will realize appropriate goals for the information system. Consequently, they will be able to investigate the requirements for the system with greater precision. In our study, we attempt to address the following research question: What descriptions by organizational users help system analysts to better understand overall   3 business activities? To answer this question, we propose using a “role clarity framework” derived from two organizational theories; role dynamics (Kahn et al., 1964) and goal setting and task performance (Locke & Latham, 1990).  According to the concept of role ambiguity from the theory of role dynamics, organizational members need to obtain clear information about the expectations, activities, and consequences of their work, to properly perform their roles in the organization. We suggest that these three constructs are very useful guides for gathering information needed to describe the business activities.  To operationalize a role’s expectations, activities, and consequences, and define a set of possible relationships among them, our role clarity framework applies two principles from the theory of goal setting and task performance. Our framework therefore helps analysts collect expectations, activities, and consequences of the roles of any organizational member, and this enables more accurate determination of all members’ business activities.  While a role’s activities express the core of business activities for each organizational user, a role’s expectations and consequences contain contextual information that allows analysts to gather and evaluate business activities with greater accuracy. Role expectations in the role clarity framework are similar to the concept of individual goals in some GORE methods, such as i* (Yu, 1997a, 2009, 2011), but current GORE models do not clarify the origin of individual goals. To show this origin explicitly, our framework applies the concept of role set.  Moreover, data on a role’s consequences help system analysts to evaluate and modify the expectations and activities. Consequences not only specify a role’s current business activities; they also enable   4 system analysts to detect future business activities for each user. In other words, knowledge of a role’s consequences supports prediction of possible changes in requirements at the early phase of system analysis. Considering future changes and alternative business activities before developing a system will, we hope, help to protect the information system project from later expensive adjustments.  Structure of the Thesis  In the next chapter, we will review the literature on requirement engineering methods, and show the gap between GORE and organizational contexts. In chapter 3, two organizational theories will be explained; role dynamics (Kahn et al.1964) and goal setting and task performance (Locke and Latham 1990). Then we will show how we derive a role clarity framework from them. Chapter 4 will describe the main concepts and procedures of the role clarity framework that are used to describe users’ business activities. In chapter 5, we will apply the role clarity framework to the “Vision Quest Auto Dealership” case study to demonstrate the strengths and practicality of our framework. The last chapter summarizes our findings and suggests a few directions for future research.     5  Chapter 2: Literature Review on Information Systems Requirements  2.1 Overview   To explain the position of the role clarity framework with respect to the relevant studies, first we will review the requirements literature, specially the goal-oriented models, and second, we will show the existing gap in the surveys.  This chapter is structured as follows. The next section presents a summary of the objectives and importance of RE in information systems literature. Section 2.3 explains the impact of the organizational contexts on the system requirements. Section 2.4 narrates a history of RE methods and describes the idea of GORE, as a popular approach considering the organizational intentions before defining the requirements. Finally, section 2.5 shows the existing gap between GORE methods and organizational analysis and describes our proposed solution to decrease this gap.  2.2 Requirement Engineering (RE) To develop the information systems, RE is an early-phase process, in which the main goals of system, stakeholders, and their needs are clarified and documented (Nuseibeh & Easterbrook, 2000). Stakeholders’ needs shape the system requirements, and the information system is expected to fulfill the requirements. Regarding the term stakeholders, information system requirements surveys have proposed different definitions. For example, Nuseibeh and Easterbrook (2000) define stakehoders as all the   6 paying customers, system developers, and users. Another study excludes the developers from the stakeholders (Yu, Giorgini, Maiden, & Mylopoulos, 2011), and Singh and Woo (2009) assume only potential users of the system as stakeholders. For the purpose of this study, we focus on the users as the main stakeholders, for whom the system requirements should be collected.   Requirements clarify the functions of an information system and the quality of them; these requirements respectively are called functional and non-functional requirements (Yu et al., 2011).  Obtaining proper requirements is known as the most critical and challenging procedure in developing the information systems (Davis, 1982; Van Lamsweerde, 2000; Zmud, Anthony, & Stair Jr, 1993). Success of the information systems development is dependent on the correctness and completeness of the collected requirements (Appan & Browne, 2012; Davis, 1982). In other words, by gathering as much complete and correct requirements as possible, the proposed information system will be closer to the expectations of stakeholders.  Besides, gathering inadequate requirements generates serious problems in information system projects (Alter, 2013), and is known as one of the main sources of system failures. More specifically, according to the Standish Group CHAOS report, published in 1995, a considerable number of American companies (n=350) reported lack of user participation, incomplete requirements, changing requirements, unrealistic expectations, and vague objectives as major reasons for system failures (Van Lamsweerde, 2000).    7 In addition, lack of enough attention to system requirements generates huge costs for organizations. If the developed information system does not meet the main purposes of its development, it should be revised. Building an information system is an expensive process by itself, and the further revisions require additional and even higher costs (Wetherbe, 1991).   RE encompasses several tasks. Nuseibeh & Easterbrook (2000) indicate the following activities as the essential tasks in RE. Most of these activities are in common with suggested steps by some other studies (Sutcliffe, 2002; Van Lamsweerde, 2000).  1) Requirement elicitation 2) Requirement modeling and analysis 3) Requirement communication 4) Requirement negotiation and agreement 5) Requirement evolvement Understanding the environment in which the information system is considered is very important, and is addressed as domain analysis (Van Lamsweerde, 2000) or scoping (Sutcliffe, 2002) phase in the existing surveys. For the purpose of organizational information systems, we should analyze the organization, as the main environment in which the information system is applied, before eliciting the information system requirements. Concentrating on organizational context and business issues will support the analysts in collecting better requirements for users (Alter, 2013).     8 2.3 Understanding the Organization before the System Requirements  Broadly speaking, there is an increasing interdependency between information systems and organizations (Pries-Heje & Baskerville, 2008). From one side, organizations require information systems to improve their efficiency and performance. Information systems are not thought to be useful if they do not improve the organizational processes (Panko, 2012). Information systems are embedded in the organizations to fulfill the needs (Davis, 1982), provide opportunistic changes (Orlikowski, 1996), control activities (Tillquist, King, & Woo, 2002), support decision making (Keen & Morton, 1978), and facilitate communications between individuals (Panko, 2012) in the organizations.  On the other side, to successfully develop an information system, it is essential to understand and analyze the organizational context and business issues. Existing requirements studies propose to explore the organizational factors prior to eliciting the system requirements (Alter, 2013; Yu, 1993). As mentioned earlier, before collecting the requirements, analysts should deeply investigate the organization in which the information system is embedded. For example, analysts need to consider the organizational goals (Singh & Woo, 2009; Watson & Frolick, 1993) and structure (Nuseibeh & Easterbrook, 2000), potential users, and business process. Analysts also need to understand how organizational members communicate and work with each other, and which business rules (Nuseibeh & Easterbrook, 2000) constraint their behavior.  Analyzing the organization is independent of any information technology solution. However, by acquiring much precise knowledge about the organizational   9 context, analysts are able to better understand the intended information system and accordingly define more accurate requirements.  Davidson’s socio-cognitive process model (2002) clearly demonstrates the impact of organizational settings on user requirements. According to this model, users infer their system requirements based on a knowledge structure that describes the information system in their organization. The knowledge structure is attributed to information about the organization, business activities, environment, and information technology capabilities. Changes in the organization update a user’s knowledge and assumptions. This, in turn, adjusts the system requirements of the user (Davidson, 2002).  Considering the organizational settings in RE has become more popular since 1990s. For example, some of the RE methods, such as goal-oriented approaches, have attempted to reduce the gap between understanding the organziation and eliciting the system requirements. These methods pay attention to important organziational factors, like objectives and policies, in their analysis; however, we think further elaborations still are required in the literature. We will discuss about the current gap in requirements surveys and propose our solution in section 2.5. In the remainder of this section, we briefly review some of the imporant changes in organizational needs that have affected the system requirements.  2.3.1 Shifts in the Requirements: From Yesterday to Today  From the birth of requirements literature, organizational needs for information systems have been changed, leading to several shifts in the type of system requirements. We review some of those shifts here.    10 2.3.1.1 Information Requirements Around the mid-1970s, as early years of studying the requirements in information systems literature, information systems were used in the organizations mostly to generate reports and support decision-making processes for the management levels. Therefore, the requirements surveys at that time emerged to target those specific information systems. For instance, a study by Munro and Davis (1977), as a primary research in the literature, limits the system requirements to the required information for managers in order to support their decision-making processes.  Subsequently, many other studies contributed to similar approaches (Montazemi & Conrath, 1986; Munro & Wheeler, 1980; Nutt, 1986; Orman, 1987; Watson & Frolick, 1993; Wetherbe, 1991). These studies concentrated on the concept of information requirements to address the information needed by managers to facilitate the decision-making in the organization. In like manner, some other surveys, considered the concept of database requirements (De & Sen, 1984; Mantha, 1987) to express the data processed and stored in the organization as the fundamental requirements of the users.  The boundaries of information system requirements have extended over the time. The current requirements, not only describe the information required by different organizational roles, but they also demonstrate different features of a system to control the business processes and facilitate communications in the organization. 2.3.1.2 Individuals’ Communications  As discussed earlier, many of the earlier requirements studies thought of the data and reports as the main parts of the management requirements; however, a recent study (Panko, 2012) demonstrates that managers spend most of their time (around 85%) to   11 communicate rather than to read reports. This evidence is a reminder for us to pay special attention to individuals’ communication patterns prior to eliciting the system requirements.  Information system surveys reveal that some organizational tasks are completed across different functions (Wetherbe, 1991). These tasks are not limited to one specific role, instead, to accomplish them, various roles should collaborate with each other (Strong & Volkoff, 2010). To accurately analyze the organizational contexts, it is important to know what users have to do in the organization 1) individually, such as reading reports, and 2) in communication with others, such as cooperating to complete a business process.  2.3.1.3 Type I and Type II Information Work Activities Another change in the application of the information systems is the shift in the essence of the knowledge work in organizations. There are a variety of information activities in the organizations; some of them are more crucial and strategic. Therefore, RE is expected to consider the degree of importance and priority of knowledge activities in the domain analysis. As Panko (2012) states, there are two different types of information activities in the organizations: Type I and Type II. Type I or clerical activities are the routine and structured tasks, including the activities in the inventory, billing, and accounting departments.  On the other hand, type II activities are less structured and non-routine, and they are considered as strategic and critical activities in the organizations. For example, engineering, marketing, and management process are type II activities.   12 Todays, organizational information systems are shifted from structured and regular toward strategic and non-routine information work (Panko, 2012). Understanding type II activities is challenging, and it requires a deep analysis of the organization. It is important to consider the differences between type I and type II knowledge activities before detecting the system requirements.   2.4 Some Popular Methods in Requirement Engineering RE emerged in the mid 1970’s (Mylopoulos et  al., 1999). Since that time, many different approaches have been proposed in the literature. In the earlier RE methods, like SADT, the main focus of RE was to collect the required data and activities for users. However, the later methods introduced new concepts, such as objects, agents and goals, to gather the requirements. In the following section, we briefly review some of the popular RE approaches in the literature.  2.4.1 Requirements Approaches: the Early Days Structured analysis and design technique (SADT), proposed by Ross (1977), was one of the early approaches in requirement analysis. SADT mainly focused on expressing the data and activities. This method not only was used in RE, but it also was a framework to enable understanding the problems in other fields, including social sciences, politics, and arts (Ross, 1977).  In addition, entity-relationship diagrams (Chen, 1976) and state transition diagrams (Wasserman & Stinson, 1979) were two of other RE methods introduced in the late 1970s. These methods were simple and popular but limited in the structure and expressiveness (Van Lamsweerde, 2000).    13 Requirement modeling language (RML), introduced by Greenspan, Mylopoulos, and Borgida (1982), was another early approach in RE. This method formalized SADT (Mylopoulos et al., 1999), and it was considered as a predecessor for incoming object-oriented requirement techniques (Van Lamsweerde, 2000). RML, as an object-oriented knowledge representation framework, applied some principles, such as classification and generalization, to model the real world (Greenspan, Mylopoulos, & Borgida, 1994)  2.4.2 The Emergent of Objects and Agents in Requirement Engineering Object-oriented requirement analysis was a popular approach in the late 1980s. Shlaer and Mellor (1988) and Coad and Yourdon (1990) proposed two of the leading models in the object-oriented analysis (Mylopoulos et al., 1999).  The main reason for success of object-oriented requirement analysis comes from the extreme range of object-oriented supporting techniques— from requirement analysis to system design and subsequently system implementation. While using the same constructs, such as the same classes and methods, simplifies applying the object-oriented requirement analysis in different phases of the system development (Mylopoulos et al., 1999), it increases the risk of confusion for analysts (Van Lamsweerde, 2000).  In a similar way, agent-based modeling was introduced in RE to model the active components of the environment and information system, their responsibilities, and the existing constraints among them (Van Lamsweerde, 2000). Agents are used to show the “who” in performing the processes and activities (Yu, 1997b). An agent is a specific type of object that processes actions, while it has the choice on its behavior (Dardenne et al., 1993).    14 In most of the agent-based models, agents possess some goals; however their degree of power to choose and modify the goals is different (Yu, 1997b). For example, in some of the goal-oriented agent-based models, such as Composite System Design (CSD) (Feather, 1987), the general organizational goals are decomposed and assigned to agents. In these models, agents do not have enough power to modify their goals, but they should perform their activities to fulfill the assigned goals (Yu, 1997b).  Agents in Knowledge Acquisition in Automated Specification (KAOS) technique (Dardenne et al., 1993) are similar to agents in CSD but allowed to negotiate on their goals (Yu, 1997b). Moreover, in the i* framework (Yu, 1997a, 2009, 2011), there is no general goals decomposition, and agents have the freedom to choose their own goals (Yu, 1997b).    2.4.3 Goal-Oriented Requirement Engineering (GORE) GORE emerged in RE, simultaneously with the separation of RE from computer science and system engineering disciplines (Regev & Wegmann, 2005). As mentioned earlier, in order to precisely elicit the system requirements, the analysts should accurately study the organization, in which the information system is embedded. GORE was introduced in RE to connect the organizational contexts to the information system requirements (Yu, 1993).  In GORE, analysts need to answer the following question: “Why is the information system required in the organization?” Understanding the whys and intentional factors underling the information system (Yu, 1993) form the foundations of GORE. In general, goals refer to the expected objectives of the information system (Liu   15 & Yu, 2004; Nuseibeh & Easterbrook, 2000), and they provide the rational to identify system requirements (Van Lamsweerde, 2001).  Some of the GORE models, such as GBRAM (Anton, 1996) and i* (Yu, 1997a, 2009, 2011), consider both of the business and information system goals in their analysis. As Anton (1996) defines, “Goals are the high level objectives of the business, organization or system. They capture the reasons why a system is needed and guide decisions at various levels within the enterprise.” (Anton, 1996, p.137) 2.4.3.1 Position of Goals in Requirement Engineering Studying the organizational contexts and identifying the goals are completed in the early-phase RE (Yu, 1997a). Early-phase requirements do not specify what the system does, instead they elaborate why the system is needed in the organization (Yu, 1997a). The early-phase RE is followed by the late-phase RE, in which all of the functional and non-functional requirements are collected (Castro et al., 2002).  Gathering goals before activities and data is very useful. Goals explain why activities and data should be gathered and evaluate whether the detected activities and data are sufficient to fulfill the goals (Liu & Yu, 2004).  2.4.3.2 Why is the Goal-Oriented Requirement Engineering Useful? Goals have been introduced in RE for several reasons. Based on two popular GORE surveys (Van Lamsweerde, 2001; Yu & Mylopoulos, 1998), we list some important reasons to consider the goals in RE.  First, goals are used to elaborate the requirements. Goals are the links between the organization and information system, and they provide the rational to identify the information system requirements of users. In addition, goals are proposed in different   16 abstract levels; the high levels goals are decomposed and refined into more detailed goals. This supports specifying the complex requirements. Second, goals are applied to verify the requirements. Goals are considered as criteria to collect and evaluate the system requirements. By using the goals, analysts attempt to detect complete and relevant lists of requirements.  Third, goals aid in managing the conflicts. If there is any conflict among the requirements, goals help the analysts to discover the conflicts at source. If analysts identify and resolve the conflicts in goals, they reduce the incompatibilities and potential problems in system requirements.  2.4.3.3 Goals and Agents Some GORE models focus on the general system goals, independently of the agents who are responsible to accomplish the goals. In these models, the global goals of the information system are revealed and decomposed into more detailed goals.  Goal modeling using scenarios (Rolland et al., 1998) is an example of the GORE methods not considering the concept of agents in their analysis. This method introduces the concept of beneficiary as “a person in favor of whom the goal is to be achieved”; however, a beneficiary is not considered as a responsible agent to accomplish the goal.  On the other hand, some other GORE methods, such as CSD, KAOS, and i*, consider the concept of agents to represent the goals. We briefly mentioned these methods in 2.3.2. Using different agents, the goal-oriented agent-based methods express the goals from the perspective of multiple users (Yu et al., 2011).  For example, in the i* framework (Yu, 1997a, 2009, 2011), which stands for distributed intentionality that underlies the framework (Yu, 1997a), there is no general   17 system goal (Yu, 1997b); however, the agents possess their own intentions, interests, and goals. The i* framework shows that how an agent is dependent on another agent to fulfill its goals. This relationship is called goal dependency between two agents.  2.4.3.4 Where Do the Goals Come from? Current GORE methods propose a variety of techniques to process given system goals, define more detailed system goals, and develop system requirements. For example, goal modeling using scenarios defines three relationships to operate on goals— AND, OR, and REFINEMENT (Rolland et al., 1998). The i* framework applies the means-ends links to decompose a goal into a few tasks, expressing the hows to accomplish the goal (Yu, 2011). In addition, some other requirements surveys (Regev & Wegmann, 2005; Singh & Woo, 2009) suggest that analysts ask why, how, and how else questions to elaborate more abstract or detailed goals from primary goals.  Despite all of the discussed techniques to deal with the primary or given goals, the question here is: where do the primary goals come from? In the remainder of this section, we briefly summarize the available suggestions to detect the original goals, and then, in the last section, we show the existing gap in the literature.  KAOS states that the information systems goals are given by the clients (Dardenne et al., 1993), and the i* framework does not clarify the origin of the primary goals. However we know that the system goals are not specified easily (Rolland et al., 1998; Van Lamsweerde, 2001), and the analysts need some strategies to identify and develop the goals (Anton, 1996). In the paper “where do goals come from? The underlying principles of goal-oriented requirement engineering”, Regev and Wegmann (2005) collected existing   18 suggestions to identify goals. According to their results, analysts need to understand a stakeholder’s problems and negate them and to extract intentional keywords (Anton, 1996;Van Lamsweerde, 2001) from organizational goals and policies statements, interview transcripts, a stakeholder’s scenarios, and workflow diagrams in order to elicit information systems goals.  Among the existing GORE methods, GBRAM (Anton, 1996) explicitly addresses the primary goals identification. GBRAM introduces two groups of goals: achievement and maintenance. This method suggests that analysts identify these two types of goals by looking for related intentional keywords in various sources, such as entity-relationship diagrams, flowcharts, and scenarios. Achieve, make, improve, satisfy, and complete are some of the intentional terms to show the achievement goals, while some other keywords, such as maintain, ensure, avoid, monitor, know, and supply express the maintenance goals. The complete lists of achievement and maintenance goals are available in Anton’s PhD dissertation (Anton, 1997).  GBRAM proposes an interesting idea to find the organizational or system goals from the documents. Some of these goals describe the enterprise objectives or policies (Anton, 1996). However, GBRAM does not explain how the analysts ensure that they collect most of the important business goals. To determine accurate primary system goals, the analysts should gather as much correct and complete business goals as possible from the users.     19 2.5 Our Research Motivation: A Deeper Organizational Analysis before Defining Goals of the Information System As Davidson (2002) indicates, both of the organizational and technological information is essential to form the requirements. Introducing the concept of goal in the information systems requirements literature was indeed a successful movement toward considering the organizational factors in RE. However, we think there is still a gap between the current GORE methods and organizational contexts.  As discussed in section 2.4.3.4, most of the existing GORE methods do not clearly explain the origin of the system goals, instead, they mainly concentrate on processing a set of primary goals to develop the further detailed goals and elicit the system requirements. In order to accurately obtain the primary goals of the information system, the analysts should clearly understand the organizational needs. Therefore, we believe a deeper organizational analysis is required by the RE literature to help the GORE methods in determining the system goals.  Based on the discussion in section 2.3, we infer that the analysts need to know what individuals do in the organization, prior to defining the information system goals. More specifically, the analysts should ask, what business tasks are performed by users in the organization. Defined in the introduction (on page 2), business activities express what users are responsible to do in the organization to support the organization and its members in fulfilling their business objectives.  By collecting business activities, the analysts have proper domain knowledge to answer why users need the information system to accomplish their job, and how the information system is helpful in completing the tasks. Correctly answering these two   20 questions helps analysts to gather the system goals and requirements. Figure 1 demonstrates a summary of the discussed relationships among the business activities, information system goals, and information system requirements.             It should be noted that to support modeling the goals, some RE surveys (Singh & Woo, 2009; Singh & Woo, 2008; Wang, 2004) studied the relationship between organization goals and information system goals and determined the current business needs. However, our study not only provides the analysts with current business activities, but it also enables them to detect future business activities for the users. This will be elaborated in chapters 4 and 5. To answer our research question (mentioned on page 4), this study applies the concept of role clarity from the organizational behavior literature and develops a role Figure 1- Relationships among the Business Activities, Information System Goals, and Information System Requirements Business Activities Information System Goals Information System Requirements Legend Represents the dependency of understanding the lower box to recognizing the upper box, i.e. to understand the “Information System Goals”, the system analysts have to recognize the “Business Activities” first.   21 clarity framework. In the next chapter we explain the organizational theories underlying the role clarity framework—role dynamics (Kahn et al., 1964) and goal setting and task performance (Locke & Latham, 1990).      22  Chapter 3: Two Fundamental Theories for the Proposed Framework  3.1 Overview Before presenting the role clarity framework, we should describe the two underlying theories of how the framework is derived. The purpose of the this chapter is to introduce these fundamental theories: role dynamics (Kahn et al., 1964) and goal setting and task performance (Locke & Latham, 1990). How did we find these two theories? As a multidisciplinary field, RE should consider social sciences to understand how individuals perceive and understand their environment (Nuseibeh & Easterbrook, 2000). Therefore, to determine a process for gathering the business activities, we attempted to realize how employees perceive their tasks and responsibilities in the organization. This drew our attention to the concept of organizational role from the organizational behavior literature— employees should understand their organizational roles, in order to determine what they have to do in the organization. Surprisingly, we found that lots of employees experience a lack of knowledge about their role. In the organization studies, this issue is called the role ambiguity (we will define the role ambiguity in section 3.2).  The theory of role dynamics (Kahn et al., 1964) describes a set of specific information, such as a role’s expectations, activities, and consequences, to help the employees in understanding their organizational roles and avoiding role ambiguity. This specific information shaped the basis of the role clarity framework; however, we needed additional guidelines to accurately collect and evaluate the expectations, activities, and   23 consequences. Therefore, we applied two principles from the theory of goal setting and task performance (Locke & Latham, 1990), and operationalized those three concepts in our proposed framework. This chapter is structured as follows. Section 3.2 presents the concept of role ambiguity from the theory of role dynamics. To suggest a set of relationships among the main components of the role ambiguity, section 3.3 explains a few guidelines from the theory of goal setting and task performance. Finally, section 3.4 describes the advantages of using the discussed ideas in RE. 3.1.1 Introducing the “Vision Quest Auto Dealership” Case Study   It should be noted that, from chapter 3 to the end of this thesis, we will use a case study to better elaborate the theoretical concepts. We chose the “Vision Quest Auto Dealership” case study, because it describes a small size organization with a number of organizational roles: namely, sales associate, sales manager, business manager, parts manager, service manager, service technician, and vice president. The Vision Quest Auto Dealership case study can be found in Appendix A at the end of this dissertation. This case study was originally presented in “Casebook for Davis’s Business Systems Analysis and Design” (Davis & Coleman, 1994) and revised later by Sase Singh. Singh shortened the case study by removing information on system design since it is not needed for studies focusing on just systems analysis. Also, the revised edition of Vision Quest Auto Dealership case study was previously used in a system analysis dissertation (Sun, 2009).    24 3.2 Theory of Role Dynamics and Concept of Role Ambiguity Broadly speaking, theory of role dynamics (Kahn et al., 1964) seeks to explain the effects of the role ambiguity and role conflict on the physical and mental health of the individuals in an organization. For the purpose of this dissertation, we apply only the concept of role ambiguity and leave the concept of role conflict as our future work.  In this section, first we briefly present some of the essential definitions in the theory of role dynamics and then elaborate meaning of the role ambiguity. All of the following definitions are collected from the second chapter of “Organizational Stress: Studies in Role Conflict and Ambiguity” (Kahn et al., 1964). 3.2.1 Main Concepts in the Theory of Role Dynamics Office: Office defines one unique position in the organization, in terms of its relationships to other positions and to the organization as a whole. For example, in the Vision Quest Auto Dealership case study, the sales manager, as an office, shows a unique position in the auto dealership, because there is a set of defined relationships between the sales manager and other positions, including the sales associate and vice president. Role: Regarding each office there is a set of activities, which should be performed by any organizational member who occupies that office; those activities form a role. In the Vision Quest Auto Dealership case study, the sales manager office is associated with a set of activities. For example, any person who occupies this office should manage the sales team and attempt to obtain profitable sales results. These activities form the sales manager role.  As Pareek (2002, p.477) says “Role and office (or position) are separate concepts, though two sides of the same coin.” Creating one position in the organization   25 does not lead to defining the related role. Instead, a role is defined when the role senders set the expectations and activities of the office (Pareek, 2002) (The role senders and expectations are defined below). In conclusion, an office describes the relationships between an organizational position and others, while a role illustrates the expectations and activities within that position to support the relationships.  Focal role: This term is used to address any role under consideration. For instance, if we address the sales manager in the auto dealership, then the sales manager is the focal role in our analysis.  Role set: The focal role is directly related to a set of other roles in the organization, including its supervisor, subordinate, and co-worker. The mentioned roles are dependent on the focal role to accomplish their activities, and they form the role set of the focal role. For example, in the Vision Quest Auto Dealership case study, the sales manager is directly related to the sales associate and vice president in the auto dealership; the sales manager is responsible to supervise the sales associate and comply with plans of the vice president. Therefore, the sales associate and vice president constitute the sales manager’s role set. Role Expectation: Members of the role set are dependent on the focal role, and they ask the focal role to accomplish what they want. Therefore, they specify some expectations and send those expectations to the focal role. More often, the focal role’s subordinates expect the focal role to supervise and help them, or its supervisor expects it to conform to the assigned responsibilities. Role Sender: A role sender is any member of the role set, who determines some expectations and sends them to the focal role. For instance, the sales associate and vice   26 president, as the role senders, hold some expectations for the sales manager. The sales associate expects the sales manager to control its activities and help it if needed. Also, the vice president expects the sales manager to follow the organizational objectives, increase the annual sales, and so forth. Table 1 summarizes the discussed basic definitions in the theory of role dynamics.   Concept Definition Office Office defines one unique position in the organization, in terms of its relationships to other positions and to the organization as a whole. Role Regarding each office there is a set of activities, which should be performed by any organizational member occupying that office. Those activities form a role. Focal role This term is used to address any role under consideration. Role set The focal role is directly related to a set of other roles in the organization, including its supervisor, subordinate, and co-worker, who need the focal role to accomplish their activities. The mentioned roles form the role set of the focal role. Role Expectation Dependent on the focal role, members of the role set specify some expectations and send them to the focal role. More often, the focal role’s subordinates expect the focal role to supervise and help them, or its supervisor expects it to conform to the assigned responsibilities. Role Sender A role sender is any member of the role set, who determines some expectations and sends them to the focal role.   3.2.2 Role Conflict Generally, when organizational members perceive pressures toward incompatible activities, they experience a psychological conflict; theory of role dynamics defines it as the role conflict (Kahn et al., 1964).  Table 1- Basics Definitions in the Theory of Role Dynamics (Kahn et al., 1964)   27 Role conflict has several types. One type is called intra-sender conflict. If the vice president asks the sales manager to perform several incompatible tasks, a person playing the role of sales manager, will find psychological conflict to comply with all the assigned tasks. Another type of role conflict is inter-sender conflict. If the sales associate expects the sales manager to do some tasks that oppose the expectations held by the vice president, the sales manager, again, find psychological conflict to comply with all the expectations.  Because the details of the role conflict is outside of the scope of this study, we leave it to the reader to find the complete list of role conflict types available on page 19 of  “Organizational Stress: Studies in Role Conflict and Ambiguity” (Kahn et al., 1964). 3.2.3 Role Ambiguity Any organizational member needs certain types of information to perform his or her role well. Lack of availability of that information generates role ambiguity for the member. Similar to the role conflict, the role ambiguity leads to the mental health issues for individuals (Kahn et al., 1964), such as tension, job dissatisfaction (Bedeian & Armenakis, 1981), job search behavior, and turnover (Sawyer, 1992). As proposed by Kahn et al. (1964), first, the individuals need to know what expectations are held by the members of their role set. A role’s expectations include a role’s rights, duties, and responsibilities. These concepts will be defined in section 4.2.1.1. Second, the individuals should know what activities they have to perform to accomplish the responsibilities. They, also, require to know how to best perform those activities (means-ends knowledge).   28 Third, the individuals need to know the potential consequences of their behaviors. A role’s consequence is defined in terms of the outcome of a role’s performance or non-performance for itself, its role sender, and the organization in general.  If the organizational members do not have clear information about their roles’ expectations, activities, and consequences, they experience role ambiguity in the organization. Information about the expectations, activities, and consequences should be available in the role set and communicated successfully to the corresponding organizational members (Kahn et al., 1964). Theory of role dynamics has been considered as a fundamental survey defining the role ambiguity; however a few years later, some other organizational behavior scholars proposed other definitions for the role ambiguity. For example, Rizzo, House, and Lirtzman (1970) define the role ambiguity in terms of “the predictability of outcome or responses to one’s behavior” and “the existence or clarity of behavioral requirements, often in terms of inputs from the environment, which would serve to guide behavior and provide knowledge that the behavior is appropriate” for any member in the organization. We think this definition, for the purpose of our research, is similar to the one proposed by Kahn et al. (1964). More specifically, the first part of the definition shows the availability of information about a role’s consequences, and the second part includes a role’s expectations and activities.  In addition, Sawyer (1992) presents two constructs of the role ambiguity: goal and process clarity. In his study, the goal clarity items (e.g. the duties and responsibilities, results of the work, and positive evaluations) are very similar to the descriptions of a role’s expectations and consequences. Also, compatible with the definition of a role’s   29 activities (Kahn et al., 1964), process clarity construct shows the degree to which individuals know how to perform their job in the organization.  In this thesis, we use the role ambiguity definition proposed by the theory of role dynamics, because it has been used as a core definition in some of the role studies, including the study by Sawyer (1992). Also, theory of role dynamics explicitly addresses a set of specific information, which should be collected for each organizational role, and in our study, we look to obtain useful information to describe the business activities. The next section explains how we think of that set of information as a relevant idea to our research. 3.2.4 The Application of the Concept of Role Ambiguity to the Proposed Framework The concept of role ambiguity emphasizes that some specific information is essential for organizational members to understand the role performance adequately. Why do we find this idea very interesting? In section 2.5, we mentioned that the main objective of this study is to provide the analysts with accurate business activities of users, before specifying the goals of the information system. In this study we seek to find a way to describe what users should do in the organization, and the concept of role ambiguity simply gives us the solution. Based on the definition of the role ambiguity (Kahn et al., 1964), we conclude that the analysts should gather a user’s expectations, activities, and consequences to realize what the user needs to do in the organization.  The concept of role ambiguity forms the basis of the business activities; however, we still need additional guidelines to process and evaluate a role’s expectations, activities, and consequences. Therefore, we searched for some instructions to   30 operationalize those three concepts and finally found the theory of goal setting and task performance (Locke & Latham, 1990). This theory provides us with a set of guidelines to precisely gather and evaluate a user’s expectations, activities, and consequences.   3.3 Theory of Goal Setting and Task Performance  As a well-known organizational behavior theory, goal setting and task performance (Locke & Latham, 1990) demonstrates a variety of valuable theoretical and empirical results about the power of goals. However, in this section, we limit our explanation to the core ideas and findings that are more relevant to the purpose of operationalizing a role’s expectations, activities, and consequences. Broadly, the theory of goal setting and task performance is based on two principal concepts— goals and actions— and the relationships between them.  3.3.1 Goals as Regulators of Actions Individuals regulate their actions and behaviors based on their goals. In other words, goals are the main causes of actions. This shows the fundamental relationship between the goals and actions in the theory of goal setting and task performance.  Goals can be set by the individuals, assigned by other people, or defined in collaborations. Moreover, goals should be defined clearly and specifically to support individuals in controlling their actions. The finding shows that setting the specific and difficult goals leads to a better task performance of individuals (Locke & Latham, 1990).  3.3.2 Feedback After completing an action, people receive feedback from the environment. In other words, they obtain the knowledge of the results of their behavior. Feedback plays a   31 significant role in the relationship between goals and actions. From one side, the feedback is a moderator in the causal relationship between goals and actions; goals regulate the actions more reliably when feedback of the actions is available than when it is unavailable (Locke & Latham, 1990).  From the other side, goals are a mediator between feedback and actions. Feedback motivates people to change their actions through modifying their goals. However, sometimes people keep their goals and only change their actions based on perceived feedback (Locke & Latham, 1990).  3.3.3 The Application of the Relationships among Goals, Actions, and Feedback to the Proposed Framework As discussed in section 3.2.4, we need to determine a procedure to operationalize a role’s expectations, activities, and consequences. The mentioned ideas from the theory of goal setting and task performance show us the solution.  We found similarities between the expectations and goals, between the activities and actions, and between the consequences and feedback. More specifically, both expectations and goals determine the motivations underlying a task performance. Both activities and actions refer to the tasks, which are performed by individuals; moreover, both consequences and feedback show the outputs of performing or non-performing those tasks. On page 94 of “Organizational Stress: Studies in Role Conflict and Ambiguity”, the authors use the terms goals and permissible means for implementing them to refer to a role’s expectations and activities (Kahn et al., 1964). This evidence strengthens the similarities between the expectations and goals and between the activities and actions in these two theories.   32 The theory of role dynamics states that a role’s activities are required to fulfill (on page 22) and meet (on page 84) the expectations. This is aligned with the causal relationship between goals and actions in the theory of goal setting. However, the causal description in the theory of goal setting and task performance more expressively explains the relationship between goals and actions and between expectations and activities.  In addition, the theory of role dynamics describes a role’s consequence as the potential outcomes of the role performance or non-performance (on page 22). This theory also mentions that an organizational member should know what behaviors are rewarded or punished (on page 23). Again, these statements are aligned with the relationship between actions and feedback in the theory of goal setting and task performance. However, once more, the theory of goal setting and task performance is more expressive in defining this relationship.  Theory of goal setting and task performance not only clearly conveys the discussed relationships, but it also gives us an idea for evaluating a role’s expectations and activities. Because a role’s expectations and activities constitute two of the fundamental components of a user’s business activities, it seems reasonable to propose a method to evaluate and modify expectations and activities. This helps the analysts to gather more accurate business activities. Based on the powerful role of feedback in evaluating the goals and actions, we apply a role’s consequences to evaluate and adjust the role’s expectations and activities.1  All of the discussed relationships will be elaborated more in the chapters 4 and 5.                                                  1 As mentioned in 3.2.3, Sawyer (1992) considers both the expectations and consequences as a role’s goals. However, in our study, we distinguish between the expectations and consequences. By considering only the expectations as the role’s goals, we are able to apply the concept of feedback to evaluate the expectations and activities.   33 3.4. Discussion In this chapter, specifically in sections 3.2.4 and 3.3.3, we discussed the theoretical rational underlying our role clarity framework. Here, we explain other advantages of considering the concepts of organizational role and role ambiguity in RE.   First, expectations elaborate the origin of a user’s business goals. Some of the goal-directed agent-based RE methods, such as the i* framework, consider the business goals besides the system goals of the users. However, i* does not present sufficient guidelines to elicit a user’s business goals. According to the concepts of role set and expectations proposed by the theory of role dynamics, we understand that the expectations form the user’s business goals. Moreover, we find that the expectations should be collected from the user’s role set.  Second, consequences enable the analysts to prepare for potential changes in how the business works. As discussed in chapter 2, it is important for analysts to understand how the business works. To the best of our knowledge, existing RE methods only focus on collecting this information; however, they do not question or even evaluate the accuracy of this understanding. For example, at the end of section 2.4.3.4, we explained that GBRAM proposes a set of guidelines to gather the business goals. However, this method does not include an evaluation process to check the accuracy of collected business goals. Consequences enable the analysts to evaluate a user’s current business goals and actions and to predict the potential changes in them. The power of consequences will be elaborated more in chapters 4 and 5. Third, we propose that analysts investigate the degree of role ambiguity regarding the users prior to collecting the domain knowledge from them.  Kahn et al. (1964) report the   34 existence of the role ambiguity for about 35 percent of a national sample. Therefore, it is highly possible that the users, whom are interviewed by the analysts, experience the role ambiguity in the organization.  To the best of our knowledge, the exiting RE methods do not investigate a user’s role ambiguity before processing the domain knowledge of the user. However, if the user does not have the clear, accurate, and adequate information about his or her organizational roles, then he or she is not a reliable source of knowledge to describe the business activities, system goals, and system requirements. We suggest that all the RE methods, specially the GORE approaches that are more concerned with the organizational aspects, check the degree of role ambiguity for a user prior to considering the user’s business knowledge. Rizzo et al. (1970) developed a questionnaire to measure the role ambiguity and conflict in complex organizations. The questionnaire can be found in Appendix B at the end of this dissertation. Now that the theoretical foundations of our study have been covered, we will introduce our role clarity framework in the next chapter.     35  Chapter 4: The Role Clarity Framework  4.1 Overview As discussed earlier, the main objective of this dissertation is to propose a method that describes business activities of users. As a solution, the role clarity framework provides system analysts with accurate business activities.  This chapter is structured as follows. Section 4.2 defines the main components of the role clarity framework, and section 4.3 elaborates how these components generate business activities.  4.2 Main Components of the Role Clarity Framework Figure 2 demonstrates a meta-model of fundamental concepts in this framework. The role clarity framework consists of three main components: namely, expectations, activities, and consequences.  4.2.1 Expectations The first essential component in the role clarity framework is a role’s expectations. Expectations show the role’s responsibilities, duties, and rights in the organization. To fulfill their needs, role set members determine the expectations and send them to the focal role. This process is called role sending. Expectations are sent from the role senders, but they are regulated by a broader context: the organization. Some organizational factors, such as the structure and formal reward system, determine the role set and the basis of the role’s expectations (Kahn et al., 1964). To apply the role clarity   36 framework, analysts can obtain the role’s expectations from the role set members if the user playing the focal role does not have accurate information about his or her responsibilities, duties, and rights in the organization.   4.2.1.1 Rights, Responsibilities, and Duties The theory of role dynamics does not provide further definitions regarding a role’s rights, responsibilities, and duties. However, to use the role clarity framework, we need to accurately determine these three concepts. According to Oxford Dictionaries, a Figure 2- A Meta-Model Describing the Fundamental Concepts in the Role Clarity Framework   37 right is a moral or legal entitlement to have or do something. For example, the sales associate has the right to answer a customer’s questions and the right to request the service manager to provide a cleaning schedule. In the role clarity framework, we use a role’s rights to identify the legal activities of a role. Rights also show the limits of a role’s authority over other roles (Kahn et al., 1964); therefore, we apply a role’s rights to send expectations from the focal role to the others.  In general, a responsibility and duty have a similar meaning. They both point out a thing that one is required to perform as a part of his or her job (Oxford Dictionaries). To find a clear distinction between these two terms, we refer to a definition proposed in the philosophy literature. Feinberg (1966) mentions that “A responsibility, like a duty, is both a burden and a liability; but unlike a duty it carries considerable discretion (sometimes called “authority”) along with it. A goal is assigned and the means of achieving it are left to the independent judgment of the responsible party.” (Feinberg, 1966, p.141). According to this definition, we infer that responsibilities only express the expectations, while duties are associated with some detailed activities required to fulfill the expectations.  Next, because the responsibilities provide individuals with authorities to choose their activities, given the responsibilities, individuals are more liable for the consequences of their behavior, specially their failures. As Feinberg says, “Indeed, the more discretion allowed in the responsibility assignment, the stricter the liability for failure is likely to be.” (Feinberg, 1966, p.141).    38 4.2.2 Activities The second essential component in the role clarity framework is a role’s activities. Activities are defined as a set of tasks required to accomplish the responsibilities and duties. Besides identifying the activities, analysts need to gather information about how a user can best perform those activities. Based on our discussion in section 4.2.1.1, if a role sender defines duties for the focal user, he or she also associates those duties with some specific activities. However, if the role sender sets responsibilities for the user, the user defines his or her activities to fulfill the responsibilities. Figure 3 shows how rights, responsibilities, and duties play different roles in developing activities.  As mentioned earlier, the main purpose of the role clarity framework is to describe business activities of users. A role’s activities shape the core of business activities; however, a role’s expectations and consequences are necessary to collect and Figure 3- A Meta-Model Describing How Expectations Develop Activities   39 evaluate the role’s activities. This will be elaborated more when we explain the role clarity process in section 4.3.1. 4.2.3 Consequences After establishing a role’s activities, the potential consequences of the role performance or non-performance for the focal role, role senders, and the organization are identified. Generally, consequences are used as feedback to evaluate the collected expectations and activities and to predict possible changes in them.  4.2.3.1 Three Types of a Role’s Consequences Based on the definition of a role’s consequences stated in section 3.2.3, we specify three types of consequences for each role. Type 1 consequences describe outcomes of a role’s successful or weak performance for itself. These consequences include the organizational rewards and punishments as well as their likelihood for the focal role (Kahn et al., 1964). For example, if the person, playing the sales associate role performs his or her tasks well, he or she is paid between 5-10% commissions for each vehicle sold. Otherwise, the person is fired if he or she performs the tasks poorly and cannot meet the commission target after 12 months. The Vision Quest Auto Dealership case study does not provide us with additional information about the likelihood of the rewards and punishments for the sales associate. However, if this information had been explained in the case study, we would have included it to describe type 1 consequences of the sales associate.  After gathering type 1 consequences of a user, analysts can evaluate whether collected expectations and activities are adequate to create positive outputs and prevent   40 from negative results for the user. The effects of type 1 consequences of the sales associate on evaluating and modifying the sales associate’s existing expectations and activities will be shown in the case study chapter.  Type 1 consequences include two subtypes: direct and indirect consequences. Type 1 direct consequences show outcomes for which the main responsible agent is the focal role. On the other hand, type 1 indirect consequences describe outputs for which other users (e.g. role set members) play a significant role. Collecting type 1 indirect consequences of a user is important. Although the focal user does not play the key role in type 1 indirect consequences, he or she is still able to increase the possibility of appropriate and decrease the possibility of improper outcomes by changing his or her expectations and activities. In order to infer one role’s type 1 indirect consequences, type 2 consequences of the role set members should be identified first. Type 2 consequences show possible opportunities or threats for a role set member, due to the focal user’s performance or non-performance in the organization. Role set members send expectations to the focal user, so the user’s performance or non-performance affects the role senders’ situation in the organization. The outcomes of the user’s performance or non-performance for a role sender are defined as type 2 consequences for the user and as type 1 indirect consequence for the role sender. For example, the sales manager, as the sales associate’s role sender, strives to have the sales team meet weekly and monthly sales quota. If the person, playing the sales associate role does not follow the sales quotas and does not perform his or her responsibilities well, he or she generates problems and punishments not only for himself or herself (type 1   41 consequence for the sales associate) but also for the sales manager (type 2 consequence for the sales associate).  We collect type 2 consequences for the focal user to modify his or her expectations and activities in order to generate useful and prevent from improper outcomes for his or her role senders. Because the sales manager is answerable for failures of its sales team, results of the sales associate’s proper performance or non-performance are collected as type 1 indirect consequences for the sales manager. If the user playing the sales manager role has enough information about those indirect consequences, he or she will be able to change expectations and activities to avoid the potential threats and create opportunities for himself or herself.  Type 3 consequences describe the effect of a role’s performance or non-performance on the organization. These consequences can be short-term or long-term and positive or negative results for the organization. The Vision Quest Auto Dealership case study does not provide us with any type 3 consequences; therefore, to clarify the third type, we use our own assumptions. We assume that if the sales associate does not provide an appropriate level of customer services, customers will not be satisfied to visit the auto dealership again. In turn, this will reduce benefits and the market size for the auto dealership. This information is captured as type 3 consequences for the sales associate. Given this information, the user playing the sales associate role is able to change his or her expectations and activities to avoid potential threats and create opportunities for the auto dealership. Figure 4 summarizes the discussed types of consequence.    42 To elaborate type 1 consequences, we suggest that system analysts explore a role’s rewards and punishments originally determined by the organization. However, type 2 and type 3 consequences may not be directly inferable from organizational documents, so analysts can apply a user’s personal experiences to understand them. 4.3 How Does the Role Clarity Framework Work?  After explaining essential components in the role clarity framework, we elaborate how these three components work together to generate a user’s business activities. Figure Figure 4- A Meta-Model Describing Three Types of Consequences   43 5 shows the role clarity framework. In this framework, the main unit of analysis is an organizational role. First, for any information system user, all of the organizational roles that he or she plays should be identified. Then, regarding each role, the role’s expectations, activities, and consequences are developed.  Based on consequences of the role, expectations and activities of the focal role and its role senders are evaluated, and if needed, they are updated. Sometime, the current expectations and activities should be changed because they are not proper to generate successful outcomes for the focal role, its role senders, and the organization. Also, sometimes new expectations and activities should be predicted to complement the current ones. For a role’ expectations and activities, separate evaluation processes are performed. Moreover, new activities should be collected for updated expectations. As discussed in 3.3.3, the evaluation processes are inferred from the effects of feedback on evaluating goals and actions in the theory of goal setting and task performance. All of the mentioned tasks shape the role clarity process in our framework. Regarding each role, this process may be performed in several iterations. The role clarity process should be repeated continuously until evaluating a role’s expectations and activities does not produce any new results. Otherwise, in the next iteration, updated activities develop new consequences to evaluate updated expectations and activities. When evaluation processes do not generate any new expectations or activities, we can finish the role clarity process. At this time, all the expectations, activities, and consequences shape the business activities of the focal role. If the focal user plays more than one role in the organization, the role clarity process should be executed for all of his or her roles.    44     Organizational Contexts  Alignment between the Role-Related Information and Organizational Contexts  Contextual Role-Related Information to Collect and Evaluate Business Activities   Intra-Role Information Flows  Business Activities   Inter-Role Information Flows Figure 5- The Role Clarity Framework   Expectations   Activities    Consequences    Organizational Contexts   A Role Sender   Legend Link1: role sending   Link3: assigning activities with duties   Link2: activities development   Link4: consequences development Link7: expectations evaluation Link8: activities evaluation Link9: expectations confirmation  Link10: activities confirmation Link5: type 2 consequences  Consequences   The Focal Role    Activities   Expectations   Link6: type 1 indirect consequences    45 The following section describes the above tasks as 13 steps of the role clarity process. These steps are distinguished from each other, and some are associated with syntactic formulas to clearly guide the analysts to collect the business activities of a user.  4.3.1 The Role Clarity Process Step 1. Establish a list of the information system users in the organization.  For any user in the list:  Step 2. Identify all of the organizational roles played by the user.  For each role R, follow steps 3-13: Step 3. Identify its role set members.  The relationship between the focal role and its role set members should be in alignment with the organizational structure. In figure 5, purple arrows from the organizational contexts to the relationships between a role sender and the focal role show this alignment. Step 4. Based on the relationship between the focal role and each of the role set members, describe the role’s expectations, including the role’s responsibilities, duties, and rights in the organization. In order to complete their activities, role senders send expectations to the focal role. Link1 in figure 5 shows the role sending from a role sender to the focal role. If the user, playing the focal role, has problems in understanding or recalling his or her role’s expectations, his or her role sender is considered as a good source of knowledge to describe those expectations. All of the role’s expectations should be in alignment with organizational objectives, organizational rules, and job   46 descriptions provided for each role. The purple arrows from the organizational contexts show this alignment.   Role R is expected to accomplish Expectation_Listr. Step 5. Explain the activities required to fulfill collected responsibilities (Link2). As mentioned previously, a duty is associated with a set of activities that are set by the role sender (Link3). For duties, use the predefined activities to complete the focal role’s activities list. Since expectation includes rights, rights should be considered in identifying the focal role’s activities. Finally, describe how the focal role can best perform its activities. For each Expectationrx in the Expectation_Listr, Find_Activities (Expectationrx) = Activity_Listrx Step 6. Elaborate the potential consequences of performing or non-performing the activities, for the focal role, its role senders, and the organization (Link4). These consequences include type 1 direct, type 2, and type 3 consequences. Type 1 indirect consequences will be elaborated in step 8.  To understand the role’s rewards and punishments, use the information provided by the formal reward system in the organization (purple arrows from the organizational contexts).  Based on activities of role R, Find_Consequences (Activitiesr) = Consequence_Listr Step 7. Based on type 2 consequences of the focal role, elaborate type 1 indirect consequences of role senders (Link5). In order to evaluate the expectations and activities of a role sender, perform the role clarity process from step 9 for the role   47 sender. It should be noted that figure 5 does not demonstrate all of the internal information flows (e.g. evaluation processes) within a role sender. Step 8. Elaborate type 1 indirect consequences of the focal role. To complete type 1 indirect consequences, first, find type 2 consequences of the role set members. Then, analyze how those consequences affect the focal role (Link6).  Step 9. Expectations Evaluation: Based on collected consequences in steps 6 and 8, evaluate whether the role’s expectations are accurate and proper. If expectations can be improved, change them. If needed, add additional expectations to complement the expectations list (Link7). After updating the role’s expectations, repeat the role clarity process from step 5 to find the required activities to fulfill the added or modified expectations. Expectations_Evaluation (Expectation_Listr , Consequence_Listr) = Updated_Expectation_Listr Step 10. Activities Evaluation: Based on collected consequences in steps 6 and 8, evaluate whether the role’s activities are accurate and proper to fulfill the relevant expectation. This step keeps the role’s expectations, but it helps to modify current activities or add new ones (Link8). Then, repeat the role clarity process from step 6 to find the new role’s consequences deriving from updated activities. For each Expectationrx in the Updated_Expectation_Listr, Activities_Evaluation (Activity_Listrx , Consequence_Listr) = Updated_Activity_Listrx Step 11. Confirm updated expectations and activities with role senders. Because originally role senders set the focal role’s expectations to complete their activities,   48 reflect the change in the focal role’s expectations in activities of role senders (Link9). If a role sender also determines the focal role’s activities (in case of a duty), reflect the updated activities of the focal role in the role sender’s activities (Link10).  If a role sender’s business activities have been collected so far, also they need to be updated. In order to do that, repeat the role clarity process from step 6 for the role sender. Step 12. Role Sending: When the focal role needs help of its role set members to complete its activities, it sends role set members some expectations. Identify role receivers and set their expectations and activities (in case of a duty).  Since the focal role needs legal authorities for a role sending, consider its rights (clarified in step 4) before setting expectations or activities of role receivers. Also, the role sending should be aligned with the organizational contexts, such as the structure and objectives.  Repeat the role clarity process from step 3 for all of the role receivers.   Step 13. Collect the focal role’s activities as (a part of) the role’s business activities.   4.4 Conclusion In this chapter, we defined three main concepts and a leading procedure in the role clarity framework to develop accurate business activities for information system users. A user’s business activities include expectations, activities, and consequences of the user’s roles in the organization. While a role’s activities shape the core of the business   49 activities, a role’s expectations and consequences contain essential contextual information to collect and evaluate activities. In the next chapter, we will apply the role clarity framework to Vision Quest Auto Dealership case study to analyze practicality of the proposed framework in collecting business activities.      50  Chapter 5:  Application of the Role Clarity Framework to a Case Study  5.1 Overview We introduced “Vision Quest Auto Dealership” case study in 3.1.1 and used it in different short examples in chapters 3 and 4. In this chapter, to show how analysts can run 13 steps of the role clarity process and analyze a role’s expectations, activities, and consequences, we apply the role clarity framework to one of the role descriptions in Vision Quest Auto Dealership case study. This case study narrates daily tasks of various roles in a small size auto dealership, located in the province of Manitoba. Among all of the roles discussed in this case, we apply the role clarity process to the sales associate role, because of availability of more detailed information about it than other roles.    This chapter is structured as follows. First, we describe the role clarity process regarding the sales associate role. Then, we discuss lessons that we learned from applying the proposed framework to the case study.    5.2 The Role Clarity Process for the Sales Associate Role Drawn from the role clarity framework (figure 5), an instance diagram describes the role clarity process for each role. For example, the instance diagram in figure 6 demonstrates the role clarity process regarding the sales associate role. As figure 6 shows, the sales manager and service manager are considered as two role set members of the sales associate.    51 The following steps explain the role clarity process for the sales associate. Since we have selected the sales associate role as the focal role in our analysis, we skip steps 1 and 2 of the role clarity process and start our analysis from step 3: Step 3. Identify the sales associate’s role set members.  The sales manager as the sales associate’s supervisor and the service manager and business manager as its co-workers, all together, constitute the role set of the sales associate.  Sales associate’s role set = {sales manager, service manager, business manager} Step 4. Based on the relationship between the sales associate and each of its role set members, describe the sales associate’s expectations, including its responsibilities, duties, and rights in the auto dealership. In section 4.2.1.1, we differentiated between a duty and responsibility. However, in analyzing the auto dealership case study, we found that the case presents information without distinguishing activities that are provided by the role senders (duty) vs. those that are derived by the focal role using expectations (responsibility). For this reason, we are unable to elaborate differences between duties and responsibilities in this case study, and consider all of them as expectations. The sales associate is expected to accomplish Expectation1, …, Expectation5. Expectation1: Promoting a sale (sent from the sales manager).  Expectation2: Handling the sales order (sent from the sales manager).  Expectation3: Meeting monthly and weekly sales quotas (sent from the sales manager). Expectation4: Contacting the service department regarding the sold vehicle (sent from the service manager).   52     Organizational Contexts  Alignment between the Role-Related Information and Organizational Contexts  Contextual Role-Related Information to Collect and Evaluate Business Activities   Intra-Role Information Flows  Business Activities   Inter-Role Information Flows Figure 6- The Instance Diagram to Demonstrate the Role Clarity Process regarding the Sales Associate    The Sales Associate  The Sales Manager   The Service Manager  Expectations   Activities   Consequences   Expectations   Activities   Consequences   Activities   Consequences   Expectations   Link1: role sending   Link3: assigning activities with duties   Link2: activities development   Link6: activities evaluation Link5: type 2 consequences   Organizational Contexts  Legend  Link12: role sending   Link13: assigning activities with duties   Link4: consequences development   Link7: type 1 indirect consequences  Link9: activities evaluation Link8: expectations evaluation Link10: expectations confirmation Link11: activities confirmation  53 Expectation5: Reporting the sales history to the business department (sent from the business manager). In figure 6, Link1 expresses expectations sent from the sales manager. However, the role sending from the business manager and service manager is not shown in this figure. Moreover, the following statements elaborates some of the sales associate’s rights in the auto dealership. These rights will be used to identify the sales associate’s legal activities and role sending from the sales associate to other roles later.   Right1: The sales associate is permitted to answer the customer’s questions. Right2: The sales associate is permitted to arrange a test-drive for the customer. Right3: The sales associate is permitted to request the service manager to provide a cleaning schedule. Right4: The sales associate is permitted to deliver the keys and documents to the customer.  Right5: The sales associate is permitted to negotiate on prices for used vehicle sales.  Step 5. Explain the sales associate’s activities required to fulfill its expectations (Link2 and Link3). Find_Activities (Expectation1) = Activity11, …, Activity13 Expectation1: Promoting a sale.  Activity11: Answer to customer’s questions (in alignment with Right1). Activity12: Arrange a test drive (in alignment with Right2). Activity13: Negotiate on the price for the used vehicle (in alignment with Right5).  Find_Activities (Expectation2) = Activity21, …, Activity24 Expectation2: Handling the sales order.  Activity21: Complete a sales order form.   54 Activity22: Inform the customer of a routine cleaning and inspection for the vehicle. Activity23: Ask the customer to return on an agreed date to complete the sales transaction. Activity24: Deliver the documents and keys to vehicle (in alignment with Right4). Find_Activities (Expectation3) =? Expectation3: Meeting monthly and weekly sales quotas. There is no specified activity in the case study to fulfill expectation3. We will infer relevant activities to accomplish this expectation after activities evaluation (step 10). Find_Activities (Expectation4) = Activity41, …, Activity42 Expectation4: Contacting the service department regarding the sold vehicle. Activity41: Request that the service manager provide a cleaning schedule for the sold vehicle. Activity42: Perform the final inspection before the customer arrives.  Find_Activities (Expectation5) =? Expectation5: Reporting the sales history to the business department. There is no specified activity in the case study to fulfill expectation5. We will infer relevant activities to accomplish this expectation after activities evaluation (step 10). Step 6. Elaborate the potential consequences of performing or non-performing the activities, for the sales associate, its role senders, and the auto dealership (Link4). Find_Consequences (Activitiy11, …, Activity13) = Consequence1, …,Consequences4 Consequence1: If the user occupying the sales associate role performs his or her role successfully, he or she will be able to keep his or her job in the auto dealership and will be paid between 5-10% commissions for each vehicle sold (Type 1 direct consequence).  55 Consequence2: The user occupying the sales associate role will be fired if he or she cannot meet the commission target after 12 months (Type 1 direct consequence). Find_Consequences (Expectation3) = Consequence3 Although we do not have any information about the activities required to fulfill expectation3, we know that: Consequence3: If the user occupying the sales associate role does not follow the quotas and does not perform his or her job very well, he or she will generate several problems for the sales manager, as his or her supervisor. Because, the sales manager is expected to have the sales team meet weekly and monthly sales quota and is answerable for the sales team failures (Type 2 consequence). Find_Consequences (Activitiy21, …, Activity24) = Consequence4 Find_Consequences (Activitiy41, …, Activity42) = Consequence4 Consequence4: If the user occupying the sales associate role does not provide an appropriate level of customer services, customers will not be satisfied to visit the auto dealership again. In turn, this will reduce benefits and the market size for the auto dealership (Type 3 consequence). In steps 9 and 10, we will demonstrate how consequence1 and consequence2 will be used to evaluate the sales associate’s expectations and activities.  Step 7. Based on type 2 consequences of the sales associate, elaborate type 1 indirect consequences of its role senders. Then, in order to evaluate the expectations and activities of a role sender, perform the role clarity process from step 9 for the role sender. Sales manager’s consequence1: The sales manager is expected to have the sales team meet weekly and monthly sales quota. If the user playing the sales associate role does not  56 follow the quotas and does not perform his or her job well, the sales manager is responsible for further failures (Link5). Sales manager’s expectation1: Having the sales team meet weekly and monthly vehicle sales quotas.  Given expectation1 of the sales manager, we evaluate the sales manager’s activities to fulfill this expectation.  Find_Activities (SalesManager_Expectation1) =? There is no specified activity in the case study to fulfill the sales manager’s expectation1. However, based on the sales manager’s consequence1, we assume that the sales manager should follow up with the sales associate on his or her understanding of sales quotas. Also, the sales manager should support the sales associate in improving his or her performance if needed. However, none of this information is provided in the case study. In reality, system analysts will need to go back to the sales manager to gather that missing information. For the purpose of this illustration, we assume the following complete list of required activities will fulfill the sales manager’s expectation1. Activities_Evaluation (SalesManager_Expectation1 , SalesManager_Empty_Activity_List1, SalesManager_Consequence1) = SalesManager_Updated_Activity11, …, SalesManager_ Updated _Activity17 Sales manager’s updated activity11: Develop sales plans. Sales manager’s updated activity12: Announce weekly or monthly sales quotas to sales associates at the beginning of each week or month. Sales manager’s updated activity13: Get feedback from sales associates about the feasibility of sales quotas.   57 Sales manager’s updated activity14: If needed, provide sales associates with additional information to illustrate strategies. Sales manager’s updated activity15: Monitor the performance of sales associates. Sales manager’s updated activity16: Give feedback to sales associates based on their performance.  Sales manager’s updated activity17: Document outcomes of sales plans.   In figure 6, Link6 shows elaborating mentioned activities based on consequnce1 of the sales manager. However, performing the whole role clarity process for the sales manager is out of the scope of this section. Step 8. Elaborate type 1 indirect consequences of the sales associate. Here, we analyze the consequence of the service manager’s weak performance on the sales associate.  Consequence5: If the service manager cannot handle cleaning and inspecting of a sold vehicle in the proper time, the vehicle is not ready when the customer returns on an agreed date. Probably, the customer will complain about the low customer service in delivering the vehicle. Because the sales associate is the only interface between the customer and auto dealership, the customer will complain about the sales associate’s weak performance in managing his or her order. This result is considered as a threat for the sales associate (Link7). In step10, we will show how consequence5 will be applied to evaluate the sales associate’s activities.   Step 9. Based on collected consequences in steps 6 and 8, evaluate whether the sales associate’s expectations are accurate and proper. Expectations_Evaluation (Expectation1, …,  Expectation5, Consequence1) = Updated_Expectation1, …, Updated_Expectation6  58 Expectation1: Promoting a sale. Expectation2: Handling the sales order.  Expectation3: Meeting monthly and weekly sales quotas.  Expectation4: Contacting the service department regarding the sold vehicle.  Expectation5: Reporting the sales history to the business department. Consequence1: If the user occupying the sales associate role performs his or her role successfully, he or she will be able to keep his or her job in the auto dealership and will be paid between 5-10% commissions for each vehicle sold.  Evaluation: Because the sale associate works for a commission, it should attempt to increase the number of sold vehicle. For example, the sales associate needs to find potential customers and promote a sale to them. However, this information is not provided in the case study. In reality, system analysts will need to go back to the sales associate to gather more information. For the purpose of this illustration, we assume another expectation (Updated expectation1) to complete the sales associate’s expectation list (Link8). Updated expectation1: Finding potential customers (sent from the sales manager).   Updated expectation2: Promoting a sale. Updated expectation3: Handling the sales order.  Updated expectation4: Meeting monthly and weekly sales quotas.  Updated expectation5: Contacting the service department regarding the sold vehicle.  Updated expectation6: Reporting the sales history to the business department. After updating the expectation list, we should find proper activities to fulfill the new expectation (Link2). However, these activities are not provided in the case study. Again,  59 in reality, system analysts will need to go back to the sales associate to gather the required activities. For the purpose of this illustration, we assume that the following list of activities will fulfill the sales associate’s updated expectation1. Find_Activities (Updated_Expectation1) = Updated_Activity11, …,  Updated_Activity18 Updated activity11: Search in organizational documents, such as the profile of past customers, to find potential people who want to purchase a vehicle.  Before searching in organizational documents, the sales associate should obtain required rights.   Updated activity12: Check online advertisement websites, such as Craigslist, to find potential customers. Updated activity13: Contact potential customers and offer available products to them.  Updated activity14: Answer to their questions.  Updated activity15: Record their favorite vehicle’s price and features. Updated activity16: Contact potential customers when a proper vehicle comes onto the market. Updated activity17: Be aware of promotional events.  Updated activity18: Inform potential customers about promotional events. Step 10. Based on collected consequences in steps 6 and 8, evaluate whether the sales associate’s activities are accurate and proper to fulfill the relevant expectation. Here, we explain two possible activities evaluations. Activities_Evaluation (Updated_Expectation4, Empty_Activity_List4 , Consequence2) = Updated_Activity41, …,  Updated_Activity44  60 Updated expectation4: Meeting monthly and weekly sales quotas. Consequence2: The user occupying the sales associate role will be fired if he or she cannot meet the commission target after 12 months.  Evaluation: There should be some guidelines to illustrate how the sales associate follows the sales quotas. Otherwise the sales associate cannot meet the commission target successfully, and consequently he or she will be fired. However, this information is not provided in the case study. Therefore, for the purpose of this illustration, we assume that the following activities will accomplish updated expectation4 (Link9). Updated actvity41: Receive sales quotas from the sales manager correctly. Updated actvity42: Ask questions if there is any difficulty or ambiguity in following sales quotas. Updated actvity43: Apply sales quotas in daily activities.  Updated actvity44: Report problems or deficiencies in fulfilling sales quotas to the sales manager. The next evaluation process that we explain here is evaluating the sales associate’s activities relevant to updated expectation5.  Activities_Evaluation (Updated_Expectation5, Activity_List5 , Consequence5) = Updated_Activity51, …, Updated_Activity54 Updated expectation5: Contacting the service department regarding the sold vehicle.  Activity51: Request that the service manager provide a cleaning schedule for the sold vehicle. Activity52: Perform the final inspection before the customer arrives.  Consequence5: If the service manager cannot handle cleaning and inspecting of a sold vehicle in the proper time, the vehicle is not ready when the customer returns on an  61 agreed date. Probably, the customer will complain about the low customer service in delivering the vehicle. Because the sales associate is the only interface between the customer and auto dealership, the customer will complain about the sales associate’s weak performance in managing his or her order.  Evaluation: The sales associate needs to follow up with the service manager on the vehicle inspection and cleaning before the due date. If the vehicle will not be ready by the due date, the sales associate should contact the customer and ask he or she to return later. Based on consequence5 and for the purpose of illustration, we assume the following activities will accomplish updated expectation5 (Link9). Updated activity51: Request that the service manager provide a cleaning schedule for the sold vehicle. Updated activity52: Follow up with the service manager on cleaning status of the vehicle. Updated activity53: Contact the customer and postpone the return date if needed. Updated activity54: Perform the final inspection before the customer arrives.  Step 11. Confirm updated expectations and activities with role senders. We should reflect updated expectations and activities of the sales associate in activities of the sales associate’s role senders. In figure 6, Link 10 and Link11 show changes in the sales manager’s activity lists, based on changes in the sales associate’s expectations and activities.  After updating the activity lists of all role senders, we should continue the role clarity process from step 6 for role senders. However, following the role clarity process for the sales manager and other role senders is out of the scope of this illustration.   62 Step 12. When the sales associate needs help of its role set members to complete its activities, it sends some expectations to its role set members. Identify role receivers and set their expectations and activities. We choose the service manager, as one of the sales associate’s role receivers, and identify its expectations and activities based on its relationship with the sales associate. In updated activity51, the sales associate should ask the service manager to handle the cleaning process for the sold vehicle. Also, in updated activity52, the sales associate requests that the service manager send updates about the cleaning process. To successfully perform these activities, the sales associate sets some expectations (duties) with relevant activities for the service manager (Link12 and Link13). Based on right3, we know that the sales associate is permitted to send these expectations and activities to the service managers. Again, these expectations are not provided in the case study. Therefore, for the purpose of illustration, we assume that we gathered the following expectations from the sales associate or service manager. The service manager is expected to accomplish ServiceManager_Expectation1. Service manager’s expectation1: Managing the cleaning procedure for the sold vehicle.  Find_Activities (ServiceManager_Expectation1) = ServiceManager_Activity11, …,  ServiceManager_Activity14 Service manager’s activity11: Control service technicians to clean the sold vehicle in the expected time. Service manager’s activity12: If the vehicle will not be ready prior to the due date, inform the sales associate in advance. Service manager’s activity13: Send updates to the sales associate regarding the cleaning status.  63 Service manager’s activity14: Ask the sales associate to perform a cleaning inspection before the customer returns.  Step 13. Collect the sales associate’s activities as the (part of) sales associate’s business activities. The sales associate’s activities (Updated_Activity_List1, …, Updated_Activity_List6) are considered as the core of the sales associate’s business activities, because they describe essential tasks that should be accomplished by this role in the auto dealership.  5.3 Discussion After analyzing the case study, we better perceived the difficulty and complexity of exploring domain knowledge. Studying how the business works is not easy; however, we believe that the role clarity framework provides analyst with valuable information to accurately understand a user’s business activities, before identifying the information system goals and requirements. In the following section, we describe what we learned about strengths of the role clarity framework from applying the framework to the Vision Quest Auto Dealership case study.  5.3.1 Lessons Learned from the Case Study Lesson learned #1: Expectations precisely describe where a user’s business goals come from. From many years ago, the concept of a user’s business goals has been considered in some RE methods. For example, the i* framework proposes an agent’s goals or soft-goals to show both system goals and business goals of a user. However, this method does not explain how a user’s business goals are developed. By introducing the idea of a role’s expectations and role senders, the role clarity framework describes where a user’s business goals come from— they are set by a user’s role senders in the  64 organization. Moreover, a user’s business goals can be changed based on consequences of the user performance or non-performance in the organization. A role’s expectations not only contain contextual information to collect a role’s business activities in our framework, but they can also supply a user’s business goals to various goal-oriented agent-based RE models.    For example, according to Vision Quest Auto Dealership case study, we know that “the sales associate’s job is to promote a sale.” Probably, the existing goal-oriented agent-based RE methods identify this statement as the sales associate’s goal; however, they do not explain why this statement shows a goal. In our framework, based on concepts of role senders and a role’s expectations, we view the mentioned statement as the sales associate‘s goal, because it shows an expectation held by the sales manager, as the sales associate’s role sender. By proposing the role clarity framework, this study hopefully supports the existing goal-oriented agent-based RE models in understanding business goals and activities of users in the organization. Besides, by applying the role clarity framework to the case study, we realized that if the focal user does not explicitly describe his or her expectations and activities, or if he or she needs to change them over time, analysts can find them by following the activities of his or her role senders. For example, Vision Quest Auto Dealership case study does not explicitly illustrate most of the activities discussed in step 12 (ServiceManager_Activity11, …,  ServiceManager_Activity13); however, we are able to explore them by following the sales associate’s activity list (Updated_Activity_List5). Lesson learned #2: Expectations are very useful, but consequences make our framework stronger. Understanding a role’s expectations is essential to develop the  65 role’s business activities. However analysts require an evaluation process to verify collected expectations and activities. A role’s consequences strongly support analysts in running the evaluation process. All users attempt to perform their activities very well in order to meet their favorite outcomes in the organization, such as finding an opportunity for growth, getting higher salary, and strengthening their team. Understanding preferred outcomes is a gold key for analysts to evaluate the collected expectations and activities of a user. Moreover, as shown in this chapter, a role’s negative consequences are crucial to be understood before evaluating expectations and activities.  For example, in Vision Quest Auto Dealership case study, Consequence2, Consequence3, and Consequence4 describe negative consequences of the sales associate role. Given this information, we can evaluate expectations and activities of the sales associate, in steps 9 and 10 of the role clarity process.  In addition, we learned that a role’s consequences not only are useful to develop the focal role’s business activities, but they also help analysts to describe a role sender’s business activities. Organizational members work with each other, so the way they perform their roles impacts on each other’s status in the organization. A user’s proper or weak performance can lead to opportunities or threats for the user’s role senders in the organization. For example, in step 7 of the role clarity process, we showed how the sales associate’s weak performance generates threats for the sales manager, and how these negative consequences determine new expectations and activities for the sales manager.   Last but not least, a role’s consequences enable analysts to look beyond the current business activities and anticipate the future ones. For instance, in step 9 of the  66 role clarity process, we considered a new expectation (Updated_Expectation1) for the sales associate to increase the sales associate’s commission pay (Consequence1).  Lesson learned #3: The role clarity framework is founded on the communication and interaction among users in the organization. Users are strongly related to and dependent on each other in the organization. We learned that understanding the roles dependencies enables analysts to determine a user’s business activities. More specifically, recognizing the communication among users is considered as an essential step in collecting a role’s expectations, activities, and consequences. First, to study a role’s expectations, analysts should find the relationship between the focal role and its role senders. Based on the relationship between the focal role and a role sender, analysts can determine the focal role’s expectations held by the role sender (step 4 in the role clarity process).  Second, based on our discussion in 2.3.1.2, analysts need to know what users should do in the organization 1) individually and 2) in collaboration with others. In both cases, a role’s activities are derived from the focal role’s communication with role set members. To understand what a role should do individually, analysts, first, should recognize the role’s expectations, and then they can elaborate required activities to fulfill expectations. Also, in order to recognize what the focal role should do in collaboration with others, there is no doubt that analysts have to analyze the existing relationships between the focal role and its role set members. For example, in Vision Quest Auto Dealership case study, the sales associate’s activities to promote a sale (Updated_Activity_List1) are determined based on the expectation set by the sales manager (Updated_Expectation1); however, most of them are  67 completed individually. To show the sales associate’s activities in collaboration with others, we can refer to Updated_Activity51 and Updated_Activity52, which are directly founded on the relationship between the sales associate and service manager.  Finally, also a role’s consequences are influenced by the communication between the focal role and its role senders. Type 1 indirect consequences exhibit how roles interactions lead to potential opportunities or threats for relevant roles. For instance, in Vision Quest Auto Dealership case study, we mentioned that if the service manager cannot handle the cleaning and inspecting of the sold vehicle in the expected time, his or her weak performance threatens the sales associate’s job safety (Consequecne5).  Lesson learned #4: The role clarity framework enables analysts to dynamically improve business activities of a user. In order to improve collected business activities of a user, analysts can continually repeat the role clarity process until no new expectations and activities are produced. In section 5.2, we described the first iteration of the sales associate’s role clarity process, we can continue the role clarity process for several iterations and obtain more accurate business activities regarding the sales associate.   At the first iteration, the sales associate’s expectations, activities, and consequences are collected, and then consequences are used to evaluate the expectations and activities. Also, the sales associate’s expectations, activities and consequences may impact on expectations, activities, and consequences of the sales manager and service manager. By completing the first iteration, we can collect the sales associate’s business activities. However, based on potential changes in business activities of role set members, we can improve the sales associate’s business activities in next iterations.   68 At the second iteration, expectations and activities of role senders are evaluated and updated. Based on these results, we can produce updated business activities for the sales manager and service manager. Similar to the previous iteration, updated expectations, activities, and consequences of role senders change the sales associate’s expectations, activities, and consequences. Subsequently, the sales associate’s updated business activities are collected, and relevant expectations and activities regarding the role set members are determined. The role clarity process for each role can be repeated continuously until evaluating the focal role’s expectations and activities does not generate any new results. At that time, the focal role’s final activities reflect the intended business activities of the focal role. From applying the role clarity framework to Vision Quest Auto Dealership case study, we perceived that our proposed framework has a very dynamic nature. Not only the focal role’s business activities are changeable over time, but also, at the same time, business activities of each role set member are under their own change. Each role sender has his or her own role set members determining and updating his or her business activities. For example, the sales manager’s business activities are adjustable due to changes in the vice president’s expectations for the sales manager, or the service manager’s business activities may be updated based on adjustments in the service technician’s business activities. The dynamic nature of the role clarity framework helps analysts to improve a role’s business activities and, consequently, to collect a more accurate and complete list of business activities regarding each user.   69 5.3.2 Limitations of the Case Study We selected Vision Quest Auto Dealership case study among several available case studies, because it clearly explains job description of various roles and demonstrates roles dependencies in an organization. However, since the case study was not originally written for the purpose of exploring the three essential components in the role clarity framework, we required to make some assumptions, specifically to determine consequences and evaluate expectations and activities.  Moreover, as discussed in the previous section, the role clarity process is intended to dynamically complement a user’s business activities. We found it difficult to continually extract information from a fixed and written case study. Practically, in the first iteration of the role clarity process, we gathered as much information as possible regarding the sales associate. Therefore, we believe that conducting a real interview with organizational members should more strongly manifest the power of the role clarity framework to collect and update business activities of users.   In addition, in Vision Quest Auto Dealership case study, we accessed to all of a role’s expectations and activities at the same time. This made our job very complicated to distinguish between a role’s responsibilities and duties. Again, in a real interview, we can ask users to differentiate between activities determined by them and ones assigned by their role senders.         70  Chapter 6: Conclusion  6.1 Summary of the Thesis In this dissertation, we pointed out that existing GORE methods require to analyze business activities of users prior to determining information system goals. Therefore, our study attempted to figure out what descriptions by organizational users help system analysts to better understand overall business activities. Drawn from two organizational behavior theories: role dynamics (Kahn et al., 1964) and goal setting and task performance (Locke & Latham, 1990), the role clarity framework describes a user’s business activities.  A role’s expectations, activities, and consequences constitute three essential components in the role clarity framework. We introduced the 13-step role clarity process to elaborate how analysts can gather a user’s expectations, activities, and consequences and, based on them, develop the user’s business activities.  At the end of this thesis, to analyze the strengths and practicality of the proposed framework, we applied the role clarity process to the Vision Quest Auto Dealership case study and collected the sales associate’s business activities. Results revealed that while a role’s activities reflect business activities of that role, expectations and consequences contain contextual information to support analysts in developing and evaluating the role’s business activities. More specifically, by utilizing the concepts of role set and expectations, the role clarity framework exhibits the origin of a user’s business activities.  71 Besides, consequences effectively enable the framework to evaluate current business activities of a user and anticipate potential ones.  6.2 Contributions of the Thesis Our study makes a number of contributions to research and practice. First, existing GORE surveys pay little attention to exploring the role description of organizational users. However, we believe that to accurately understand goals and requirements of an organizational information system, system analysts should, first, elaborate what users are expected to accomplish in the organization.  This dissertation proposes a theoretical framework to describe a user’s business activities. When analysts realize business activities of a user, then they can precisely determine system goals—why the user requires the information system—and system requirements—how the information system supports the user in fulfilling his or her business activities.  Second, to explain a user’s business activities, we operationalized the concept of role ambiguity from the theory of role dynamics, which specifies essential information that an organizational member needs to perceive in order to adequately understand his or her role in the organization. We believe this information is particularly useful for system analysts to develop a user’s business activities. Therefore, we suggest that analysts follow the role clarity process and gather a user’s business activities to elaborate tasks that a user is expected to perform in the organization.  Third, concepts of expectation and role sender elaborate where a user’s business goals come from. A role’s expectations are a remarkable achievement of the role clarity  72 framework; they help system analysts to precisely understand a user’s business goals, which are utilized by existing goal-oriented agent-based RE studies. Forth, the evaluation procedure is considered as a significant contribution of the role clarity framework. Evaluation supports system analysts in verifying a user’s collected business activities. In addition, when a user’s consequences include long-term outcomes of role performance, the evaluation process enables system analysts to predict potential business activities. This helps analysts to tackle changes in information system requirements at the beginning of system analysis, reducing late and extremely expensive corrections. Fifth, the role clarity framework is developed based on the relationships among organizational members, such as the relationship between the focal role and its role senders. Focusing on existing communications in the organization, prior to design an information system, aids the intended system to effectively facilitate a user’s communications in the organization.  6.3 Limitations of the Thesis and Directions for Future Research This thesis has several limitations. First, we used the Vision Quest Auto Dealership case study to demonstrate the power and practicality of the role clarity framework to describe a user’s business activities. However, further empirical research should be undertaken to better observe and analyze strengths and weaknesses of the proposed framework.  The initial motivation of this study was to find a solution for describing a user’s business activities in order to determine an accurate list of information system goals. It is  73 recommended that future studies conduct empirical models to compare a user’s business goals, tasks, and information system goals developed by the role clarity framework with ones produced by other methods, such as the i* framework (Yu, 1997a, 2009, 2011).  Second, in this study, we assumed that a user does not perceive any conflict among his or her expectations; however, in the real world, his or her role senders may impose several incompatible expectations on him or her. Therefore, in order to address various types of conflicts among a user’s expectations, future research should focus on the concept of role conflict proposed by the theory of role dynamics and study how to manage role conflict in the role clarity framework.  Third, the Vision Quest Auto Dealership case study plainly describes expectations, activities, and consequences of several roles. Possibly, a real world role description contains more complex and detailed expectations, activities, and consequences, gathering of which requires more precisions. In order to offer a practical approach to the role clarity framework, future research should be conducted to define a set of items to comprehensively narrate expectations, activities, and consequences in a real interview. For example, the process clarity scales proposed by Sawyer (1992) can be utilized to elaborate the scheduling, time allocation, and best way of accomplishing in a user’s activities.  Forth, as mentioned previously, the role clarity framework is developed based on the relationship among organizational members. By applying the results of the proposed framework, system developer, we expect, build an information system that effectively facilitates communications in the organizations. Consequently, the intended information system will allow the focal user to better connect to his or her role senders and perform  74 adequate activities in the organization. This, we hope, will lead to reducing overall role ambiguity for organizational members. An interesting research direction would be to investigate the relationship between applying the role clarity framework to develop a system and role ambiguity perceived by employees after using the system. Finally, as another useful study to reduce role ambiguity in organizations, one goal for future research could be to utilize the essence of the role clarity framework in designing an organizational learning system. This learning system collects necessary information about each organizational role and distributes it between each role and its role senders. This helps employees to learn what they are expected to do currently and possibly in the future to fulfill organizational objectives. We hope this research will be effective to decrease role ambiguity among individuals in the organization.     75  Bibliography Alter, S. (2013). Work system theory: overview of core concepts, extensions, and challenges for the future. Journal of the Association for Information Systems, 14(2), 72–121. Anton, A. I. (1996). Goal-based requirements analysis. In Requirements Engineering, 1996., Proceedings of the Second International Conference on (pp. 136–144). IEEE. Anton, A. I. (1997). Goal Identification and Refinement in the Specification of Information Systems. Georgia Institute of Technology. Appan, R., & Browne, G. J. (2012). The impact of analyst-induced misinformation on the requirements elicitation process. MIS Quarterly, 36(1), 85–106. Bedeian, A. G., & Armenakis, A. A. (1981). A path-analytic study of the consequences of role conflict and ambiguity. Academy of Management Journal, 24(2), 417–424. Castro, J., Kolp, M., & Mylopoulos, J. (2002). Towards requirements-driven information systems engineering: the< i> Tropos</i> project. Information Systems, 27(6), 365–389. Chen, P. P.-S. (1976). The entity-relationship model—toward a unified view of data. ACM Transactions on Database Systems (TODS), 1(1), 9–36. Dardenne, A., Van Lamsweerde, A., & Fickas, S. (1993). Goal-directed requirements acquisition. Science of Computer Programming, 20(1), 3–50. Davidson, E. J. (2002). Technology frames and framing: A socio-cognitive investigation of requirements determination. MIS Quarterly, 26(4), 329–358. Davis, G. B. (1982). Strategies for information requirements determination. IBM Systems Journal, 21(1), 4–30. Davis, W. S., & Coleman, P. (1994). Casebook for Davis’s Business systems analysis and design. Belmont, California: Wadsworth. De, P., & Sen, A. (1984). A new methodology for database requirements analysis. MIS Quarterly, 8(3), 179–193.  76 Feather, M. S. (1987). Language support for the specification and development of composite systems. ACM Transactions on Programming Languages and Systems (TOPLAS), 9(2), 198–234. Feinberg, J. (1966). Duties, rights, and claims. American Philosophical Quarterly, 3(2), 137–144. Greenspan, S. J., Mylopoulos, J., & Borgida, A. (1982). Capturing more world knowledge in the requirements specification. In Proceedings of the 6th international conference on Software engineering (pp. 225–234). IEEE Computer Society Press. Greenspan, S., Mylopoulos, J., & Borgida, A. (1994). On formal requirements modeling languages: RML revisited. In Proceedings of the 16th international conference on Software engineering (pp. 135–147). IEEE Computer Society Press. Kahn, R. L., Wolfe, D. M., Quinn, R. P., Snoek, J. D., & Rosenthal, R. A. (1964). Organizational stress: Studies in role conflict and ambiguity. John Wiley & Sons Inc. Keen, P. G., & Morton, M. S. S. (1978). Decision support systems: an organizational perspective (Vol. 35). Addison-Wesley Reading, MA. Liu, L., & Yu, E. (2004). Designing information systems in social context: a goal and scenario modelling approach. Information Systems, 29(2), 187–203. Locke, E. A., & Latham, G. P. (1990). A theory of goal setting & task performance. Prentice-Hall, Inc. Mantha, R. W. (1987). Data Flow and Data Structure modeling for database requirements determination: a comparative study. MIS Quarterly, 11(4), 531–545. Montazemi, A. R., & Conrath, D. W. (1986). The use of cognitive mapping for information requirements analysis. MIS Quarterly, 10(1), 45–56. Munro, M. C., & Davis, G. B. (1977). Determining management information needs: a comparison of methods. MIS Quarterly, 1(2), 55–67. Munro, M. C., & Wheeler, B. R. (1980). Planning, critical success factors, and management’s information requirements. MIS Quarterly, 4(4), 27–38. Mylopoulos, J., Chung, L., & Yu, E. (1999). From object-oriented to goal-oriented requirements analysis. Communications of the ACM, 42(1), 31–37.  77 Nuseibeh, B., & Easterbrook, S. (2000). Requirements engineering: a roadmap. In Proceedings of the Conference on the Future of Software Engineering (pp. 35–46). ACM. Nutt, P. C. (1986). Evaluating MIS design principles. MIS Quarterly, 139–156. Orlikowski, W. J. (1996). Improvising organizational transformation over time: A situated change perspective. Information Systems Research, 7(1), 63–92. Orman, L. (1987). Information intensive modeling. MIS Quarterly, 11(1), 73–84. Panko, R. (2012). RETHINKING“ SYSTEMS” IN INFORMATION SYSTEMS (SYSTEMATICALLY). Presented at the 2012 EUROPEAN CONFERENCE ON INFORMATION SYSTEMS. Pareek, U. N. (2002). Training Instruments in HRD and OD. Tata McGraw-Hill. Pries-Heje, J., & Baskerville, R. (2008). The design theory nexus. MIS Quarterly, 32(4), 731–755. Regev, G., & Wegmann, A. (2005). Where do goals come from: the underlying principles of goal-oriented requirements engineering. In Requirements Engineering, 2005. Proceedings. 13th IEEE International Conference on (pp. 353–362). IEEE. Rizzo, J. R., House, R. J., & Lirtzman, S. I. (1970). Role conflict and ambiguity in complex organizations. Administrative Science Quarterly, 150–163. Rolland, C., Souveyet, C., & Achour, C. B. (1998). Guiding goal modeling using scenarios. Software Engineering, IEEE Transactions on, 24(12), 1055–1071. Ross, D. T. (1977). Structured analysis (SA): A language for communicating ideas. Software Engineering, IEEE Transactions on, 3(1), 16–34. Sawyer, J. E. (1992). Goal and process clarity: Specification of multiple constructs of role ambiguity and a structural equation model of their antecedents and consequences. Journal of Applied Psychology, 77(2), 130–142. Shlaer, S., & Mellor, S. J. (1988). Object-oriented systems analysis. Yourdon. Singh, S. N., & Woo, C. (2008). A methodology for discovering goals at different organizational levels. Proceedings of BUSITAL, 8, 16–30. Singh, S. N., & Woo, C. (2009). Investigating business-IT alignment through multi-disciplinary goal concepts. Requirements Engineering, 14(3), 177–207.  78 Strong, D. M., & Volkoff, O. (2010). Understanding organization-enterprise system fit: a path to theorizing the information technology artifact. MIS Quarterly, 34(4), 731–756. Sun, F. (2009). Translating requirements specified in goals to UML diagrams. University of British Columbia. Sutcliffe, A. (2002). RE Tasks and Processes. In User-centred requirements engineering. Springer. Tillquist, J., King, J. L., & Woo, C. (2002). A representational scheme for analyzing information technology and organizational dependency. MIS Quarterly, 26(2), 91–118. Van Lamsweerde, A. (2000). Requirements engineering in the year 00: A research perspective. In Proceedings of the 22nd international conference on Software engineering (pp. 5–19). ACM. Van Lamsweerde, A. (2001). Goal-oriented requirements engineering: A guided tour. In Requirements Engineering, 2001. Proceedings. Fifth IEEE International Symposium on (pp. 249–262). IEEE. Wang, W. (2004). An OOEM-Based Goal Modeling. University of British Columbia. Wasserman, A. I., & Stinson, S. K. (1979). A specification method for interactive information systems. In Proceedings SRS-Specification of Reliable Software (pp. 68–79). Watson, H. J., & Frolick, M. N. (1993). Determining information requirements for an EIS. MIS Quarterly, 17(3), 255–269. Wetherbe, J. C. (1991). Executive information requirements: getting it right. MIS Quarterly, 15(1), 51–65. Yourdon, E., & Coad, P. (1990). Object-oriented analysis. Prentice Hall. Yu, E. (1997a). Towards modelling and reasoning support for early-phase requirements engineering. In Requirements Engineering, 1997., Proceedings of the Third IEEE International Symposium on (pp. 226–235). IEEE. Yu, E. (1997b). Why Agent-Oriented Requirements Engineering. In Proceedings of 3rd Workshop on Requirements Engineering For Software Quality.  79 Yu, E. (2009). Social Modeling and i*. In Conceptual Modeling: Foundations and Applications (pp. 99–121). Springer. Yu, E. (2011). Modelling strategic relationships for process reengineering. In Social Modeling for Requirements Engineering (pp. 11–152). Yu, E., Giorgini, P., Maiden, N., & Mylopoulos, J. (2011). 1 Social Modeling for Requirements Engineering: An Introduction. In Social Modeling for Requirements Engineering (pp. 3–10). Yu, E., & Mylopoulos, J. (1998). Why goal-oriented requirements engineering. In Proceedings of the 4th International Workshop on Requirements Engineering: Foundations of Software Quality (Vol. 15). Yu, E. S. (1993). Modeling organizations for information systems requirements engineering. In Requirements Engineering, 1993., Proceedings of IEEE International Symposium on (pp. 34–41). IEEE. Zmud, R. W., Anthony, W. P., & Stair Jr, R. M. (1993). The use of mental imagery to facilitate information identification in requirements analysis. Journal of Management Information Systems, 9(4), 175–191.     80  Appendices  Appendix A: The Vision Quest Auto Dealership Case Study for Chapters 3-5  Lee Atwell is the president/owner of Vision Quest Auto dealership. He employs a vice president, a business manager, a sales manager, a service manager, a parts manager, seven sales associates, and ten service technicians. The vision of the Auto dealership is to establish a firm ground in the province of Manitoba and eventually across Canada and finally into the United States. Currently Vision Quest Auto controls an estimated 8% of vehicle sales in Manitoba. Lee Atwell is hoping to increase the sales to 12% within the next 5 years. The primary activities of Vision Quest Auto include ordering new vehicles for inventory; pricing used vehicles; deciding which vehicles to sell to wholesalers; servicing vehicles; selling vehicle parts. To have an understanding of the operations, an overview of the typical day-to-day business transactions (selling a new/used vehicle and parts) is presented in the section below. Selling a Vehicle The selling process begins when a customer enters the showroom. The sales associate’s job is to promote a sale, which includes answering the customer's questions and arranging a test drive. Once the customer decides to purchase a vehicle, the sales associate completes a sales order form and informs the customer of a routine cleaning and inspection for the vehicle. The customer is then asked to return on an agreed date to  81 complete the sales transaction. The sales associate then requests the service manager to provide a cleaning schedule for the vehicle. After the vehicle is cleaned, the service manager requests the sales associate to perform a final inspection before the customer arrives. When the customer returns, he pays the business manager. Payment may be made through cash, cheque or a financial institution. If a payment is to be made through a financial institution, the business manager contacts the financial institution for confirmation. After the financial details are completed, the business manager then tries to sell the customer a maintenance contract, which the customer may accept or decline. Finally, the customer is escorted back to the sales associate who delivers the documentation and the keys to the vehicle. Used vehicle sales follow much the same process, but there is some negotiation on prices. Selling Vehicle Parts When a customer purchases parts, the parts manager completes an invoice with the total cost and instructs the customer to pay the business manager. After paying, the customer returns with an invoice marked paid and collects the parts from the parts manager. Management and Executive Transactions This section describes other activities performed by the managers to ensure that Vision Quest Auto is maintaining customer’s loyalty, a high quality service, and increasing sales to 12% over the next 5 years. Sales Manager: The sales manager strives to have his sales team meet weekly and monthly vehicle sales quotas. He is also responsible for tracking deals (vehicle sales) and customers follow up; monitoring the daily newspaper advertisements for competitive  82 prices; and, adjusting vehicles prices. Every month, the nearby wholesaler makes a request for purchasing vehicles. The wholesaler sends in an order to the sales manager who then determines whether he is capable of fulfilling the request. Business Manager: The business manager is responsible for calculating the commissions for the sales associates. The sales associates work for a commission, and are paid between 5-10 % commissions for each vehicle sold. Sales associates who do not meet their commission target after 12 months are fired.  Parts Manager: The parts manager is responsible for maintaining appropriate inventory levels while ensuring periodic parts turnover. He also adjusts the stock to curtail accumulation of unused parts. The reorder point varies (due to the season, the age the part etc.) throughout the year. When reordering, the parts manager prepares an invoice and sends it to the business manager, who then prepares an ordering invoice. The parts manager is then responsible for faxing the invoice to the manufacturer, tracking the order's progress, receiving the part, notifying the service manager when the part arrives, and submitting the bill to the business manager who then pays the supplier. Service Manager: Vision Quest Auto also runs a servicing department and the service manager is responsible for managing the workflow in that department, and preparing a weekly schedule for the service technicians. Vision Quest Auto's policy is to keep roughly between 5-15% of the service technicians’ time available to deal with drop-ins and emergencies. This percentage is not easy to determine since one of the goals of the servicing department is to return customer’s vehicles in the shortest possible time.    83 Vice President: The vice president (VP) job is to ensure that Vision Quest Auto is working progressively towards achieving the long term targets, for example – achieving a 12% increase in customer sales over the next 5 years. Some of the tasks performed by the vice president are:   Forecasting Sales  – the VP continuously analyzes the competitors, the growth of the vehicle industry and the value of services it is offering to its customers. He performs quarterly analysis and if the forecasts do not match with the projected forecast, he suggests changes to the short-term strategies, for e.g. reducing the profit margin on  Bundling of Services  – the VP analyzes the models of vehicles visiting the service department and compares these models with the models that Vision Quest Auto is carrying in its showroom. Vehicle models that visit the service shop most often are deemed “problematic” models. If the profit margins for these “problematic” models are too small, then the VP would suggest to the sales manager to discontinue selling these vehicles. If the profit margin is large, the VP will propose bundling services to customers who purchase the “problematic” models, for e.g. he may suggest offering the customer a bundle which includes free tire alignment and free oil change for one year.  Keeping Loyal Customers  – the VP analyzes the frequency of customer visits, whether it is to buy a new part or buy a new vehicle. He also analyzes the demographics of the customers such as age, income, type of vehicle purchased. Based on these data, he will suggest to the sales manager to recognize the customer loyalty by either offering the customer a gift; or a discount on his/her next purchase.    84  Appendix B: Rizzo et al. (1970) Questionnaire to Measure Role Ambiguity and Conflict for Chapter 3     1- I have enough time to complete my work. 2- I feel certain about how much authority I have. 3- I perform tasks that are too easy or boring. 4- Clear, planned goals and objectives for my job. 5- I have to do things that should be done differently. 6- Lack of policies and guidelines to help me. 7- I am able to act the same regardless of the group I am with. 8- I am corrected or rewarded when I really don't expect it. 9- I work under incompatible policies and guidelines. 10- I know that I have divided my time properly. 11- I receive an assignment without the manpower to complete it. 12- I know what my responsibilities are. 13- I have to buck a rule or policy in order to carry out an assignment. 14- I have to "feel my way" in performing my duties. 15- I receive assignments that are within my training and capability. 16- I feel certain how I will be evaluated for a raise or promotion. 17- I have just the right amount of work to do. 18- I know that I have divided my time properly. Item number Statement  85 19- I work with two or more groups who operate quite differently. 20- I know exactly what is expected of me. 21- I receive incompatible requests from two or more people. 22- I am uncertain as to how my job is linked. 23- I do things that are apt to be accepted by one person and not accepted by others. 24- I am told how well I am doing my job. 25- I receive an assignment without adequate resources and materials to execute it. 26- Explanation is clear of what has to be done. 27- I work on unnecessary things. 28- I have to work under vague directives or orders. 29- I perform work that suits my values. 30- I do not know if my work will be acceptable to my boss.    

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:
https://iiif.library.ubc.ca/presentation/dsp.24.1-0132750/manifest

Comment

Related Items