Enterprise Modelling and the Teleological Approach - Semantic Scholar

Enterprise Modelling and the Teleological Approach to Requirements Engineering P. Loucopoulos & E. Kavakli Department of Computation UMIST P.O. Box 88 Manchester M60 1QD U.K. {pl, kavakli}@sna.co.umist.ac.uk

Abstract A critical factor in successful requirements analysis appears to be the understanding not only of what the system under consideration should do, but also why. To capture the purpose of an information system, one needs a mechanism to describe the behaviour of the organisation in which the system will operate. This approach suggests further understanding and modelling of the organisational goals and the way that these goals become operationalised. In software systems development we often make the distinction between the enterprise world and the system world. The former describes the domain about which the proposed software system is to provide some service, while the second is concerned with specifications on what the system does and include descriptions of the systems requirements, conceptual designs and implementations. This paper describes an approach which involves the explicit modelling of organisational objectives, social roles and operations and the synthesis of these different perspectives towards a set of information systems requirements.

1.

Introduction

It is increasingly being recognised that the success of information systems in terms of their functionality and acceptance by their customers and users, depends to a large extent on the ability of system developers to correctly specify requirements from a potentially diverse set of stakeholders. Therefore, the effective discovery, specification and analysis of requirements is a highly critical step in the software life cycle. A great variety of problems can arise during this step, e.g. inadequacies, incompleteness, contradictions, ambiguities, etc.

Such errors and deficiencies can have disastrous effects on the subsequent development steps and on the quality of the resulting software product. We maintain that the challenging issue of how to proceed from informal, fuzzy individual statements of requirements, to a formal specification that is understood and agreed by all stakeholders, remains unanswered. This view is re-enforced by empirical evidence. For instance, it is reported in [Curtis, Krasner, et al 1988] that “requirements volatility causes major difficulties during development” whilst Lubars reports that a number of issues regarded as being important by users, such as recording of assumptions and decisions, understanding of changes due to enterprise changes and the use of domain models, are left unanswered by current technology [Lubars, Potts, et al 1993] . Our approach attempts to address these specific issues in the context of assisting a requirements engineer to proceed from fuzzy, ill-defined requirements to formal requirements expressions. We advocate the development and exploitation of different knowledge sources about the requirements engineering products, and the activities themselves. In particular we advocate the explicit modelling of enterprise knowledge according to a structured framework which incorporates different viewpoints that provide insights into the purpose of the system, its operational characteristics and its implication on the roles of the different actors affected by the system itself. This implies a close relationship between issues found in two domains of concern, namely, the enterprise and the information system. By bridging these two domains one can begin to incorporate measurement parameters, justification criteria and explanations about the information system ‘product’ and the ‘process’ by which it was developed, in terms of ‘real-world’ objectives, needs and phenomena. The paper is organised as follows. Section 2 discusses a number of basic issues in requirements engineering that have motivated our work. Section 3 introduces the notion of ‘enterprise modelling’ giving an overview of the requirements of different fields as well as the different approaches applied within these fields. Section 4 discuss in detail our approach to enterprise modelling as applied within requirements engineering. To this end, this section discusses the modelling orientation adopted in our method in terms of the teleological, social and technical perspectives and defines a high-level meta-model for each perspective. Section 5 shows how enterprise requirements are related to information system requirements using the teleological view as the motivating factor for the method. The concepts and the method are illustrated using the Air Traffic Control (ATC) case described in the Appendix. Section 6 concludes by discussing in broad terms the need for using requirements engineering as a change management mechanism which will ultimately benefit enterprises striving to ___________________________________________________________________________ P. Loucopoulos & E. Kavakli

IJICS

page 2

transform their operations and structures as well as providing a firm foundation for information systems to support such a transformation.

2.

Requirements Specification and Analysis

The term requirements engineering (RE) has been defined as the systematic process of developing requirements through an iterative co-operative process of analysing the problem, documenting the resulting observations in a variety of representation formats and checking the accuracy of the understanding gained. This definition is based on the premise that the RE process involves aspects of concern along three dimensions: the representation, cognitive and social dimensions [Pohl 1993] . Issues of representation range from informal descriptions such as natural language expressions to formal conceptual modelling languages. Issues in the cognitive domain concern different orientations of models in terms of understanding the process itself and validating the requirements. In the social domain, consideration is given to the complex social process in which the communication and cooperative interaction between the stakeholders of the requirements determines the quality of the final product. The process of RE represents a continuous interplay between factors from all three domains resulting in successive versions of what has been traditionally termed a requirements specification. According to [Rzepka and Ohno 1985] a requirements specification represents both a model of what is needed and a statement of the problem under consideration. The structure of the specification itself varies according to different standards and practices [DOD-STD-2167A 1988; IEEE-Std.’830’ 1984; NCC 1987] . The role of requirements specification is multifaceted. For example, it could and should be the means by which a potentially large and diverse population of requirements stakeholders and requirements analysts communicate. The specification itself can be used for clarifying a situation about the intended system or its environment i.e. the organisational context. The specification may also be part of contractual arrangements, a situation that may become especially relevant when an organisation wishes to procure a system from some vendor rather than develop it ‘in house’. The specification could also be used for evaluating the final product and could play a leading role in any acceptance tests agreed between system consumer and supplier. The traditional view of a requirements specification is that of a functional specification i.e. a definition of the desired service of the intended system. However, this over-reliance on functional specifications has been criticised as having a number of undesirable side effects. ___________________________________________________________________________ P. Loucopoulos & E. Kavakli

IJICS

page 3

One concern is the amount of detail with which both requirements holders and requirements analysts have to deal. It has been argued c.f. [McDermid 1994] that when a functional specification becomes the focal point of requirements analysis then one makes a decision on the boundary of the system before any understanding is gained of the real needs of the requirements holders. In other words, functional specifications tend to deflect attention from other important aspects. For example, it is at least as important as defining a functional specification to consider issues such as the objectives of the system itself and the relationship of these to organisational objectives or specifying other desirable properties of the system (e.g. performance, security, usability, etc.) and constraints on its development (e.g. use of a particular toolset, economic constraints etc.). It is only then that one can adequately understand the reasoning behind the needs and aspirations of requirements holders. Furthermore, such a wider view of a requirements specification could accommodate situations requiring resolution of conflict of requirements at an organisational level, deciding to give priorities to the stated requirements, or evaluating alternative scenarios for the satisfying of the stated requirements. The purpose of building a software system is to be found outside the system itself, in the enterprise1, i.e. the context in which the system will function. Many authors have argued that requirements of customers need to be represented in a specification in terms of observed phenomena about the enterprise itself [Bubenko, Rolland, et al 1994; Bubenko 1994; Bubenko and Wangler 1993; Greenspan, Mylopoulos, et al 1994; Jackson 1994; Loucopoulos 1991; Loucopoulos and Katsouli 1992; Loucopoulos, McBrien, et al 1991; Nellborn, Bubenko, et al 1992; Yu and Mylopoulos 1994; Yu 1993] . A broader view therefore, of requirements specification is one that goes beyond the description of system functionalities. A functional specification should be one view supplemented, or even motivated by an explicit definition of the enterprise within which the system will eventually operate. We advocate that such a definition is a fundamental prerequisite to the development of a common understanding of the requirements holders, system customers, system users and system developers about the problem in hand. The emerging consensus within the RE community is that a requirements specification should include not only software specifications but also any kind of information describing ‘real world’ phenomena. In other words, requirements need to be articulated in the framework of ‘real-world’ knowledge which would provide the purpose of the intended system as well as the knowledge about the phenomena common to the enterprise and system domains.

1

Synonyms of this are the terms ‘application domain’ and ‘environment’.

___________________________________________________________________________ P. Loucopoulos & E. Kavakli

IJICS

page 4

Elaborating on enterprise aspects delimits the scope of the investigation as well as providing a context and justification for the intended system or system component.

3.

Enterprise Modelling

3.1

Overview

The need for enterprise modelling stems from a number of different considerations but there is a common thread amongst all these approaches namely “the need for integration and co-ordination of activities required in order to meet rapid change”.

The traditional approach to information systems development has proved to be too monolithic and lacking facilities for dealing with highly complex, multidimensional, and distributed systems. In the traditional paradigm little attempt is made in understanding how the proposed system relates to other components (some of which may be legacy systems themselves) or the effect that the system will have on the enterprise itself. A new approach, based on explicit modelling of enterprise concepts has been proposed as a way to alleviate these problems [Hein 1990] . This approach advocates the analysis of enterprise components prior to engaging in information system analysis and specification activities. Enterprise modelling is about describing, in some formal way, a social system with its agents, work roles, goals, responsibilities and the like. Early examples of techniques and formalisms for including enterprise models in a requirements specification include [MacDonald 1986; Mercurio, Meyers, et al 1990] . More recent approaches tend to expand on the earlier results, recognising that it is advantageous to examine an enterprise from multiple perspectives [Dobson 1992; Nellborn, Bubenko, et al 1992; Yu 1993] . Enterprise modelling supports the strategic alignment task as well as the management of planning evolution and change of business systems and practices. It provides the means for describing the current structure of the enterprise, its missions and objectives. It can also be used as a reasoning tool for evaluating the consequences of the applied technology and the business redefinition onto the enterprise and its agents.


IJICS

page 5

Enterprise modelling has been examined from a number of different perspectives. Prominent amongst these are efforts in the areas of Computer Integrated Manufacturing (CIM), Enterprise Integration (EI), Business Process Re-engineering (BPR) and Information Systems Engineering. The CIM technology links automation systems such as Data Processing, Computer Aided Design, Computer Aided Manufacturing and Flexible Manufacturing Systems into a distributed processing system. Enterprise models that describe the overall organisational objectives, can be used to specify the characteristics of the CIM system in terms of what is required for the enterprise concerned. As a reasoning tool the enterprise model can be used to analyse precisely the current status of the manufacturing system and identify possible problems (i.e. evaluate the benefits/drawbacks of the implemented CIM system to the enterprise; estimate the effects of the new technology to the working relationships in the enterprise and the human factor involved). It can be used to make a diagnosis of each system activity and evaluate its operations, as well as produce a specification of the altered activities of the new system. Examples of enterprise modelling methodologies towards CIM systems development are the M* methodology [Berio, Dileva, et al 1993] , the CIM Reference Architecture in CIM-OSA [Kosanke and Vlietstra 1989] and EMS [Graefe and Chan 1993] . In EI one is interested in the co-ordination of different individuals, or groups that share a common goal. This integration can happen at intra-company, inter-company or even at virtual-company level. For example the manufacture of cars and aeroplanes requires the coordination of not only thousands of people within the manufacturing organisation, but also a large number of subcontractors and suppliers. In this domain enterprise modelling is considered as a corporate activity that produces models of the information resources, information flows, and business operations that occur in the enterprise [Goranson 1992; Petrie 1992; Scheer and Hars 1992] . The resultant models describe the business environment in such a way so as to provide a common language to describe the heterogeneous enterprise components and their functions, to predict the effects of changing and to support strategic decision making. Business Process Reengineering is defined as the redesign of an organisation’s business processes to make them more efficient [Curtis, Kellner, et al 1992] . It involves the fundamental analysis and radical redesign of processes, social systems, organisational structure and management approaches to achieve performance improvements in cost, speed, customer satisfaction, quality, etc. Enterprise models that describe the organisation's structure and behaviour are used in BPR in order to gain better understanding of the business ___________________________________________________________________________ P. Loucopoulos & E. Kavakli

IJICS

page 6

processes, and how they can be modified. The enterprise model offers a common format for the representation and reasoning about the business processes in their wider organisational perspective. It integrates information like what is going to be done, who is going to do it and why. In the area of Information Systems Engineering an early example can be found in [MacDonald 1986] . Typically, one considers the development of an information system in terms of four levels: planning, analysis, design and construction. The first two levels emphasise strategic planning, modelling of the enterprise, and business area analysis. During strategic planning, several business areas are identified, which are subsequently treated individually in the business area analysis phase. Entity types and their relationships, business functions and interactions between data and functions are represented using entity models, function hierarchy diagrams and process diagrams. More recently, repository technology has also advocated the use of enterprise modelling [Hazzah 1991; Mercurio, Meyers, et al 1990] in that an enterprise submodel supports a high-level definition of business processes and data and represents the definitions of the kinds of information necessary to describe a business and its business operations. 3.2

Enterprise Modelling for Co-operative and Distributed Information Systems

In modern co-operative or virtual enterprises there is an increasing desire for distributed information systems to co-ordinate the interaction of actors. Such systems may be geographically distributed and are usually integrated in networks. Furthermore, they are supposed to communicate and exchange data with other systems. While the technology for appropriate hardware and system software is available there is still no satisfactory method for developing distributed information systems. An examination of well established systems engineering methods such as Structured Analysis, SSADM, or Merise, reveals that all are targeted to the construction of centralised information systems [Aue and Breu 1994] . Neither of the above takes into account aspects like communication, locality of data and processes or causal dependencies among organisational actors. A similar observation is found in [Sommerville and Rodden 1994] concerning the field of CSCW (Computer Supported Co-operative Work), that deals with the implementation of systems for groups of users. According to Sommerville and Rodden, none of the widely used IS development methods explicitly allow for the inclusion of attributes like negotiation, interaction or co-operation nor do they reflect them in the system requirements. ___________________________________________________________________________ P. Loucopoulos & E. Kavakli

IJICS

page 7

To address the particular properties of distributed and co-operative Information Systems, enterprise models have been used, that map the conceptual description of the system requirements (services) to the organisation and physical structure of the enterprise. Several examples can be found in the literature. The BOS Engineering Method [Aue and Breu 1994] , uses several interrelated business models to describe the management and business rules in the application domain, and define the information system inside the context of the enterprise. The COMANDOS (Construction and Management of Distributed Open Systems) project [Friedemann 1992] , suggests a process-oriented organisational model to support the design and management of distributed systems. Finally, in the CSCW area, several less “formal” enterprise models have been proposed [Benford, Mariani, et al 1992; Sommerville and Rodden 1994] , in an attempt to address the nature of the organisation. The common link in all these models is that they try to embody social aspects of the enterprise like the way work is organised, how responsibilities are distributed, how human agents co-operate to fulfil their roles, etc., together with aspects from the objectives, service and operation domains.

3.3

Approaches to Enterprise Modelling

In recent years, various business models and methods have appeared in the literature, depending on the philosophy of how to view the world, i.e. the business and its place in the world, with a certain purpose [Nellborn, Bubenko, et al 1992] . Most approaches consider enterprise modelling in terms of one or more following viewpoints such as financial, technical and social. The M* methodology [Berio, Dileva, et al

1993] , aims to assist designers evaluate, plan and implement changes in a CIM system. For the M* meta-model, the real world is made of components that are handled by activities. Components describe things of interest for the organisation, like products, resources, and materials. Activities are performed by agents and can be triggered by events that correspond to a specific state changes of the object system. An agent carries out and controls the execution of activities, and can send/receive communication to/from other agents. Events can be generated by the organisation’s environment, by the communication between agents, by an activity, or because of a time condition. An event may trigger the execution of one or more activities. Yu [Yu 1994] proposes a conceptual modelling framework which attempts to provide a systematic way of organising and using knowledge from multiple organisational analysis perspectives. The framework is made up of three types of models. The first, called Actor Dependency (AD) model, represents an organisational configuration as a network of ___________________________________________________________________________ P. Loucopoulos & E. Kavakli

IJICS

page 8

interdependencies among actors. The second, called an Agents-Roles-Positions (ARP) model, models the make-up of social actors in terms of roles, positions and concrete agents. The third called an Issue Argumentation (IA) model, uses a network of arguments to express the concerns that actors have about the current and potential organisational configuration from various perspectives. The underlying mechanism for organising knowledge is common across these models, so that items in one model can be linked to items in the other type of model, without imposing the world-view of one on the other. A modelling example that focuses more on the social aspects of IT, is the ORDIT approach [Dobson, Blyth, et al 1994] . Its aim is to develop a methodology that will enable system designers to reason about organisational goals, policies and structures, and the work roles of intended end users in a way which will facilitate the identification and expression of organisational requirements for IT systems. The ORDIT approach provides an Enterprise Model that models responsibilities and relationships rather than activities. The three essential elements of the enterprise model are agency, activity and resource. An enterprise is described as a set of work roles. The concept of agency (embodied in agents), is intentional in the sense that it is not an object but a collection of responsibilities. ORDIT introduces the concept of agency in order to be able to differentiate between technical and social objects. A machine may perform the same tasks as a person, but a person will hold responsibilities for those tasks in contrast to a machine which cannot hold responsibility. Since an agency is considered a coherent set of responsibilities, it permits the discussion of issues related to the change in and re-allocation of responsibilities when some functions or agents in the system are proposed to be automated. For this reason the concept of agency is thought to be important in the ORDIT approach to the organisation as a socio-technical system. A different framework is proposed by F3 (From Fuzzy to Formal), in [Nellborn, Bubenko, et al 1992] . In this framework, the enterprise model aims to improve communication between users, requirements holders and IS developers in the analysis of the enterprise and to facilitate the IS requirements acquisition process. The framework consists of five, strongly interrelated, worlds (submodels). These are: The objectives world, the concept world, the actors world, the activities and usage world, and the information systems requirement world.

4.

Enterprise Modelling for Requirements Engineering

4.1

Modelling Viewpoints


IJICS

page 9

In order to deal with enterprise complexity we adopt a multiperspective approach. The task of reasoning about the enterprise is viewed as a co-operative activity which exploits the contribution of different views, each encompassing a specific type of knowledge and representation. When combined, these perspectives will produce an integrated, consistent and complete model of the enterprise analysed. Particular attention has been devoted to the investigation of the relationships among different views: the links between different concepts, the ways for ensuring that the set of available views consistently describe the enterprise. Within this multiperspective approach enterprise analysis is based on two mechanisms: reasoning within a perspective; and reasoning across different perspectives in order to allow each individual step in the analysis process to exploit the most appropriate knowledge source [Chittaro, Guida, et al 1993] . When using models to describe enterprises we need to be mindful of their limitations. A model highlights certain aspects of the real world, inevitably omitting others. It is unrealistic to try to capture every aspect of the enterprise in detail. This is made obvious when we consider that an enterprise is a social organisation whose functions can be determined by a wide network of social actors or stakeholders. Social actors can be rather unpredictable often leading to false a-priori assumptions. It is not possible to formalise concepts such as power, prestige etc. even if they do have an impact on the enterprise. In our approach, the enterprise model provides an image of the universe of discourse and an explanation on how it operates. Specifically, this view is motivated by one or more of the following considerations: technical, social and teleological. A technical perspective describes a number of different aspects of the business: business processes, flow of information and data across business processes, where resources or organisations are located, where activities take place, etc. It is often the case that technical solutions to problems do not adequately support the way in which the human components of the work system are organised. A social viewpoint reasons about policies, structures and work roles; validates and maintains their established order. In the case of a change in a business process, the enterprise model allows a measure of the impact this change could have, in terms of user satisfaction. As mentioned already, an important role of the enterprise model is to provide an explanation of the behaviour of the organisation it describes. In order to understand the behaviour of the enterprise, it is necessary to analyse organisational goals and goal dependencies. This teleological viewpoint of the enterprise model, aims to capture the reason behind the organisational activities and explain their assignment to the various organisational agents. ___________________________________________________________________________ P. Loucopoulos & E. Kavakli

IJICS

page 10

The background to these three views is based on our interpretation of the term “enterprise”. We view the enterprise as being composed of a number of members who possess varying types and degrees of competence and skill; varying values, personal goals and commitments; varying degrees of interpersonal contact, co-operation and influence. The specific combination of member competencies, commitments and influences which exists in the enterprise at any point in time determines the acceptable range of alternative actions. The members of the enterprise work toward the joint, enterprise objectives perhaps different but related to their personal objectives. The members have available to them, immediately or potentially, an aggregation of resources, (as represented by raw material or important information, facilities) for creating intermediate components or products, and activities capable of providing needed services. The magnitude and patterns of the resources in hand or potentially available to the organisation, at any time, determine the range of action alternatives which are realistically available to the enterprise at the time. The members operate the resources within an environment, which provides the enterprise's opportunities for service contributions and which makes certain demands upon the enterprise's performance. Here we are concerned with legal constraints, limits, incentives and assistance; labour constraints, demands, wage levels disposable income and interest rates and so on. 4.2

The Enterprise Metamodel

Different perspectives often require different conceptual models. However, even though different types of model are designed for different domains, there needs to be an underlying conceptual modelling mechanism to link items in one type of model to items in other type of model. A well accepted mechanism is the use of metamodels. When using metamodels, the enterprise concepts and their semantic links, will be defined at a meta-level which will act as a reference for all possible applications. Domain level models can be defined using the metamodel, its concepts being instances of the metamodel abstractions. There are five essential elements in our model: goals, roles, actors, processes and resources. Goals are recognised as the primary factors that govern/explain the current and potential enterprise configuration. Goals can generate behaviours, originate roles and determine activities. The notion of the actor includes both individuals and organisational units. Processes are the means by which the state of the system changes. Resources can either be of physical nature (material) or information. In a few words, the actor concept corresponds to ___________________________________________________________________________ P. Loucopoulos & E. Kavakli

IJICS

page 11

the who question, the role concept corresponds to the what question, the process concept corresponds the how question, and the goal concept corresponds to the why question. Several relationships exist among these basic elements. By exploring these relationships one can understand the reasoning behind the activities supported by an information system. For example: goals may generate, conflict or restrict other goals; actors are responsible for (play), certain roles and depend on other actors for the fulfilment of their obligations; activities compose of roles, and operate on and produce resources. By tracing the links among the concepts of this metamodel the IS designer can answer questions such as: “who is responsible for this activity?”, “why is this activity performed?”, “how do changes affect the enterprise?”, “in order for the goals to be achieved, what needs to be done, who is going to do it, what needs to be known?”.

4.2.1

The Teleological View

This viewpoint describes the goals of the various stakeholders. The notion of purpose is essential to every organisation. The organisation and its activities exist because there is some objective to be met. In the same sense the information system is created because there is some organisational goal to be met; the system’s functions and properties are defined by the organisation’s goals that the system intends to fulfil. The teleological view of the enterprise metamodel is illustrated in figure 1. Central to this view is the concept of goal. Goals denote intention and express the solution to some problem (problem-solving goals), or address some general vision or wish (wish-fulfilling goals), or satisfying some constraint (constraint-handling goal). Goals can vary in their degree of specificity. In general, the more desired values are mentioned, the more specific the goal is. For example the goal “To make profits of $1M in the next financial year” is more specific than the goal “To make profits in the next financial year”. Depending on their degree of specificity goals can be refined to simpler more precise goals.


IJICS

page 12

constraints affects

0:N

0:N

constrained_by 0:N

is_affected_by 0:N

CONSTRAINT

GOAL composes 0:N

is_decomposed_by 0:N

Figure 1: The Teleological View of the Enterprise Metamodel

To exemplify the notion of a goal consider the ATC description in the appendix. The enterprise in this case is responsible for the safety of aircrafts approaching the airport. To create an objective view of what the expectations of the new system are, the viewpoints of various stakeholders have to be taken into consideration. These stakeholders include the enterprise managers and staff, but also the enterprise users, that is, the aircraft operators, as well as its customers i.e. their crews and their passengers. The goals of these stakeholders may represent among others their economic, political, and safety concerns. The goals mainly presented by managers and customers are “Guarantee aircraft safety” and “Reduce aircraft delays”. The intentions of the potential system users (i.e. the air traffic controllers) can be summarised into the goal “Reduce demands placed upon air traffic controllers”. One can easily observe that these goals summarise the purpose for the development of the new ATC system. However, these goal statements are too vague to be interpreted into specific actions. There is a need to decompose these goals into a number of more specific goals. For example, to attain the goal “Reduce aircraft delays”, the following goals must be attained “Increase user productivity” and “Reduce aircraft separation”. This goal decomposition is expressed through the is_decomposed_by relationship. Goals can be decomposed in more than one way, introducing different alternative goals and therefore alternative approaches to their being satisfied. Choice among different alternatives


IJICS

page 13

can be justified through their associated cost. This cost can be estimated in different ways such as resources used, user satisfaction, etc. It should be noted that the aforementioned goals are not independent. For example the goal “Reduce aircraft delays”, implies the increase of user productivity and therefore has a negative impact on the user goal “Reduce demands placed upon airtraffic controllers”. Conflicts exist among goals due to the fact that different organisational agents, perceive the same problem in different ways. Goals can also be mutually supportive, that is they affect positively each other’s attainment. For example the goal “Create a user friendly system” supports the goal “Increase user productivity”. These influences among goals are expressed in the enterprise model through the affect relationship. It becomes obvious that there is a need to resolve conflicts among goals considering relevant goal priorities, or negotiating/bargaining with stakeholders. Sometimes the priority of some goal is absolute and cannot be traded off for some other goal. In our ATC example, the goal “Guarantee aircraft safety” is not negotiable and any automation strategy should support it. The ‘ambition’ of the goals prescribed by the stakeholders is enveloped by the existence of actual constraints placed upon the behaviour of the enterprise. For example the goal “Reduce aircraft separation” is constrained by the existence of separation standards that cannot be violated. Another example is the control flow regulations placed by the local authorities that set a maximum number of aircrafts allowed to cross the airport airspace per day, and constraint the goals of the enterprise. A constraint is an operational end to be met by the enterprise. As opposed to goals, a constraint is formulated in terms of measurable properties, and actions of the enterprise. A goal can be achieved provided the constraints imposed on it can be met. To meet these constraints appropriate restrictions may be required in turn on the actions and objects already defined. Constraints are set within the enterprise (enterprise rules), or from the enterprise environment. For example the separation standards are set within the enterprise taking into account the specific airport limitations, but the air-traffic flow regulations are set by the air traffic standards organisation. Goals should be expressed in a clear concise manner to avoid multiple interpretations of the same goal. It is important to clarify that goals denote intention and do not refer to the means that materialise these intentions. For example the statement “Visualise data” is a goal ___________________________________________________________________________ P. Loucopoulos & E. Kavakli

IJICS

page 14

but the statement “The automated system should have a screen” refers to the way the above goal can be achieved and is not a goal.

4.2.2

display

The Social View

The social viewpoint describes the organisational members and how they interact. Figure 2 shows the main concepts involved in this viewpoint. In more detail an actor is an organisational agent. Actors are the primary system manipulators since they are the ones who perform the activities. An actor can be either an individual agent or a group (organisational unit). The individual concept denotes both human individuals (persons), or machines, automated systems, etc. Organisational units refer to organisational structures like departments, divisions, sections, projects, teams, etc. Examples of organisational units are the Planning Department or the Data Base Team, the Telecommunications Group, etc. Individuals and organisational units are related through the is_part_of relationship (that is an individual belongs to an organisational unit).

INDIVIDUAL

is_part_of

1:N ORGANISATIONAL UNIT is_made_of

1:N

ACTOR is_responsible_for 1:N is_assigned_to 1:N

ROLE

is_dependent_upon 0:N

depends_on 0:N

DEPENDENCY

STRUCTURAL DEPENDENCY

FUNCTIONAL DEPENDENCY

Figure 2: The Social View of the Enterprise Metamodel


IJICS

page 15

A role is a coherent set of process elements to be assigned to an agent as a unit of responsibility. Roles are assigned to actors depending on their goals and capabilities. One actor might be acting several role instances simultaneously, or the actor that plays a particular role may change. They are independent of company organisation and may cross several department boundaries. This means that any future role re-allocation will have little effect on how the current information flow is defined. In a social world, roles normally rely on other roles for achieving some part of their goal and are in turn dependant upon others. For example the consumer role depends on the supplier role for the availability of stock. To that end, organisational configurations are viewed as networks of dependencies between different roles. In describing these dependencies between different roles one is interested in identifying the goals that a role attempts to achieve and its dependency on other roles in achieving this goal. We refer to the depending role as the depender, and the role who is depended upon the dependee. To deal with these dependencies the depends_on relationship is introduced. Related to this are issues such as resources and tasks required for meeting a specific goal; and structural issues, that is power dependencies according to the organisational structure of the enterprise. Therefore, we differentiate between two types of dependencies: •

functional dependencies, reveal the possible interactions among roles. In a functional dependency the depender depends on the dependee for the availability of some resource or the accomplishment of some task.

•

structural dependencies, reveal the power dependencies that exist in the organisation. In a structural dependency the depender is subservient to the dependee. In other words, structural dependencies reveal how control is established inside the organisation and how decisions fall on either side of the dependency.

In the ATC example we identify, among others, three actors: the controller the assistant controller and the automated system. Each actor is responsible for a different role. The controller is responsible for the manager role, the assistant controller plays the executive role, and the automated system is responsible for the data processor role. The three roles are interdependent. The executive depends on the data processor for the accomplishment of a task, e.g. display the data. Therefore, the dependency among them is a functional dependency. At the same time the executive is subservient to the manager who should ___________________________________________________________________________ P. Loucopoulos & E. Kavakli

IJICS

page 16

validate first any control instructions to the aircraft, and therefore the dependency among the two roles is structural. By being assigned to a role, an actor acquires the characteristics of that role. All the expectations on a role are also expectations on the actor responsible for that role. The dependencies of the role are induced into the actor. These interdependency chains reveal the possible interactions among the actors that play the roles, as well as their vulnerabilities. There is possibility of failure at each dependency, and it is important to be able to ascertain its implication. For example, if the data processor does not provide accurate data to the executive, that could adversely affect the executive's ability to efficiently control air traffic. The type of dependency reveals whose goals might be affected by a problem, and indicates which side will deal with the contingency. 4.2.3

The Process View

The process perspective includes the functional and behavioural viewpoints. It illustrates what process elements are being performed, and what flows of resource entities (e.g. data, artefacts, products) are relevant to these process elements. It also describes when processes are performed (triggering conditions). A graphical representation of the process view of the enterprise metamodel is shown in figure 3.

EVENT triggers 1:N

generated_by 0:N generates

triggered_by

0:N

1:N carried_out_in

PROCESS uses 0:N

MATERIAL

1:1 produces 0:N

LOCATION

produced_by

used_by

0:N

0:N

has 1:1

RESOURCE

of 1:N

of 1:N

decomposed_into 0:N

INFORMATION

composed_into 1:N


IJICS

page 17

Figure 3: The Process view of the Enterprise Metamodel

A Process is a set of related steps carried out towards a common desired result. At an appropriate level of abstraction, a process performs some identifiable task in the enterprise. Processes use or produce/modify resources. Resources can either be of physical nature (material), or information. Materials represent physical matters (e.g. raw materials, parts, products, components, etc.). Information represent information objects (e.g. data items, files of structured data items, forms of structured documents etc.). For example, in the ATC case, the “Radar Data Acquisition” process, uses the “radar” (material) and produces radar data (information). Resources can be seen to be made of other resources. In the previous example “radar data” is made of “primary radar data” and “secondary radar data”. Processes are triggered by events that correspond to specific state changes of the enterprise. Events express dynamic dependencies between processes and happen at a given moment in time. Events can be generated by a process, or because of a time condition (e.g. each week, at the end of the year, etc.). The concept of location indicates the distribution network of the enterprise, that is where specific processes are performed, and where the resources required to perform the process are located. It provides the “physical” description of the enterprise topology. Location becomes important especially for modern enterprises whose functions are distributed among several branches of the same enterprise, positioned in different places. In the ATC example we can identify among others the process “Flight Plan Acquisition” and “Data Processing”. The first is triggered by the aircraft request to enter the airspace, controlled by the enterprise. The “Flight Plan Acquisition” process uses the “Flight Plan System” to produce the appropriate “Flight Plan Data” of the approaching aircraft. These data are used by the “Data Processing” function, which processes the data to be provided to the controller. The same function generates an “Update Display” event, that in turn will trigger the execution of the “Display Data” process, that presents the processed data to the controller.

5.

Relating Enterprise Requirements to System Requirements: A Goal-Driven Approach

In the goal-driven approach information systems functions can be derived progressively from organisational objectives through a process that is called goals operationalisation. ___________________________________________________________________________ P. Loucopoulos & E. Kavakli

IJICS

page 18

Operationalisation is the process of refining goals so that the resulting subgoals have an operational definition [Anton, McCracken, et al 1994] . In this sense, a required system is considered as the realisation of a set of enterprise goals. The derived interrelated goal network will inevitably give rise to a variety of implementation alternatives. These alternatives should be evaluated according to measurement parameters associated with the goals in order to determine the degree to which a set of goals is supported by a particular operationalisation. This section discusses the goal-driven approach using the modelling viewpoints presented in section 4. The approach is demonstrated using the ATC case study. According to their degree of specificity enterprise goals can be organised into goal hierarchies. Vague objectives need to be refined into concrete, formal goals. The refinement of enterprise objectives into less abstract goals is necessary because only simple primitive goals can be operationalised. One disadvantage of goal decomposition is that the distinction between primitive goals and the means to achieve them is not always clear. Goals can also be grouped in different categories, depending on their context, owner, priority and so on. Several goal classifications have been proposed [Mylopoulos, Chung, et al 1992] , [Mittermeir, Rousopoulos, et al 1990] , [Dardenne, Lamsweerde, et al 1993] , [Yu and Mylopoulos 1994] . According to [diRoccaferrera 1973] , each objective forming the multiple goals set can be considered to belong to one of the following three general categories: enterprise objectives (reflecting general policy, strategy and tactics), problemsolving objectives, and innovative objectives. A pragmatic classification of goals [Anton, McCracken, et al 1994] differentiates between prescriptive and descriptive goals. A prescriptive goal is offered by the stakeholder to account for organisational structures and processes that should be observed. A descriptive goal, in contrast, emerges from analysis of actual processes. Another approach to goal analysis problem is that of goal reduction. The idea is borrowed from the problem-reduction method used in problem solving [Nilsson 1971] . As for the problems, so for the goals to be reached, they have to be ranked in order of importance and priority. As there are corresponding and related solutions to problems, so there are connected objectives. The theme to this approach is to reason backward from the objective to be met, establishing goals and subgoals until, finally the original objective is reduced to a set of trivial primitive goals. For any given objective more than one alternative set of subgoals can be produced. Some of the subgoals may not be satisfiable (unrealistic, too expensive etc.),


IJICS

page 19

thus requiring the testing of several alternatives in order to reach a set of subgoals that are all satisfiable. 5.1

From Enterprise Goals to IS Requirements - Summary of the method

We propose a conceptual framework for requirements specification that constitutes an interrelated set of domains, namely, the enterprise, functional and non functional requirements domains. The enterprise domain describes the enterprise’s goal structure, its existing activities, roles, actors, relations etc. The reasons for the need of the information system support, are found here and formalised in the FR and NFR domains. The informal user requirements are embodied in the teleological view of the enterprise model as the enterprise goals. These are elaborated into expressions of the system characteristics, i.e. the system functions and the constraints upon these functions. In order to achieve this, one has first to establish the boundaries of the intended system. Boundary establishment allocates roles to enterprise actors. It determines the 'margin' between the environment and the system, or in enterprise terms, the degree of automation proposed. This process includes the following steps: 1. 2. 3.

identify the goals to be assigned to the automated system, identify the roles required to achieve the system goals, identify the processes that realise these roles. Detail Enterprise Model enterprise goals Translate into I.S. Requirements Functional Requirements

Detail FR Model

Non-Functional Requirements

Detail NFR Model

Functions, data definitions


IJICS

page 20

Figure 4: The RE Conceptual Framework

Figure 4 shows in schematic form the major steps proposed within our approach. 5.2

The ATC Enterprise Model

In this section the proposed enterprise modelling methodology and its efficacy are tested in a real world problem, the development of an advanced system for an air traffic control centre (ATCC). A detailed description of the structure of the ATC centre and its processes, is given in the Appendix. 5.2.1

The Actor-Role Model (Social View)

The structure of the air traffic control centre (ATCC), is based on the principle that control decisions are taken by the controller who is personally responsible for traffic in a given area. The decision is then communicated by the controller (ATCO) to the pilot using radio. The human controller is assisted in his task by an automated system, the air-traffic control unit (ATCU), that performs routine tasks. Its main role is to provide data processing facilities to handle radar and flight plan data. The initial ATCC structure is illustrated in figure 5. In this configuration we can identify three roles. The data processor, the decision maker and the executive. The data processor role is assigned to the automated system, while the other two are assigned to the air traffic controller. The data processor role includes radar data processing and display of information. The decision maker role includes the planning and sequencing of approaching aircrafts, while the executive receives information from the decision maker, communicates with the pilot, and updates flight plans.


IJICS

page 21

Executive - Communicate with aircrafts - Update flight plans Individual

depends_on

ATC Controller Decision Maker - Sequencing - Planning

depends_on

depends_on Data Processor Individual ATC Unit

- Radar data processing - Flight plan processing - Data display

Figure 5: The Initial Social Configuration

5.2.2

The Process Model (Technical View)

The description of the air traffic control processes is illustrated in figure 6. This model provides a different viewpoint about the ATCC. It provides an insight into the processes that take place in the enterprise, the resources that are required by each process, and their triggering conditions. For example, the model shows that the process Flight Plan Processing, is triggered by some aircraft request to enter the controlled airspace, and it uses the Flight Plan System resource to produce Flight Plan Tables information. This information is in turn used by the Data Display process, and so on.


IJICS

page 22

Resource Update Display

Radar Process Radar Data Processing Resource

Meteo Plots &Tracks

Process Data Display

Process Scenario

Conflict Data

Meteo

Resource

Process

Flight Plan System

Flight Plan Processing

- Sequencing - Planning

Planning and timing

Flight Plan Tables

Aircraft Request

Process - Radio Communication - Update Data

Data from Controller

Figure 6: The Initial Process Configuration

5.2.3

The Goal Model (Teleological View)

Safety and efficiency are the original aims of air traffic control. The air traffic control framework also includes further considerations: e.g. reducing delays to aircraft or minimising fuel consumption. Other more personal wishes, such as avoiding controllers’ boredom, reducing his/her stress or trying to please pilots, may also be in mind on certain occasions. Together with these wishes, several problems and constraints are imposed on the ATC task which provide additional goals. For example airport terminal capacity, or particular aircraft characteristics should be taken into consideration, while the ATC centre should also be able to cope with emergency situations like immediate landing of some aircraft due to a passenger health condition, or demands made by a military aircraft. A summary of the above is illustrated in figure 7. Wishes pertain to these statements made by individuals with the aim to satisfy their own role aspiration. Problems address situations that need to be dealt with, or change. Finally, constraints express restrictions that are set upon the ATC tasks either from the ATC centre itself, or its environment.


IJICS

page 23

The ATCC objectives Minimise the risk of any accident befalling the aircrafts [airport management and passengers] Wishes

Reduce demands placed on controllers [ATCO] Improve air-traffic flow [airport management and passengers]

Problems

Deal with problems and emergencies Reduce delays The maximum number of aircrafts crossing the TMA at any time cannot be more that 15

Constraints

The vertical separation between aircrafts cannot be less that 2000 ft The horizontal separation between aircrafts cannot be less than 5 miles The maximum number of aircrafts / day allowed to cross the TMA is 100

Table 7: Wishes, Problems and Constraints Attributed to the ATC System

We refine these initial objectives to construct four interrelated goal hierarchies: ‘Minimise risk befalling aircrafts’, ‘Deal with problems and emergencies’, ‘Reduce delays’, and ‘Reduce demands set upon the air traffic controllers’ as shown

in figure 8. Considering that safety is the absolute objective of air traffic control, it is reasonable for the requirements engineer to allocate a greater degree of priority for the ‘Minimise risk befalling aircrafts’ objective than the ‘Reduce delays’ objective.


IJICS

page 24

Minimise risk befalling aircrafts

ATC goals

Maintain separation standards Decrease risk of human error Validate scenarios Automate control process

(A)

Automate sequencing and planning Automate aircraft sequencing Monitor continuously the situation inside the TMA

(B)

Visualise air traffic scenarios in real time Monitor continuously meteo conditions Monitor aircraft evolution Maintain accurate plans Order aircrafts in time and space

Deal with problems and emergencies Validate scenarios

Monitor continuously the situation inside the TMA same as (B) Reduce delays Handle quickly the sequence of aircrafts Automate controll process same as (A) Reduce aircraft separation Reduce demands set upon the air traffic controllers Automate controll process

goal decomposition alternative decomposition

same as (A)

Figure 8: The ATCC Goal Hierarchies

Figure 8 represents the four ATC goal hierarchies. The links show how the initial goals are decomposed in more specific sub-goals. The links shown in lighter shading denote alternative decompositions. For example the goal ‘automate control process’ can have two alternative decompositions: ‘automate sequencing and planning’ and ‘automate aircraft sequencing’. In the goal analysis presented in figure 8, we further analyse the alternative goal ‘automate aircraft sequencing’ into the five primitive goals: ‘visualise

air

traffic

scenarios

in

real

time’;

‘monitor

continuously

meteorological conditions’; ‘monitor aircraft evolution’; maintain accurate plans’; and ‘order aircrafts in time and space’.


IJICS

page 25

GOAL

Minimise risk befalling aircrafts

GOAL

GOAL

GOAL

Reduce demands placed upon ATC controllers

Decrease risk of human error

Deal with problems and emergencies

GOAL

GOAL

Automate control process

Validate scenarios conflicts

GOAL

GOAL

Automate sequencing and planning

Automate aircraft sequencing

GOAL

1st automation strategy

Visualise air traffic scenarios in real time

2nd automation strategy

Figure 9: A Portion of the ATC Goal Structure

We use the goal hierarchies to construct the goal graph, a portion of which is depicted in figure 9. In this goal graph, goal decompositions are presented as AND nodes while alternative decompositions are presented as OR nodes. This graph also illustrates the conflicts that exist among goals. For example the 'automate sequencing and planning' goal conflicts with the 'deal with problems and emergencies goal'. The contribution of carrying out this type of goal analysis is highlighted in the following section which shows how different scenarios can be constructed and evaluated. 5.2.4

Scenario Analysis

Because there are many possible decompositions of a single goal the analyst has to compare several alternatives rather that choose one immediately. A ‘scenario’ is a behavioural sequence exhibited by one of the proposed automation strategies. Like a story, a scenario also explains the context and consequences of these behaviours. Scenarios can apply to ___________________________________________________________________________ P. Loucopoulos & E. Kavakli

IJICS

page 26

operationalisation of goals and help elicitate the exact operationalisation of the goal hierarchy. In the ATC example, the need for advanced computer support is largely prompted by the pressure of traffic loading. The demands placed on the air-traffic controller constantly increase, and the current ATC system cannot cope with more traffic. Automated assistance to controllers may introduce new control strategies to be established which will allow more flights without compromising safety. The question arises as to what extent the human operator can be taken out of the control process. In other words should conflict resolution and economic routing be completely automated? According to the goal structure depicted in figure 9, we can consider two automation strategies. In the first strategy the control process will be completely automated. This will involve the automation of the sequencing and planning activities. The ATCU will play the role of decision maker, while the ATCO will play the role of the supervisor with a veto. Given a request of an aircraft to enter the TMA, the ATCU will automatically detect conflicts and divergences and order the aircraft in time and space in the most efficient way (considering time delays and fuel consumption). The controller will just verify the proposed plan and notify the pilot about his route in the TMA. Alternatively, a system could be proposed that manages only the aircraft sequencing, without playing the decision making role. In this case, the controller is expected to: select the economic (and safe) order of the requesting aircraft among the alternative sequences offered by the ATCU; communicate with the aircraft pilot; and update the flight plans. The argument for the first automation strategy is that complete automation of the control process would minimise the risks of human error. The problem is that aircraft operators have different preferred flight tracks and different optimal flight profiles; and aircrafts have different operational characteristics. Furthermore, abnormal situations and emergencies cannot be controlled by the standard procedures. For example, consider the scenario of an emergency aircraft landing due to some mechanical failure. This aircraft should get priority in the sequencing order, compromising the economic routing factor. In a worse case there might be no available track in the TMA so the controller should have to alter the routes of other aircrafts already in his TMA. Therefore the ATCO is not just a supervisor of the control process because in cases of emergencies he will be the one responsible to provide solutions that may not be included in the alternatives provided by the automated system.


IJICS

page 27

Executive - Communicate with aircrafts - Update flight plans Individual

depends_on

ATC Controller Decision Maker - Planning

depends_on

depends_on Data Processor - Radar data processing - Flight plan processing - Data display Individual ATC Unit

depends_on depends_on Sequencer - Sequencing

Figure 10: The ATCC Configuration after the Introduction of the New ATCU

Consequently, we choose the partial automation alternative since the full automation alternative does not satisfy the ‘Deal with problems and emergencies’ objective. According to this strategy the ATCO plays the roles of decision-maker and executive, while the automated system plays the role of the data processor, and sequencer, providing the controller with the processed data needed to govern his sector of airspace. The social and process configuration of the ATCC after the introduction of the new ATCU, according to the second automation strategy, is illustrated in figures 10 and 11, respectively.


IJICS

page 28

Resource

Conflict Data

Radar Process Radar Data Processing

Update Display Process

Meteo Plots &Tracks

- Sequencing

Planning and timing

Process Data Display

Resource Meteo

Scenario

Resource

Process

Flight Plan System

Flight Plan Processing

Flight Plan Tables

Process - Planning - Radio Communication - Update Data

Aircraft Request

Data from Controller

Figure 11 : The ATCC Processes after the Introduction of the New ATCU

In the new configuration the demands upon the controller are indeed reduced, and so is the risk of human errors, since the sequencing role is now transferred to the automated system. Having decided on the automation strategy, the next step would be to identify the ATCU requirements.

5.3

From Enterprise Requirements to IS Requirements

The main objective is shown as the “need to guarantee a high degree of safety”. In order for this to be met there is a need to meet another goal “decrease risk of human error” which can be achieved by providing automated control facilities in terms of “visualisation of air traffic scenarios in real time”. It is this enterprise requirement which is directly related to defining specific functional and non functional requirements for a number of system components, one of which will be considered for the purpose of this example namely, the display system. This enterprise requirement can also act as the ‘link’ between the system itself and the role of the system in the wider context of the enterprise and in particular its participation in meeting the overall objective of “providing a high degree of safety”. With respect to functional requirements the following observations can be made. First, the goal “visualise air traffic scenarios in real time” shown in figure 9, will motivate an information system goal which in turn will drive the process of deriving functional requirements. Second, for each functional requirement a description of the system function in terms of at least its input, output processing and data will need to be defined. ___________________________________________________________________________ P. Loucopoulos & E. Kavakli

IJICS

page 29

The relationship between enterprise goal, information system goal and system functional requirements is shown in figure 12. Note that the example is limited to only the “display scenarios” requirement. The model shown in figure 12 relates the IS-Goal “the system should display scenarios” with a set of functions, shown in the diagram by the boxes labelled “IS-FR” that need to be incorporated by the intended system in order for the system to meet this goal. This model shows no details about the data required by the system or the details of the functions themselves in terms of input, output and processing. These aspects are modelled separately, an example of which is shown in figures 13. IS-FR

GOAL


motivates

The system should display scenarios motivates

IS-FR

Display tracks

IS-FR

IS-FR

Display maps and airways

Display alerts and conflicts

IS-FR

IS-FR

Display tables

Display plots

motivates motivates

motivates

IS-FR IS-FR

Display position and speed

IS-FR

Display track history

Display correlated flight plan and supplementary info

IS-FR

IS-FR

IS-FR

Display altitude tendency

Display primary data detections

Display meteo data ftom radar

IS-FR IS-FR

IS-FR

Display correlated flight plans

Display uncorrelated flight plans

Display flight plans corresponding to lost tracks

IS-FR

Display ambiguous flight plans

Figure 12: Relationship between Enterprise Goals and FRs

Figure 13 shows the main entity types and their relationships for this application. This entityrelationship model shows that the displayed information is made up of different types of entities such as alerts (which themselves can be one of software failure, hardware failure or other radar alerts), maps and airways, radar signals, tables and tracks (note that there are different types of radar signals, tables and tracks).


IJICS

page 30

Primary plots

Ambiguous Correlated Uncorrel. Plans corresp. flight plans fligh plans flight plans to lost tracks

Meteo data

Flight plan

Position and speed

Secondary plots

Track history Altitude tendency Flight plan Tables tables

Radar signal

Tracks

makes

made_up_of

Alert

Radar alert

Hardware fault

made_up_of

makes

made_up_of

Displayed message

makes

made_up_of

made_up_of

makes

Maps and airways

Software fault

Figure 13: A Data Model for the Display Function

However, not all enterprise requirements are translated as functional IS requirements. Furthermore, the same enterprise goal can give rise to both functional and non-functional IS requirements. In our example the enterprise requires that the system should "visualise air traffic scenarios in real time", which motivates also the system requirement that it should perform in real time. This leads to a number of non-functional requirements that are primarily concerned with performance and capacity. For example, the non-functional requirement “radar data should be displayed in real time” motivates the more detailed non-functional requirement “aircraft position should be displayed in less that 3/16 sec of the radar sweep period”. Further analysis of non-functional requirements results in successively more specific statements represented as the leaves of the tree diagram shown in figure 14. This diagram is analogous to that shown in figure 12, between enterprise goals and functional requirements goals. The view shown in figure 14 has therefore two objectives: to relate non-functional requirements to the objectives of the enterprise and to successively examine these requirements until a measurable statement has been defined. As in the case of functional requirements it is possible to trace non-functional requirements back to originally stated, vague expressions in the enterprise domain. Again, all the non-functional requirements stated in figure 14 refer to one of the components of the target system, the display unit.


IJICS

page 31

IS-NFR

GOAL


motivates

The system should perform in real-time motivates

IS-NFR

IS-NFR

Display radar data in real-time

The display must accommodate all necessary data for the scenario

motivates

motivates

IS-NFR

Aircraft position should be displayed in less than 3/16 sec of the radar sweep period

IS-NFR

IS-NFR

IS-NFR

IS-NFR

Display 100 tracks

Display 100 meteo plots

Display 200 vectors

Display 500 table symbols

Figure 14: Relationship between Enterprise Goals and NFRs

6.

Conclusions

The continuing evolution of Information Technology has now reached a threshold of cost and ease of use that is having widespread organisational impact. Information Technology in general, and Information Systems in particular, exert such a strong influence because they can affect both production and co-ordination. Traditionally information systems dealt with issues relating to cost reduction, productivity increment and quality enhancement of the services offered by the enterprise. These issues bring changes in the work roles and skill levels. Work roles may be enriched or extra burdens may be imposed. Information systems are entering a new phase moving beyond the traditional automation of routine organisational processes and towards the assisting of critical tactical and strategic enterprise processes. Development of such systems needs to concentrate on organisational aspects, delivering systems that are closer to the culture of organisations and wishes of individuals. Specifying requirements in this context directly address issues such as: Improving change management by explicitly identifying and specifying those aspects of enterprises that are liable to change and by developing information systems that go beyond the automation of existing processes. Providing integration of views within an enterprise by adopting an approach which encourages a co-operative generation and assessment of requirements. ___________________________________________________________________________ P. Loucopoulos & E. Kavakli

IJICS

page 32

Relating information systems to business strategy by facilitating the modelling of business goals and their realisation in information systems structure.

Business success is today critically dependent on the ability of the enterprises to link their information systems - their development and use - more closely to the business development process and such a success can only be achieved if infrastructure systems truly meet the needs and expectations as articulated within an organisational framework. In order for organisations to meet the challenges and opportunities presented by information systems in the automation, decision-making and in particular in the transformation stages the following are regarded as a general set of prerequisites [Morton 1991] : •

Clear definition of business purpose and vision of what the organisation should become. This vision should be visible and understood by the organisation itself.

•

Alignment of corporate strategy and information systems development.

In other words, the development of information systems is not simply about designing software components but also about understanding the needs of individuals and other stakeholders within the enterprise and ensuring that the system meets user requirements and business strategy. By examining the objectives of the organisation, a rationale is established not only about the organisation itself but also about the infrastructure that supports or will support in the future the enterprise and the way that the system will fit the organisation and used by different end-user communities [Bubenko and Wangler 1993] . Crucially therefore, requirements engineering is about establishing the ‘connection’ between the need for some change within an organisational framework and the technology that could bring about such a change. In other words, requirements engineering can be considered as a way of managing change. This involves: •

an understanding at a conceptual level of the current status

•

a definition of the change in terms of the transition from the ‘old’ conceptual situation to a ‘new’ target conceptual situation


IJICS

page 33

•

the implementation of the change in terms of the new components of the system and

•

the integration of this new implementation in the environment which contained some legacy system.

The approach proposed in this paper seeks to provide mechanisms for progressing from fuzzy, ill-defined expressions for information systems support to a more formal, validated specification whose contents can be analysed in terms of different areas of concern to requirements stakeholders. We take the view that requirements need to be articulated within the framework of ‘real-world’ knowledge which would provide the purpose of the intended system as well as the knowledge about the phenomena common to the enterprise and system domains. We regard the process of specifying requirements as a set of model-building activities. It is our contention that a critical part of these activities is that which deals with expressing enterprise views in terms of the technical, social and teleological dimensions and their relationship to information system goals.

Acknowledgements The work presented in this paper has benefited from our involvement in the F3 (From Fuzzy to Formal) project. We are particularly indebted to Janis Bubenko and Christer Nellborn for many fruitful discussions on the topic of enterprise modelling.

References Anton, A.I., McCracken, W.M. and Potts, C. (1994) Goal Decomposition and Scenario Analysis in Business Process Reengineering, 6th International Conference on Advanced Information Systems Engineering (CAiSE•94), G. Wijers, S. Brinkkemper and T. Wasserman (ed.), Springer-Verlag, Utrecht, The Netherlands, 1994, pp. 94-104. Aue, A. and Breu, M. (1994) Distributed Information Systems: An Advanced Methodology, IEEE Transactions on Software Engineering, Vol. 20, No. 8, 1994, pp. 594-605. Benford, S., Mariani, J., Navaro, L., Prinz, W. and Rodden, T. (1992) MOCCA An Environment for CSCW Applications, Centre for Research in CSCW, Lancaster University, CSCW/14/92, 1992. Berio, G., Dileva, A., Giolito, P. and Vernadat, F. (1993) Organisation Analysis Concepts and Models for CIM Design, , 1993. Bubenko, J., Rolland, C., Loucopoulos, P. and de Antonellis, V. (1994) Facilitating “Fuzzy to Formal” Requirements Modelling, IEEE International Conference on Requirements Engineering, 1994. Bubenko, J.A. (1994) Experiences from Testing Enterprise Modelling- A Requirements Acquisition Method, , 1994.


IJICS

page 34

Bubenko, J.A. and Wangler, B. (1993) Objectives Driven Capture of Business Rules and Information Systems Requirements, IEEE Conference on Systems, Man and Cybernetics, 1993. CAA (1983) CIVIL AVIATION AUTHORITY, A report on the supplying by the Authority of navigation and air traffic control services to civil aircraft, Her Majesty’s Stationery Office, London, 1983. Chittaro, L., Guida, G., Carlo, T. and Toppano, E. (1993) Functional and Teleological Knowledge in the Multimodeling Approach for Reasoning About Physical Systems: A Case Study in Diagnosis, IEEE TRANSACTION ON SYSTEMS, MAN, AND CYBERNETICS, Vol. 23, No. 6, 1993, pp. 1718-1749. Curtis, B., Kellner, M.I. and Over, J. (1992) Process Modelling, Communications of the ACM, Vol. 35, No. 9, 1992, pp. 75-90. Curtis, B., Krasner, H. and Iscoe, N. (1988) A Field Study of the Software Design Process for Large Systems, CACM, Vol. 31, No. 11, 1988, pp. 1268 ff. Dardenne, A., Lamsweerde, v. and Fickas, S. (1993) Goal-directed Requirements Acquisition, Science of Computer Programming, Vol. 20, 1993, pp. 3-50. diRoccaferrera, G.M.F. (1973) Behavioral Aspects of Decision Making Under Multiple Goals, in ‘Multiple Criteria Decision Making’, J. L. Cochrane and M. Zeleny (ed.), , pp. 635-656. Dobson, J. (1992) A Methodology for Managing Organisational Requirements, University of Newcastle upon Tyne, Newcastle NE1 7RU, UK., 1992. Dobson, J.S., Blyth, A.J.C., Chudge, J. and Strens, R. (1994) The ORDIT Approach to Organisational Requirements, in ‘Requirements Engineering: Social and Technical Issues’, M. Jirotka and J. A. Goguen (ed.), Academic Press, London, pp. 87-106. DOD-STD-2167A (1988) Defense System Software Development, Department of Defence, February, 29, 1988, 1988. Friedemann, R. (1992) Organisational Integration System Design Process, CAiSE’92, P. Loucopoulos (ed.), Springer-Verlag, Manchester, UK, 1992, pp. 410-424. Goranson, H.T. (1992) Dimensions of Enterprise Integration, Proceedings of the 1st International Conference on ‘Enterprise Integration Modeling’, C. J. Petrie (ed.), MIT Press, 1992, pp. 101-113. Graefe, U. and Chan, A.W. (1993) An Enterprise Model as a Design Tool for Information Infrastructure, in ‘Infromation Infrastructure Systems for Manufacturing (B-14)’, H. Yoshikawa and J. Goossenaerts (ed.), Elsevier Science B.V., North Holland, pp. 183-192. Greenspan, S., Mylopoulos, J. and Borgida, A. (1994) On Formal Requirements Modeling Languages: RML Revisited, 16th International Conference on Software Engineering (ICSE-94), IEEE Computer Society Press, 1994, pp. 135-148. Hazzah, A. (1991) DRC and DRM: The Repository Meets the Database, Database Programming & Design, No. August, 1991, pp. 29-39. Hein, K.P. (1990) DevelopMate: A new paradigm for information system enabling, IBM Systems Journal, Vol. 29, No. 2, 1990, pp. 250-264. IEEE-Std.’830’ (1984) IEEE Guide to Software Requirements Specifications, The Institute of Electrical and Electronics Engineers, New York, ANSI/IEEE Std 830-1984, 1984. Jackson, M. (1994) The Role of Software Architecture in Requirements Engineering - Position Statement, The 1st International Conference on Requirements Engineering, IEEE Computer Society Press, Colorado Springs, Colorado, 1994, pp. 241.


IJICS

page 35

Kosanke, K. and Vlietstra, J. (1989) CIM-OSA - Its Goals, Scope, Contents and Achievements, ESPRIT ‘89, Brussels, 1989, pp. 661-673. Loucopoulos, P. (1991) The TEMPORA Method: Enterprise Modelling and Information System Design, UMIST, E2469/UMIST/T5.1/9, 1991. Loucopoulos, P. and Katsouli, E. (1992) Modelling Business Rules in an Office Environment, ACM SIGOIS, No. August, 1992. Loucopoulos, P., McBrien, P., Schumacker, F., Theodoulidis, B., Kopanas, V. and Wangler, B. (1991) Integrating Database Technology, Rule-Based Systems and Temporal Reasonig for Effective Information Systems: the TEMPORA Paradigm, Journal of Information Systems, Vol. 1, No. 2, 1991, pp. 129-152. Lubars, M., Potts, C. and Richter, C. (1993) A Review of the State of the Practice in Requirements Modelling, IEEE International Symposium on Requirements Engineering, IEEE Computer Society Press, San Diego, California, 1993, pp. 2-14. MacDonald, I.G. (1986) Information Engineering, in ‘Information System Design Methodologies : Improving the Practice’, T. W. Olle Sol, H.G., Verrijn-Stuart, A.A. (ed.), Elsevier Science Publishers B.V (North Holland), Amsterdam. McDermid, J.A. (1994) Requirements Analysis: Orthodoxy, Fundamentalism and Heresy, in ‘Requirements Engineering: Social and Technical Issues’, M. Jirotka and J. A. Goguen (ed.), Academic Press, London, pp. 17-40. Mercurio, V., Meyers, B.F., Nisbet, A.M. and Radin, G. (1990) AD/Cycle Strategy and Architecture, IBM Systems Journal, Vol. 29, No. 2, 1990. Mittermeir, R.T., Rousopoulos, N., Yeh, R.T. and Ng, P.A. (1990) An Integrated Approach to Requirements Analysis, in ‘Modern Software Engineering: Foundations and Current Perspectives’, P. Ng and R. T. Yeh (ed.), Van Nostrand Reinhold, New York, pp. 450-461. Morton, M.S. (1991) The Corporation of the 1990s: Information Organisational Transformation, Oxford University Press, Oxford, 1991.

Technology

and

Mylopoulos, J., Chung, L. and Nixon, B. (1992) Representing and Using Nonfunctional Requirements : A Process-Oriented Approach, IEEE Transactions on Software Engineering, Vol. SE-18, No. 6, 1992, pp. 483497. NCC (1987) The STARTS Guide. A guide to methods and software tools for the construction of large real-time systems, National Computing Centre Ltd, Manchester, UK, 1987. Nellborn, C., Bubenko, J. and Gustafsson, M. (1992) Enterprise Modelling - the Key to Capturing Requirements for Information Systems, SISU, F3 Project Internal Report, 1992. Nilsson, N.J. (1971) Problem-Solving Methods in Artificial Intelligence, McGraw-Hill, 1971. Petrie, C.J. (1992) (ed.) Proceedings of the 1st Conference on ‘Enterprise Integration Modeling’, Scientific and Engineering Computation Series, MIT Press, Cambridge, Massachusetts & London, UK. Pohl, K. (1993) The Three Dimensions of Requirements Engineering, 5th International Conference on Advanced Information Systems Engineering (CAiSE•93), C. Rolland, F. Bodart and C. Cauvet (ed.), SpringerVerlag, Paris, France, 1993, pp. 275-292. Rzepka, W. and Ohno, Y. (1985) Requirements Engineering Environments: Software Tools for Modelling User Needs, IEEE Computer, No. April, 1985, 1985. Scheer, A.-W. and Hars, A. (1992) Extending Data Modelling to Cover the Whole Enterprise, Communications of the ACM, Vol. 35, No. 9, 1992, pp. 166-175.


IJICS

page 36

Sommerville, I., Bentley, R., Rodden, T. and Sawyer, P. (1994) Cooperative Systems Design, The Computer Journal, Vol. 37, No. 5, 1994, pp. 357-366. Sommerville, I. and Rodden, T. (1994) Requirements Engineering for Cooperative Systems, Centre for Research in CSCW, Lancaster University, CSCW/1/1994, 1994. Yu, E. and Mylopoulos, J. (1994) Understanding ‘Why” in Software Process Modeling, Analysis and Design, 16th International Conference on Software Engineering, Sorrento, Italy, 1994, pp. 159-168. Yu, E.S.K. (1993) Modelling Organizations for Information Systems Requirements Engineering, IEEE International Symposium on Requirements Engineering, IEEE Computer Society Press, San Diego, California, 1993, pp. 34-41. Yu, E.S.K. (1994) An Organisational Modelling Framework for Multi-Perspective Information System Design, , 1994, pp. 66-85.


IJICS

page 37

Appendix - The Air Traffic Control Centre Air Traffic Control (ATC) is the service provided for the purpose of preventing collisions, (between aircraft in the air, and on the ground, or between aircraft and obstructions), and expediting and maintaining an orderly flow of air traffic [CAA 1983] . Safety, expedition and economic efficiency are the prerequisites to successful operation of commercial air transport. To achieve these aims necessitates controls on the use of airspace. As the number of aircraft increases the greater is the pressure on the capacity of the operating environment to accommodate them with optimum safety, expedition and efficiency - and therefore the greater the need for such controls. The need for effective computer support is largely prompted by the pressure of traffic loading. The demands placed on air-traffic controllers constantly increase, and the current ATC system cannot cope with more traffic. This leads to the introduction of inefficient flow control restrictions. It is largely flow control restrictions which are responsible for delays being increasingly experienced. Automated assistance to controllers might allow new control strategies to be established which would allow more flights without compromising safety. For example, a real-time warning system such as a 'conflict alert' system, would allow a tighter aircraft packing into the available airspace. ATC is an evolved, highly skilled occupation in which the methods of working have maintained substantially unchanged since the 60's. It has an occupational culture which has demonstrated its reluctance to embrace technological solutions which fail to improve the work and maintain standards of safety as controllers interpret them [Sommerville, Bentley, et al 1994] . The automated control system would need, at least, to capture all current functionalities (or provide alternatives) in order not to impoverish or problematise the accomplishments of controlling. Its objective is to facilitate the controller’s tasks and support him in the decisions, increasing his operational capabilities. It is important that the automated resources will not overload the controller creating new tasks that could introduce new burdens to his job. Within the air traffic control framework are included other considerations: i.e. reducing delays to aircraft, minimising fuel consumption and minimising noise to people on the ground. Other more personal desires, such as avoiding controllers' boredom, reducing stress or trying to please pilots, may also be in mind on certain occasions. In addition to conflicts of interest, these considerations might be mutually exclusive, particularly if the 'minimising' is taken literally. ___________________________________________________________________________ P. Loucopoulos & E. Kavakli

IJICS

page 38

Airspace and Air Traffic The airspace is divided into flight information regions (FIR). Each FIR is divided into controlled and uncontrolled airspace. Controlled airspace must be established in certain areas because of the density of traffic wishing to use them. Every aircraft in controlled airspace is continuously subject to ATC, and remains in radio contact with an air traffic controller (ATCO). Controlled airspace consists of control zones and control areas. The control zones stretch from ground level to a specified height, and are established as protection around one or more airports. Linking the airports of the world, each surrounded by its own control zone are airways in the form of corridors. These ‘aerial motor ways’ are ten nautical miles wide and mostly about 20,000 feet high, extending upwards from different heights above the ground. Where the airways come together over major airports or groups of airports a terminal control area (TMA) can be established. This is a block of airspace designed to 'cover the joins' and provide a link between the airways and the control zone. Each TMA has its own Area Control Centre (ATCC), where the approach control is carried out. Approach control is responsible for an arriving aircraft from the point at which en route control is handed over, typically at radio beacons some 10 to 25 miles from the airport. Approach control is also responsible for organising stacks (approaching aircrafts are required to circle in a holding ‘stack’ over a radio beacon when landing is delayed due to density of traffic or bad weather). When the aircraft has been lined up to land on the runway, control passes to aerodrome control, whose responsibility covers landing, movement on the ground and take-off. The final approach to the airport is usually the most critical phase of flight, as an aircraft has to be brought to the ground in all weathers at a precise point on the runway. The margin for error is extremely limited and most major airports are equipped with an instrument landing system. For the purposes of this case study we concentrate on the domain of a TMA and its AirTraffic Control Centre, responsible for airport approach control. To respond to traffic demands the ATCC has at its disposal a number of properties which include: (a)

surveillance radars: to monitor the height and position of aircraft,

(b)

data processing facilities: to handle radar and flight plan data,

(c)

skilled manpower: trained in projecting aircraft trajectories and formulating track, deviations which separate aircraft with minimum disturbance, and


IJICS

page 39

(d)

a defined, regulated airspace, i.e. the Terminal Control Area, (TMA).

The air traffic control task is composed of the following general processes: radar data processing; flight data processing; scenario display; and air traffic handling. Radar Data Processing (RDP) In air traffic control the radar picture provides a controller on the ground a ‘space vehicle’s view’ of a piece of airspace. A primary radar beam reflected off an aircraft produces a ‘blip’ on a radar screen. Secondary radar interrogates an aircraft fitted with a transponder2; the latter's coded response, after computer processing, displays on an ATCO’s radar screen the aircraft's identification, height and destination. All radar data available to an ATC system must be processed before use by the ATCO. The primary and secondary data are combined, together with other information received by the Meteorological services, that concern the weather conditions that affect the aircraft or the different barometric pressure datums used to calculate the height and altitude of the aircraft. The radar/meteo information is important for two main reasons: firstly, so that the pilot can be sure of clearing the terrain lying below the aircraft and along its intended path, and secondly, so that vertical separation of aircraft can be effected accurately. Flight Plan Processing (FPP) Before each flight in controlled airspace the pilot submits a flight plan which includes the aircraft's call sign and type, estimated time of departure, desired altitude, route and destination. Amended as necessary so as to avoid conflict with other planned flights, its acceptance by the ATC system is the pilot's permission to fly in controlled airspace in accordance with the plan. For regular flights the plan may have been filed weeks or months in advance and the information stored in a storage unit, (possibly a flight plan data base). In controlled airspace, therefore, the airways system has the great advantage, both for the pilot and for the ATCO of every sector through which his aircraft passes, that a flight is preplanned and, once approved, is generally unimpeded although under constant surveillance. If

2A

transmitter/receiver fitted to an aircraft to enable it to transmit data in response to interogation by secondary

radar.


IJICS

page 40

ATC instructions result in a change in speed, track or flight level then changes should be input and the flight plan again updated. Scenario Display Information from the flight plan is distributed(displayed) as a flight progress strip3 to every ATCO concerned with the aircraft during that flight, who will use the strip to monitor the aircraft's progress through his sector, noting on it any instructions he has given the pilot. Together with the flight progress strips the controller task requires additional information about airport and runway configurations (i.e. maps of the region around the airport and of the existing airways); general information about the weather conditions; and tracks of the aircrafts currently flying in his sector. All this information will give a 3-D image about the current situation and will help the controller appreciate the current situation and order aircrafts in time and space. Air Traffic Handling Aircraft request entry to the ATC track system about 40 minutes before estimated entry time, whilst in flight. They will ask the ATCC for their preferred track at a preferred flight level at a given time. Possible conflicts are checked with other aircraft already cleared; if this check is satisfactory, the request is accepted; if not, an alternative will be offered, until an agreement is reached. The appropriate selection of track and flight level is very important to the pilot as these form the main determinant of fuel used. An overall view of the operation of the ATC system is shown in the following Data Flow Diagram.

3Progress

strips are traditionally printed and distributed manually, but this is superseded by electronic display

of the flight strip data in the form of flight tables.


IJICS

page 41

Tracks initiated

Choose initiated tracks

Primary and secondary plots for display

TRACKS Display tracks

Radar tracks

Display plots and meteo

Meteo data for display

Tracks cancelled Flight plans coresponding to lost tracks

Altitude tendency

Display Unit

Ambiguous flight plans

Position and speed

Correlated fligh plans

Display tables

FDP system

Uncorrelated flan plans

Maps, airways and meteo data for display

Alerts and conflicts for display

Display Maps,airways and meteo data

Display Alerts

Correlate flight plans and tracks

Construct tables

SYSTEM CONF. DATA

Maps, airways and meteo data

Construct maps, airways and meteo data

Radar data acquisiton

Invariant data

Meteo System Monitor System

Variant data

Meteo data Meteo data

Radars

Meteo data acquisition

Radar tracks

Figure 15: A Data Flow Diagram of the ATCU Operation

Due to air traffic control, the pilot is guaranteed a standard separation distance4 from all other aircraft, with the knowledge that threats of conflicting traffic or the intrusion of other aircraft into the system, probably unsuspected by him, will prompt immediate preventive action by the ATCO.

4An

aircraft in controlled airspace is separated from another by prescribed horizontal and vertical distances.

Vertical separation is at least 1,000 ft up to FL290 (=29,000 ft) and at least 2,000 ft above that height. Horizontal separation varies according to the circumstances but there is a minimum of 5 miles when radar is being used.


IJICS

page 42

Enterprise Modelling and the Teleological Approach - Semantic Scholar

Enterprise Modelling and the Teleological Approach - Semantic Scholar

Suggest Documents

Enterprise Modelling and the Teleological Approach - CiteSeerX

Enterprise modelling - Semantic Scholar

Enterprise Modelling and the UML - Semantic Scholar

enterprise knowledge modelling: domains and ... - Semantic Scholar

Modelling business processes and enterprise ... - Semantic Scholar

MoKi: The Enterprise Modelling Wiki - Semantic Scholar

On Ontologies And Enterprise Modelling - Semantic Scholar

The Unified Enterprise Modelling Language - Semantic Scholar

Collaborative enterprise integrated modelling - Semantic Scholar

User oriented Enterprise Modelling for ... - Semantic Scholar

Enterprise Data Modelling: Developing an ... - Semantic Scholar

From enterprise modelling to enterprise visual ... - Semantic Scholar

Geomorphologic approach for modelling the ... - Semantic Scholar

A Methodological Approach for Enterprise ... - Semantic Scholar

An Approach for Enterprise Interoperability ... - Semantic Scholar

Semantic Enrichment of Enterprise Modelling

Quality Criteria for Enterprise Modelling in the ... - Semantic Scholar

Integrated Approach for Modelling of Semantic and ... - Semantic Scholar

A Meta-Modelling Approach to Feature Modelling - Semantic Scholar

towards the enterprise engineering approach for ... - Semantic Scholar

A Methodological Approach for Enterprise Modelling of Small and ...

Process Modelling for Enterprise Systems: Factors ... - Semantic Scholar

On the Grey-Box Modelling Approach for ... - Semantic Scholar

3D vs. 4D ontologies in Enterprise modelling - Semantic Scholar