"Worlds" in Requirements Acquisition and Modelling - CiteSeerX

"Worlds" in Requirements Acquisition and Modelling Janis A. BUBENKO jr* and Marite KIRIKOVA** Department of computer and System Science Royal Institute of Technology and Stockholm University Electrum 230, S-16440, Kista, Sweden [email protected], [email protected]

The approach presented here is based on the concept of Enterprise Modelling, where different modelling "worlds", or sub-models, are used. The objectives submodel describes, the "why", the long term intention or vision of the enterprise we are discussing or designing. The concept sub-model describes what "things" (phenomena) developers are talking about, using a conceptual modelling technique. The activities of the enterprise as well as the actors involved in these activities, are described in corresponding sub-models of the requirements specification. These models may describe an existing situation, or a future, desired situation. The requirements, functional as well as non-functional, regarding the supporting information system, are described in the information system requirements as two additional sub-models of the specification. A requirements specification is not developed in a simple, straightforward fashion. Many intermediate, and sometimes alternative design versions may exist. In order to deal with this, models to describe different configurations of designs and specifications are needed. Finally, it is necessary to link the requirements descriptions to the formal design specifications of the information system, the information systems sub-model. This give eight interrelated sub-models to be developed and maintained in requirements acquisition. In this paper also the process of modelling is discussed and the Enterprise Modelling approach is assessed by comparing it with a number of related approaches.

1. Introduction Acquisition and analysis of requirements for information systems is a strongly iterative and creative design activity. This activity of the information systems life-cycle is often neglected. Insufficient time and resources are allocated to it. The way to perform it, and the documents to produce, is not well understood. Its importance for the subsequent information systems design seems underestimated. In many respects, in particular concerning the acquisition and management of initial, "fuzzy" requirements, it resembles the process of requirements capture and the design of building objects in architecture [1, 2]. Not all requirements can be determined before the system is being used in real life situations. Some requirements may be "found" long time after the start of use of the system. This may lead to heavy rework and re-design. Our assumption is, however, that if more attention is paid to systematic, initial requirements acquisition and modelling, together with the analysis of enterprise objectives, the smaller the risk for heavy re-work. The approach presented here is based on the concept of Enterprise Modelling (EM) and the formulation of requirements for an supporting information system. This approach has been developed by * The author’s work on this paper is partly sponsored by SISU’s participation in the ESPRIT project F3 (6612) and the ESPRIT Basic Research project NATURE (6353) supported by NUTEK, Sweden. ** The author is on leave from Riga Technical University, Latvia, sponsored by the Swedish Institute, Stockholm, Sweden.

SISU (Swedish Institute of Systems Development), and is being introduced in the F3 project" From Fuzzy to Formal" [3, 4]. We have there chosen to represent the requirements specification as a structured description of eight interrelated "sub-models". The "sub-model concept" is to some extent similar to the view of requirements modelling in the DAIDA and NATURE projects, where four modelling "worlds" are introduced [5, 6, 7]. In our approach, the following eight sub-models (worlds) are suggested. The objectives sub-model describes, the "why", the long term intention or vision of the enterprise we are discussing or designing. The concept sub-model describes what "things" (phenomena) we are talking about, using a conceptual modelling technique. The activities of the enterprise as well as the actors involved in these activities, are described in corresponding sub-models of the requirements specification. These models may describe an existing situation or a future, desired situation. The requirements, functional as well as non-functional, we have on the supporting information system, are described in the information system requirements submodels of the specification. A requirements specification is not developed in a simple, straightforward fashion. Many intermediate, and sometimes alternative design versions may exist. In order to deal with this, we need models to describe different configurations of designs and specifications. Finally, we have to link the requirements descriptions to the formal design specifications of the information system, the information systems sub-model. This give us eight interrelated submodels to be developed and maintained in requirements acquisition. The reason to suggest these eight sub-models is our experience that there is a need and benefit to separate between particular concerns in requirements engineering. Each sub-model represents a particular concern and requires particular user and customer expertise. While there are certainly several ways of separating the concerns of requirements acquisition, we have found that these sub-models separate the different concerns in a workable and natural way. The different sub-models are, however, not developed (populated) in a sequential, waterfall-like, fashion. It is true that the information system requirements and the information system sub-models are, typically, developed in the later phases of the requirements acquisition process. It is, however, not always the case that the process starts "top-down" with developing an objectives model. Sometimes the situation of the modelling group may be such, that it is better to start developing some other model. For instance, if there is a general lack of common understanding of the important concepts of the enterprise (an observed situation of the modelling group), the group may well start of with developing the concept submodel in order to improve communication and understanding of what is being talked about. The concept of "Enterprise" should here be interpreted in a very wide sense. It could actually mean the whole enterprise or some small part of it. More often than not, in developing information systems, the concept "enterprise" will denote a limited area of activity of the enterprise of which we are concerned. Examples of a limited area might be "office document management", "customer relations management", or "publicity management" of a company. An enterprise could also mean the process of developing a method and a computer based supporting tool-set. In this case the tool-set can be seen as the information system supporting the "development activities", which are consistent with some "method objectives". Depending on how familiar we are with the application domain, its conceptual structure, and the requirements for computer support, the need to perform an extensive, in-depth environment modelling may vary. For instance, in a limited technical situation, where the requirements and the conceptual model is well defined, the need for extensive enterprise modelling is limited. Section 2 of this paper describes the different sub-models in more detail. Section 3 discusses guide-lines for managing and using the approach. Section 4 assesses Enterprise Modelling approach and relates it to some existing research.

2. "Sub-models" in Requirements Modelling Our assumption is that developing a requirements specification, basically implies "population" of a number of interrelated meta-models. These meta-models describe the kinds of interrelated "documents" (or sub-documents) to be developed. By following a set of "good" meta-models, the risk to develop incomplete, and inconsistent specifications can be reduced. By "good meta-models" we mean models which separate concerns in a way which improves clarity, as well as development work quality and productivity. Experience has shown [8, 9] that the use of an "objectives model driven approach" may lead to improved understanding of the problem realm for "end-users", decision makers, requirements holders and customers, as well as for developers. The economic value of improved communication and understanding for minimising re-work in later stages of the information systems development process, is well recognised [10]. In F3 [11] we propose to structure a requirements specification in an number of "sub-models", also shown in figure 1.

Configuration sub-model

Objectives sub-model

motivatesmotivates

motivates

motivates motivates

Activities and usage sub-model

Concepts sub-model

Functional requirements sub-model

Actors sub-model

Non-functional requirements sub-model

Information system requirements

Informations systems sub-model

Figure 1 Many different kinds of relationships may exist between the sub-models. Note that the objectives sub-model plays a dominant, motivational role, i.e., it primarily describes the reasons for developing and including components in the other sub-models

2.1. The Set of Sub-models In this subsection the set of sub-models used in the Enterprise Model are informally described. A more precise description is given in [11]. - The objectives sub-model. In this part of a requirements specification we describe, in a structured way, the "why" part of a requirements document. Goals and business rules for a particular enterprise activity (or set of activities), existing, to be modified, or to be designed, will be stated, and their relationships analysed. Other component types of this sub-model are problems, causes (of problems), opportunities, and development actions. While goals and rules are the "important" components of this sub-model, the other types of components help and support the detection as well as formulation of goals and rules. They are hence considered as important text components in order to document and explain why certain rules and goals have been formulated. The objectives model is a graph with the above types of components as nodes, connected by relationships of type "motivates" or "influences". The motivates relationship is here seen as a refinement relationship (e.g. a goal is refined in a number of sub-goals). The influences relationship is a relationship indicating positive or negative influences between objectives model components. These relationships can also be given different levels of priorities and "strengths", e.g. low, medium or high. - The concept sub-model. The concept sub-model is used to define the "ontology" of the "universe of discourse" that concerns us, i.e. the set of object types, relationships, and object properties of the application we are talking about. In this sub-model we also further refine business rules of the objectives model into static as well as dynamic rules for the concept sub-model states as well as for permissible state changes. For developing a functional information systems specification, the concept sub-model will define about what "things and relationships" information must be represented in the information system, and what should be the rules, implemented in the processes of the information system, according to which the information system should behave. The concept sub-model will, moreover, serve as a dictionary of user and customer defined concepts, and conceptual structures to be used to strictly express other parts of a requirements specification. - The actors sub-model. This sub-model is used to discuss and define the set of actors of the studied activity (individuals, groups, job-roles/positions, organisational units, machines, etc.), and their inter-relationships, such as part-of, reports-to, etc. This model includes links to the other sub-models, e.g. who is the "stakeholder" of a particular goal, who is responsible for managing an activity according to a particular goal, who is the author of a non-functional requirement, etc. - The activities and usage sub-model. In this part of a requirements specification, the particular organisational activity (in a wide sense), existing, to be modified, or to be developed, is defined and described from the point of view of activities, tasks, processes, and the information and material flows between them. Describing, for instance, human - computer interaction is part of this sub-model. Clearly, components of this sub-model are motivated by components of the objectives sub-model, they are performed using, or referring to, components of the concept sub-model, and they are (typically) carried out by components (resources) of the actors sub-model. Information system requirements, related to the above models, are described by the following two sub-models. - The functional requirements sub-model. This part of the requirements specification elaborates the specific objectives and requirements that are put on the information system to support the activities and objectives listed previously. Typically it will indicate needs for establishing information system objects (or relationships, attributes), deleting objects, modifying objects, and the need for checking, querying and browsing objects and relationships.

- The non-functional (NF) requirements sub-model. NF requirements are primarily related to the activity and usage model, and indirectly to the objectives sub-model, as activities normally are motivated by the objectives model. NF requirements concern components of the information systems sub-model, i.e., information subsystems. NF requirements can be of several different kinds, such as standards for interfacing other systems, restrictions concerning use of hardware and/or software, accuracy of information, timelines of information, security, access-rights, economic limits of the development project, etc. The information system is described conceptually by the information systems sub-model. By this we mean the complete, formal specification of the information system. It is the task of the IS designer to develop IS designs and descriptions such that designated activities and processes in the activities and usage sub-model, as well as the functional and NFrequirements are supported (to a higher or lesser degree). In order to manage the modelling process and its results, we need a configuration submodel. This is a sub-model, orthogonal to the other sub-models. The main concepts of this sub-model are version and release. We need this dimension for the reason that systems, they may be organisational or computer based, continuously evolve and change. For instance, the concept sub-model, or parts thereof, will change at times. New versions of these sub-models will be developed, based on other earlier versions. On the other hand, we cannot disregard such historical information, as some actors may be still using it. Developing a new version of some sub-model will most likely also require changes in the other sub-models. For instance, a new objectives sub-model description will certainly affect and require a reconsideration of all other sub-models. To manage "configurations" of descriptions is an important mission of a good requirements modelling facility. What we have described above is basically a set of interrelated descriptions or documents, each constructed with a predefined set of "permitted" types of components and component relationships. Depending on the purpose of the modelling exercise, we may, for a particular modelling job, need only a subset of these sub-models. Other sub-models may be, for a particular modelling purpose, superfluous and "empty". We may think of several other purposes for modelling the enterprise, than information system design. One such is the re-design of organisational activities, without assuming any supporting computer system to be developed. Another, quite typical purpose in practical situations, could be to reconsider the organisation’s goals, objectives, mission, etc., and then study how an existing information system actually supports the new set of goals. However, in this paper we assume that a business activity is to be studied and that requirements for computer support for it are to be developed. This requires all sub-model types indicated above. 2.2. An Example The relationships between these sub-models are exemplified in the following figure (2), which shows a few instances of the different sub-models. Assuming the "enterprise" is an auto repair shop, the goal "To gain respect and trust from old customers", which we assume is one of several goals, could be "detected" after analysing different, perceived problems of the enterprise (in this case the problem with old customers is observed and documented first). The goal may lead to different sub-goals, described by motivate links. One of them is, we assume, to "Maintain good contact with old customers". After a long discussion, consensus was reached that a new periodic activity in the workshop, "Christmas Card sending", motivated by the contact goal, should be introduced. The mission of this activity is to "At December 1st, send Christmas cards to all old customers". A discussion then started about what was meant by "old customers". After some debate, it was agreed to document a rule that an old customers are "Customers with cars older than 10 years and who have been doing repairs more than twice per year during the last 3 years". The Christmas Card sending proc-

ess was discussed and later decomposed in a number of sub-activities. The actor performing the sub-activity "signing cards", should be the manager of the shop. Preparation of cards and sending of cards should be done by clerks. The goals, rules, and activities discussed so far indicate the need for at least the following object types in the concept sub-model: "customer", "repair", and "car," a number of attributes, and some relationships. A functional requirement would be, for instance, to retrieve all old customers, and their addresses. A nonfunctional requirement would be to use a special colour laser printer to print the cards. This figure only depicts some simple examples of sub-model components and relationships. It cannot, without further discussion and detail provide justification for the approach as such. As will be pointed out in the next session, the major impact of the approach is the group-work process, the discussions, and the agreements that take place before a final model is constructed. This process, and its benefits, cannot be depicted in a simple two-dimensional figure. The objectives sub-model Problem Goal

The share of old customers is decreasing

hinders

To gain respect and trust from old customers motivates Goal Maintain good contact with customers

Rule

Old customers are customers with cars older than 10 years and who have been doing repairs more than twice per year during last three years

motivates

controls

The concept sub-model

The activities and usage sub-model

Concept

The actors sub-model Role

Activity

Customer - name - address

1 1

orders_repair owns Concept

Concept

Repair - amount - date

Car - age - make

Manager

Christmas Card sending Activity

2

Prepare cards

2

Activity

Clerk

Sign cards

1

Activity

reports_to Role

2

Send cards

3

3

The non-functional requirements sub-model NF Requirement

The functional requirements sub-model F Requirement

Select old customers

Cards must be in colour print 4

4

The informations systems sub-model System XMAS

Figure 2 Sample instances of the different sub-models and some of their possible relationships. Relationships of type 1 reflect information needs in various activities. Type 2 relationships reflect responsibility or performer. Type 3 relationships reflect functional or non-functional requirements of various activities. Type 4 relationships requirements to be satisfied (implemented) by different IS subsystems

3. The Process of Modelling. Discussion The primary objectives of performing Enterprise Modelling (EM) within Requirements Engineering are: • to improve and to document the participants’ knowledge regarding the current enterprise situation as well as regarding desirable future situations • to improve their possibilities to reach a clear, structured, and documented agreement on important concepts, properties, activities, and goals for the future enterprise situation • to develop a basis, as complete as possible, for designing an adequate information system, conforming to the enterprise objectives • to develop a set of interrelated documents, that in the future can be re-used, when redesigning enterprise objectives, activities, and information system requirements 3.1. The Process It is SISU’s experience that using a common, structured, graphical notation to express the EM, improves creativity as well as communication between partners of the process. The structured modelling technique has been briefly outlined above. However, a problem is how to describe the process, or activity, of enterprise modelling, and how to give guide-lines about how to perform it. We must here pay attention to the difficult, but important, problems of managing the EM process from a behavioural, communicative, political, as well as cognitive point of view. The different kinds of modelling concepts and sub-models, introduced in the second section, cannot in themselves make the EM process arrive at a successful result. It is rather the way the process is staffed as well as managed, that may lead to a result of acceptable quality. A set of preconditions must be satisfied in order to enter the EM context. If such conditions are not satisfied, there is a great risk that large resources will be wasted without obtaining useful results. Inside the EM context, different modelling as well as managerial situations may occur. An example of a modelling situation is that participants in the group do not agree on the interpretation of a particular concept. A managerial situation is, for instance, when one member of the group openly obstructs the rest of the group to perform work. Experience based guide-lines can be given in such situations. For instance, regarding the modelling situation above, try to decompose the concept, try to relate it to other concepts, etc. Modelling situations may therefore, by experience, recommend that certain modelling actions are performed, while managerial situations may give experience based recommendations to perform managerial actions. Enterprise Modelling is thus seen as performing situation-based modelling actions as well as managerial actions in the EM context. Within the EM context, modelling is performed in different sub-contexts, each corresponding to the kind of sub-model which is currently being used. e.g. the OM (objectives modelling) context, the CM (concept modelling) context, or the AM (actors modelling) context. Here, in the same way as in the overall EM context, different situations may arise, leading to different kinds of recommended actions. The progress of modelling in a particular context is, furthermore, driven by a number of "driving questions" such as "what concepts does this goal refer to?", "what is the problem of this goal?", and "who will be responsible for this goal?". Many such questions can be advised to carry the dialogue and the modelling process forward (see also [11]). 3.2. The Use of EM in Different Situations EM can be applied for different purposes and be performed by different kinds of individuals or groups. In some situations EM can be used as a technique to analyse the current situation

of an organisation (or part of it) and to set new objectives for the future. In other situations, EM can be used for developing of new products, or used to re-design business activities. In these cases the objective of performing EM is not, primarily, to build a new information system. However, in whatever form and for whatever purpose EM is performed, it is important that the participants are properly "preconditioned" and prepared for the modelling activity they are to be engaged in. EM is a rather domain-independent technique. It can be applied in many different types of enterprises and activities, for instance, planning the activities, work, and information support for workers and clinics in hospitals, as well as for planning of the production process of a new aircraft model. This also means that the technique must be supported by actors with specific domain-dependent knowledge and experience in order for the EM process to produce results of satisfactory completeness and quality. The composition of the EM team is instrumental for achieving success in EM. Among others, the following types of situations, where the EM approach may contribute to a better solution, can be distinguished: • There is a need to solve a "one-shot" business problem. EM will here be used to determine the problems scope, relate them to enterprise objectives, clarify the conceptual terminology, determine important products, activities, actors, their roles, etc. • EM is used to clarify the basic objectives and requirements for a new or improved information system. Properties of the current system will then be judged and evaluated with respect to the new requirements set up. • EM is used as a continuous activity to monitor the operations of an enterprise. The enterprise model will here act as the current "general map" of relevant parts of the enterprise. In a way, the map represents a partial base of enterprise knowledge. The map can be used in situations when "newcomers" must be introduced to the enterprise’s "business language, terminology, concepts, objectives, activities, etc.", or as a basis for re-design of business policies, processes, and rules. Also other types of uses of EM have been experienced. 3.3. Preconditions for Entering an EM Activity EM is not an activity where the syntactical and technical knowledge of "drawing boxes and arrows" of a particular type, in any way guarantees the success of the process and the usefulness of the output. In order to improve the possibility to complete the EM activity in a successful way, leading to a practically useful product, the following preconditions (at least) must hold: • The modelling staff is appropriately trained for the activity (or has previous experience in EM type of activities) • There exists a skilled and experienced modelling facilitator, knowing how to manage people in group-work, and knowing approaches how to start, stimulate, and complete the modelling work • Sufficient time and other resources are allocated to the activity • The modelling team is given a clearly stated mission to pursue • The team is well-balanced in terms of enterprise knowledge, knowledge of specific business or application-technical problems and methods, and knowledge of software and computing equipment opportunities, existing systems, etc. • The modelling team is given authority to design or re-design organisational as well as technical processes, procedures, concepts, and rules • Responsibilities must be assigned regarding the documentation, use, and maintenance of the EM to be developed

3.4. Modelling is Group-work Modelling is a typical group activity, where 1+1 may become 3. Modelling by group work, if properly managed, normally generates more ideas and "kicks" than individual or interview based modelling. When performing enterprise-internal seminars, issues which are important to the enterprise are no longer delegated to (outside) experts, but treated by local people with good knowledge of the enterprise, its problems and its opportunities. Furthermore, the things that are being modelled are issues and concepts which often are neither right nor wrong. They are people’s perceptions of some reality. As information systems are designed to support a number of human-oriented enterprise activities, it is important that several users and requirements holders participate actively in the modelling process. Experience shows that in a few days, users can learn to populate and to read EMs. Group-based modelling gives most, perhaps all, participants a sense of responsibility for the result obtained. It leads also to an easier change process, when the enterprise has subsequently to be changed. Modelling in groups, if properly managed, may lead to [12] • improved creativity • good balance between creativity and critique • solutions/designs characterised by consensus • "eye-openers" for all participants regarding important issues • increased knowledge and competence for all participants • better self-knowledge for participants • results are obtained faster than with conventional techniques • better "anchoring in organisation" is achieved, when key-persons do participate in the modelling process • cost-effectiveness However, there are also non-desirable situations that may occur in group-based modelling, if this activity is not properly managed, e.g. • some really bright ideas of individuals may be blocked • dominant, "besser-wisser" type of participants may negatively influence the result of the process, giving a one sided view only • personal authority relationships between group members may obstruct creativity and balance of the results

4. Assessment Enterprise Modelling is seen as a building of repository of the knowledge to be used to support to carry out the requirements acquisition process, to formulate functional as well as non functional requirements, and to be a description to which another kinds of system models can be linked [13]. Different groups of people involved in the modelling process are experienced in particular areas of enterprise, and they use concepts and terminology they have learned and refined during performance of their tasks. We can say, that people are "living" in different "worlds" in enterprise. Conceptual structures and terms, used in each world are to some extent a presentation of the environment people achieve for their survival as specialists [14]. It is not an easy task to find relationships or mappings between those different presentations, because of differences in languages and perceptions. Nevertheless, a holistic view of the enterprise is necessary in order to find reasonable, consensus-based solutions for information system development.

4.1. Achieving a Holistic View of Enterprise Two basic strategies for achieving a holistic view of enterprise seem essential: • improving the "level of culture" of specialists • improving the "level of culture" of modelling technology We consider a culture here as a possibility to perceive, and hopefully, in a case of specialists, understand, the presentations suggested by "inhabitants" of different worlds, relevant in requirements acquisition. The enterprise as a whole could be represented in a well elaborated, total Conceptual Model, supported by user friendly means for learning and understanding it [15, 16]. The approach explained in this paper also uses a concepts model, but in the combination with other types of models. We can say that some purposes of Conceptual Modelling and Enterprise Modelling are very similar, yet the way of achieving them is not. Both approaches are compared in table 1. In real life applications, requirements engineering usually is desired to be performed in a very short time period. Elaboration of a common conceptual model and learning of the concepts are, however, quite time consuming tasks. On the other hand, complete understanding of other "worlds" is not required from specialists. What is essential for them is a possibility to get an insight in other "worlds" and in the enterprise as a "whole". Navigation trough different sub-models is permitted in the Enterprise Model. If goal is stated in the objectives sub-model, the author of the goal can perceive the impact of activities, introduced for supporting of the goal, to other activities performed in enterprise. The actors model can display how the introduction of new activities affects responsibilities and communication structures of individuals and organisational units and like. Thus, the other "worlds" are perceived directly. If all of them are considered, specialists get a holistic view of enterprise indirectly. The Enterprise Model is pragmatically as well as semantically oriented. Contents and level of details in concept and other sub-models are dependent on current development situation. Even very fuzzy concepts, represented by natural language sentences, can be the elements of the EM. The purpose of the approach is not to loose information, elicited from users and specialists, and refine it and elaborate it in the concepts sub-model only if and when it is necessary and possible. Fuzzy concepts are here in many situations more preferable as compulsory and perhaps non-adequate refinements. Using pure Conceptual Modelling technique it is possible to view the enterprise from some abstract level, but contextual problems still remains. In Enterprise Model the concepts sub-model, that represents semantics of the acquired knowledge, is related to the other submodels, that deal with pragmatic issues of the enterprise and permit to decide, which concepts are needed and how detailed they should be presented in concepts sub-model. Worlds, or sub-models, of Enterprise Modelling have been introduced on the basis of experience in more than 50 business and system analysis projects carried out by SISU. Each world has its meta-framework consisting of elements that have been found supportive of human thinking and reasoning. These different worlds - objectives, activities and usage, actors, concepts, functional requirements, non-functional requirements, and information system, are used to "perceive", i.e., elicit human knowledge effectively. Inter-model links, in their turn, give a possibility to show the impact of elements of one world to the other worlds (see example in figure 2), and thereby support specialists to get an insight in these worlds as well as in whole enterprise.

Table 1 Conceptual Modelling versus Enterprise Modelling

Differences in...

Conceptual Modelling

Enterprise Modelling

Perception of other "worlds" (mostly)

indirect

direct

direct

indirect

semantic

pragmatic & semantic

all enterprise

sub-enterprise relevant for information system design

Perception of the "whole" (mostly) Orientation (mostly) Well elaborated concept model of

4.2. Supporting New "Worlds" by the EM’s knowledge Knowledge, amalgamated in the Enterprise Model, can further be analysed, restructured and combined with respect to different needs of users. It means that new "worlds," or meta models, can be created on the basis of existing knowledge. Frameworks of meta models are to be organised according to the presentations of the environment of particular groups of specialists - users of the Enterprise Model. We will consider three examples of frameworks for the illustration of possible meta models. - Example 1: Mental Maps for team performance in complex systems [17]. In requirements engineering team work is the object of particular interest, as requirements specification should be elaborated and agreed upon by groups, knowledge is elicited by groups, the business and the project are managed by groups, and further design is performed also by groups of people, i.e., teams. A Mental Map is a framework reflecting purpose, functions, state, and form of three systems: (1) equipment used in team work, (2) tasks of team members, and (3) the team itself (grey elements in table 2). Purpose corresponds to knowledge describing why a system exists, function - to knowledge explaining, how a system operates, state is meant for explanations and predictions about what a system is or will be doing, and form depicts descriptions of what a system looks like. Equipment knowledge explains characteristics of equipment elements, relationships among them, temporal patterns of equipment response, functioning and co-functioning of equipment elements, overall mechanism of equipments response, requirements fulfilled and objectives supported by equipment, and physical theories and principles concerning equipment. Task knowledge is about situations, criteria, analogies, procedures, strategies, methodologies, operational and logical basis and mathematical principles and theories concerning tasks. Team knowledge is about roles of team members, relationships among team members, temporal patterns of team performance, functioning and cofunctioning of team members, and overall mechanisms of team performance It explains why team and team members are needed, and concerns behavioural principles and theories such as psychology, management, etc. It should be noted here, that the authors [17] do not consider contents of form knowledge in detail. Yet in requirements engineering this structure unit can be useful, e.g., if the requirements of screen layouts and forms are important or critical . Knowledge according to the sub-models of EM is necessary for supporting the elements of a Mental Map. For instance, knowledge about purpose of the team is gathered from the objectives and actors sub-models (table 2). We conclude, that the knowledge acquired in the

EM can be made useful for "mental map" generation for the teams working on the complex systems. - Example 2: A framework for analysis of diversity and flexibility of organisations [18]. An information system is always embedded in some particular environment. Usually there are several possible variants of the information system to be embedded. To consider them, and to cope with reflections of changes in domain system of the information system, appropriate knowledge must be available. Work organisation, technical artefacts, physical space, and work activities are introduced as components of a framework for analysis of an organisation. The framework is not meant as a model of reality, but rather as a map of frame of reference, useful when addressing the various dependencies among work activities and other elements. Work organisation requires knowledge about formal and informal division of labour among and within the various occupational groups, as well as their skills and qualifications. Technical artefacts concerns knowledge about tools, as well as about other technical artefacts (e.g. telephone systems, various paper based documents, wall charts, etc.), that may support work. Physical space depicts knowledge about dedicated functions of workplace. This structure unit is introduced because "in a non-electronic environment, physical proximity is a prerequisite for doing tasks, for instance the tools, the materials and the persons have to be near each to other" [18]. Work activities concerns knowledge about the process of work (functional and behavioural aspects). Table 2 Possible Mapping between Mental Maps and Enterprise Model

Elements of framework

PURPOSE

FUNCTION

STATE

EQUIPMENT

Objectives Activities and usage Non-functional requirements

Activities and usage Actors Information system

Activities and Usage Actors

TASK

Objectives Activities and usage

Activities and usage Functional requirements

Activities and Usage Functional requirements

TEAM

Objectives Actors

Activities and usage Actors

Activities and Usage Actors

FORM Objectives Non-functional requirements

Table 3 Mapping between framework for analysis of diversity and flexibility of organisations and Enterprise Model Framework for analysis of diversity and flexibility of organisations Enterprise Model

Work organisation

Technical artefacts

Objectives Activities and usage Actors Functional requirements

Objectives Activities and usage Actors Non-functional requirements Information system

Physical space

Objectives Non-functional requirements

Work activities

Activities and usage Actors Functional requirements Information system

Table 4 Mapping between framework for software risk management end Enterprise Model Framework for software risk management Enterprise Model

Management

Objectives Activities and usage Actors Functional requirements Non-functional requirements

Task

Objectives Activities and usage Actors Functional requirements

Structure

Activities and usage Actors Functional requirements

Technology

Activities and usage Actors Functional requirements Information system

Actors

Actors Activities and usage Functional Requirements

Mapping between this framework and Enterprise Model framework is displayed in table 3. Our conclusion is that knowledge developed in Enterprise Modelling can support analysis of diversity and flexibility of organisations. - Example 3: A framework for software risk management [19]. Software risk factors have to be considered already in the early stages of information system development, i.e., in the requirements engineering stage [20]. If risk factors are not considered in the requirements specification, then it is a costly and difficult task to consider them in the later stages of design. To avoid such problems, appropriate knowledge about possible risk issues has to be available in the Enterprise Model. Authors [19] present the Environmental Model, that recognises risk management as a satisfacing behaviour. In their model, the concepts task, structure, technology, and actors are considered as main components generating a risk profile. The risk management process, and the management environment are described in detail. Task concerns knowledge for definition of project objectives, what the project should accomplish, what software systems to develop and what changes to carry out in the client organisation. Structure involves knowledge about systems of communication (who is communicating with whom, when and how frequently communications take place, how formal communications are, etc.), systems of authority (responsibilities between project actors and groups), systems of work flow (how project tasks are split in sub-tasks or activities, how are these scheduled over time, space, and actors) and the physical environment within software project environment. Technology includes knowledge about available methods, tools, and infrastructure to develop and implement the software system. It considers production, coordination and organisational aspects of the technology. Actors depicts knowledge about all participating persons and other "stakeholders" including customers, managers, maintainers, development groups, and users. It concerns their skills, experiences, expectations, commitments, beliefs and values [19]. Management concerns knowledge about managers, organisational maturity, and management methods. Mapping between the framework for software risk management and the Enterprise Model framework is displayed in table 4. It shows that knowledge developed in Enterprise Modelling is potentially useful for expressing and analysing risks in system development. 4.3. Discussion As we can see from examples 1-3, meta-models for using knowledge about the enterprise for particular groups of specialists, differs from the sub-models for knowledge elicitation. Frequently, one element of meta-model’s framework reflects knowledge elements from several enterprise sub-models. We can from this conclude that the Enterprise Model may serve as a mediator between different groups of specialists involved in requirements engineering. Links between different enterprise sub-models permit to maintain the holistic view of the enter-

prise by both strategies mentioned in the beginning of section 4.1. Developing meta-models convenient for particular groups of users, improves the "level of culture" of modelling technology. The possibility to show reflections of the introduced knowledge elements in several "foreign worlds" contributes to the improvement of a specialist’s culture as well.

5. Conclusions The Enterprise Modelling approach suggests eight different "worlds," or sub-models, for requirements acquisition. All of them have been motivated by more than five years experience of SISU in business modelling and system analysis. The framework is user driven and has been found to support human thinking and reasoning. Knowledge, amalgamated in a Enterprise Model, can be analysed, restructured and combined according to different needs of knowledge. If necessary, new meta structures of knowledge can be introduced. The Enterprise Modelling process is a typical group activity. Managing of the process concerns behavioural, communicative as well as cognitive issues. Several preconditions must hold for entering the Enterprise Modelling activity. Using the Enterprise Modelling approach it is possible • to improve and to document the participants’ knowledge regarding the current enterprise situation as well as regarding desirable future situations • to improve their possibilities to reach a clear, structured, and documented agreement on important concepts, properties, activities, and goals for the future enterprise situation • to develop a basis, as complete as possible, for designing an adequate information system, conforming to the enterprise objectives • to develop a set of interrelated documents, that in the future can be re-used, when redesigning enterprise objectives, activities, and information system requirements Enterprise Modelling is a rather domain independent technique. It can be applied in many different types of enterprises and activities, and be, or be not concerned with information systems development and design. Enterprise Modelling aims at bringing the users and customers into a more powerful position in the business and/or information system development process. The development of the Boeing 777 aircraft involved some of Boeing’s larger customers in the design process. The result was a dramatically different type of aircraft, better suited to the perceived needs of the customers. We believe Enterprise Modelling has a potential of achieving a similar effect in the field of business and information system development.

References [1] Cross, N. (Ed.) Developments in Design Methodology, John Wiley & Sons, Chichester. [2] Lawson, B. How Designers Think. The Design Process Demystified., Butterworth Architecture, London, 1988. [3] Bubenko, J. A., jr. Extending the Scope of Information Modelling, Fourth International Workshop on the Deductive Approach to Information Systems and Databases, Costa Brava, Catelonia, A. Oliv (Ed.), Departament de Llenguatges i Sistemes Informatics of the Universitat Politecnica de Catalunya, Barcelona, 1993. [4] Bubenko, J. A., jr, Wangler, B. Objectives Driven Capture of Business Rules and of Information System Requirements, IEEE Systems Man and Cybernetics ’93 Conference, Le Touquet, France, 1993. [5] Jarke, M., Bubenko J. A. jr, Rolland C., Sutcliffe A. and Vassiliou Y. Theories Underlying Requirements Engineering: An Overview of NATURE at Genesis, IEEE Symposium on Requirements Engineering, RE’93, San Diego, CA, Jan. 4-6, 1993.

[6] Jarke, M., Mylopoulos, J. Schmidt, J. W. and Vassiliou, Y. "DAIDA: An Environment for Evolving Information Systems", ToIS, 1992, 10, (1), pp. 1-50. [7] Jarke, M. Pohl, K. Establishing Visions in Context: Towards a Model of Requirements Processes, 93-08, Informatik V, Ahornstr., 1993, 55, 5100 Achen, Germany. [8] TEMPORA Consortium. The extended Sweden Post Case Study, E2469/SISU/NT3.2/2, SISU, 1993. [9] Willars, H. Amplification of Business Cognition through Modelling Techniques, 11th IEA Congress, Paris, 1991. [10] Curtis, B., Krasner, H., Iscoe N. "A Field Study of the Software Design Process for Large Systems", Communications of the ACM, 1988, 31, (11), pp. 1268 ff. [11] F3, Consortium. The F3 Reference Manual, SISU, Box 1250, S164 40, Kista, Sweden, 1993. [12] Willars, H., Modelleringshandboken, Del 1: Bashandledning, Triad-parterna/SISU, Stockholm, 1993 [13] Nellborn, Ch., Bubenko, J. jr, Gustafsson, M.R. Enterprise Modelling - the Key to Capturing Requirements for Information Systems, SISU, Box 1250, S164 40, Kista, Sweden, 1992. [14] Miller, G.A. Trends and Debates in Cognitive Psychology, Cognition, 1981, 10, pp. 215-225 (Published by North Holland). [15] Kangassalo, H. Conceptual Level Interfaces to Data Bases and Information Systems, Advances in Information Modelling and Knowledge Bases, H. Jaakola et al. (Eds), Amsterdam: Washington: Tokyo:, 1991, pp. 66-90. [16] Boman, M., Bubenko, J., jr, Johanneson P. Conceptual Modelling. DSV, Stocholm University, Kista, 1992. [17] Rouse, B.W., Cannon-Bowers, J.A., Salas, E. The Role of Mental Models in Team Perfomance in Complex Systems, IEEE Trans. on Syst., Man and Cybern., 1992, Vol. 22, No. 6, pp. 1296-1308. [18] Kjaer, A., Madsen, K.H. The dependencies between Work Activities, Technical Artifacts, Space, and Work Organisation, Proc. of the 16th IRIS, J.P.Bransler, K.Bodker, F.Kensing, J.Norjberg, J.Pries-Heje (Eds), University of Copenhagen, 1993, pp. 39-44. [19] Lyytinen, K., Mathiassen, L., Ropponen, J. Software Risk Management as Satisficing behaviour: an Environmental Model. University of Jyvaskyla, 1993. [20] Sage, A.P, Systems Engineering. New York: Chichester: Brisbane: Toronto: Singapore: John Wiley & Sons, Inc., 1992.