Elena Kushnareva
email: elena.kushnareva@malix.univ-paris1.fr

Irina Rychkova
email: irina.rychkova@univ-paris1.fr

Rébecca Deneckére
email: rebecca.deneckere@univ-paris1.fr

Bénédicte Le Grand
email: benedicte.le-grand@univ-paris1.fr

Modeling crisis management process from goals to scenarios

Keywords: Statecharts, MAP, process flexibility, Intentional Modeling, State-based Modeling

Modeling crisis management process from goals to scenarios

Elena Kushnareva, Irina Rychkova, Rébecca Deneckére, Bénédicte Le Grand

Introduction

Crisis management process is an example of a knowledge-intensive process (KiPs) [START_REF] Di Ciccio | Knowledge-intensive processes: Characteristics, requirements and analysis of contemporary approaches[END_REF]: it strongly depends on the situation (context) and tacit knowledge of human actors plays the central role in this process. On the other hand, crisis management has to comply with federal regulations such as the Emergency Management Guidelines. These characteristics make specification and implementation of crisis management solutions challenging.

In this paper, we consider the case of flood management process specified for floods on Oka River in the Moscow region in Russia. This process is implemented as a part of COS Operation Center (COSOC) -a smart city solution developed by COS&HT [START_REF] Helvas | Cos operation center[END_REF]. The existing COSOC solution was designed following traditional workflow-based approach: the flood management process is specified as a sequence of activities that have to be executed according to the current conditions (i.e., water level and status of the flooded regions) and in compliance with the Emergency Management Guidelines defined by the Ministry of Emergency Situations (MES) in Russia.

The experience shows that execution of workflows proposed by COSOC can often be problematic due to unforeseen circumstances (e.g., lack of resources, disrupted traffic, etc.) Current system provides only limited support for process flexibility and in order to implement an alternative scenario, the process manager often switches to "off-line" mode.

To improve the process flexibility and adaptability: 1) Process specification should capture its intentional perspective, or should answer a question "WHY do we carry out an activity/procedure?". Understanding intentions behind the guidelines will help to define alternative scenarios in the situations when the default scenario cannot be implemented [START_REF] Van Lamsweerde | Reasoning about alternative requirements options[END_REF] [START_REF] Amyot | Urn: towards a new standard for the visual description of requirements[END_REF].

2) Process specification should focus on WHAT has to be done instead of HOW it must be done [START_REF] Dietz | Basic notions regarding business processes and supporting information systems[END_REF]. In this case, only the process outcomes need to be fixed at design while concrete procedures or activities leading to these outcomes can be chosen by the process manager at run-time.

In this paper, we introduce an approach for modeling crisis management process from goals to executable scenarios. We use MAP to reason about intentions behind the flood management process (strategic level). MAP is a goal-oriented modeling language introduced by Rolland in [START_REF] Rolland | A comprehensive view of process engineering[END_REF][12] [START_REF] Rolland | A multi-model view of process modelling[END_REF].

We use statecharts formalism for representing the flood management process at the operational level. Statecharts is a state-oriented modeling formalism defined by Harel [START_REF] Harel | Statecharts: A visual formalism for complex systems[END_REF].

To align the strategic and operation process levels we translate the MAP model of flood management process to the statecharts.

Statecharts specifications are executable. We simulate the flood management process, showing how the process goals defined on the strategic level can be achieved by various scenarios executed in the operational level.t

The remainder of the paper is organized as follows: in Section 2 we introduce the case study of a flood management process and specify this process on the operational level using statecharts; in Section 3 we specify a goal model for the flood management process; in Section 4 we translate MAP model to statecharts; in Section 5 we illustrate how the complete model of the flood management process -strategic and operational levels -can be simulated in YAKINDU Statecharts tool; in Section 6 we draw our conclusions.

Flood Management Process: Operational level

In this section we briefly introduce our case study -the flood management process; we show how this process can be modeled with Statecharts formalism.

Flood Management Process

Floods on the Oka River in the Moscow region are seasonal events caused by an increase in the flow of the river, provoked by intensive snow melting during the spring months. Cities built along the Oka River are confronted to the risk of flooding and can expect important damages, affecting thousands of people. Floods on Oka also represent substantial risks for the critical infrastructure facilities situated in the area: a railway bridge, a pontoon road bridge, an electric power plant, etc.

Along with other types of crisis, the flood management process has to comply with the Emergency Management Guidelines [START_REF]The ministry of the Russian Federation for civil defense and elimination of consequences of natural disasters[END_REF] defined by MES. This document prescribes the activities that have to be carried before, during and after crisis situations by different public services and agencies of the city.

As specified in Section 1, the flood management process is implemented as a part of COSOC -a process-aware information system used by a government to manage the variety of cross-domain operations within the city.

The functions of COSOC can be roughly divided into three groups: (i) data collection and visualization, (ii) analysis of the situation and decision making and (iii) triggering response processes.

The COSOC process manager is a member of the city administration who is responsible for monitoring the situation and handling emerging issues. He/she can accept or decline the solution proposed by the system; when a workflow is triggered, he/she monitors its execution and intervenes when decision-making is required.

When the problematic situation is resolved, the process manager can provide feedback to the system: request for process improvement, modification of monitored parameters list, etc.

In our previous work [START_REF] Kushnareva | Modeling business processes for automated crisis management support: lessons learned[END_REF], we examined the BPMN specification of the flood management process designed for COSOC and showed that the capacity of PAIS to support flexibility of the process is inherent to the underlying process modeling paradigm.

In order to provide the flexibility of the process, we design a state-oriented model of the flood management process in the YAKINDU Statechart Tool (SCT) using the formalism of statecharts.

Statecharts model

The statecharts formalism specifies hierarchical state machines (HSM) and extends classical finite-state machines (FSM) by providing: depth (the possibility to model states at multiple hierarchical levels); orthogonality (the possibility to model concurrent or independent sub-machines within one state machine); broadcast communication (the possibility to synchronize multiple concurrent submachines via events).

The statecharts model (Fig. 1) describes the process with a set of states (e.g., Alert, Emergency, Restoring Normal Functioning, etc.) and transitions between them. Process execution starts at an initial state and terminates at a final state. The sequence of states and transitions that leads from the initial state to the final state can be seen as a process scenario.

In statecharts (unlike Petri Nets, where transitions are associated with the execution of an activity) each state transition can be triggered by a specific event or combination of events. For example, the event E2: water level h>10cm and keeps rising triggers a transition from Alert to Emergency. The activities producing these events can be selected at run-time. We call this deferred binding.

As a result, a process specification is divided into two parts: the statetransition part, defined with a set of states and transitions between states and their triggering events, and the activity part, defined by a list of activities specified by their preconditions and outcomes. The process enactment can be seen as a dynamic selection of activities to produce some outcomes (events) that make the process progress towards its (desired) final state.

Flood Management Process: Strategic level

In this section we explain our choice of modeling formalism, introduce the concept of MAP, illustrated on the flood management process example, and propose a procedure for transforming a MAP to a Statechart model.

Choosing the formalism

Processes may be formalized in an intentional way in goal-modeling approaches to model the processes according to the purpose of the actors/organizations. We quote among them i* [START_REF] Yu | Modelling Strategic Relationships for Process Reengineering[END_REF][18], KAOS [START_REF] Dardenne | Goal-directed requirements acquisition[END_REF] and MAP. We choose the MAP modeling language in our approach because it allows formalizing flexible processes with high level organizational intentions. It supports variability for the goals and offers the possibility to follow different strategies by focusing on the intentional aspect when enacting methodological processes [START_REF] Deneckre | Modeling the role variability in the map process model[END_REF]. i* has an operational semantic for the tasks but not for the goals and it is not used to model strategic goals; it is not designed to be a variable framework, therefore it does not afford a high level of flexibility. As for KAOS, it supports variability and have a well-structured semantic but is less involved in the intentional aspect of IS actors. Furthermore, KAOS has a rigid task-decomposition; modeling complex intentional processes is then difficult [START_REF] Rolland | Systems design for requirements expressed as a map[END_REF]. MAP specifies processes in a flexible way by focusing on the intentions and the different ways to fulfill them, according to the context of each actor. A MAP model is presented as a graph which nodes represent intentions and edges represent strategies. An edge is defined between two nodes where its related strategy can be used to achieve the intended target node. There may be several edges entering a node representing all the strategies to fulfill an intention. A section is a triplet <source intention, strategy, target intention>, which represents a particular process step to achieve an intention (the target intention) from a specific situation (the source intention) following a particular technique (the strategy). The MAP meta-model has been validated in several domains as IS engineering [START_REF] Rolland | A multi-model view of process modelling[END_REF], requirement engineering [START_REF] Rolland | Systems design for requirements expressed as a map[END_REF], method engineering [START_REF] Kornyshova | Method chunks selection by multicriteria techniques: an extension of the assembly-based approach[END_REF], enterprise knowledge development [START_REF] Barrios | Model driven architectures for enterprise information systems[END_REF], etc.

MAP model

The MAP corresponding to the flood management process is presented in Fig. 2.

There are three intentions specified on this level: Prepare to flood, Secure the city and Handle emergency. Each intention can be fulfilled by several strategies. For example, Handle emergency intention can be reached either from the initial intention (Start) -in case of need for emergency evacuation of the citizens before the preparations finished, or from the Secure the city intention -in case of lack of resources, or getting the 'Electric Power Plant (EPP) is flooded' alert. The final intention (Stop) corresponds to the process termination and can be attained either By removing barriers, or By restoring normal functioning of objects of the city infrastructure. The flood management MAP model also contains a recursive section <Handle emergency, By rescue operations, Handle emergency>, which represents the maintenance of a need in emergency handling while receiving the rescue operations requests.

All goal-oriented models share the same problem concerning the intentions operationalization. The MAP model highlights this problem by proposing several kind of guidelines to guide the user through the navigation in the map and to explain how a specific intention can be realised with a specific strategy (IAG: intention achievement guideline). This guideline can be described in several ways: in natural language, with an algorithm, through a workflow, etc. However, it is always difficult to offer an automatic way of operationalizing this guideline. Statecharts open an essential dimension to this problem by offering an automatic operationalization of the process contained in the IAG.

Statecharts semantics for MAP

In this section we propose a procedure for transforming a MAP to a Statechart model by using the example of the flood management process, and discuss the advantages that can be gained by this transformation.

As introduced in Section 3, a MAP is specified as a set of intentions to be achieved, and strategies for achieving them. The intentions can be interpreted as sets of states a process manager desires to reach. However, reaching a state does not necessarily mean that the intention is achieved. Some goals may require a number of actions to be performed before being achieved. Furthermore, taking an action aimed at attaining the goal, does not necessarily end in achieving this goal, but should reach a state which is closer to that goal than the previous one. As a result, intentions in statechart representation have a "core", which is a set of states where some actions towards attaining the goal are performed. This is a statechart representation of strategies.

The MAP flood management model transformed in statecharts semantics is shown in Fig. 3. For example, the condition that triggers the Handle emergency state is either water rises higher than 45 cm (which implies closing roads/bridges), or the Living Area or EPP sub-state becomes Unsecured (Fig. 1). Following the statechart model, the Living Area goes to Unsecured state when lack of resources is detected. The EPP sub-state, in its turn, can only reach the Unsecured state when the EPP is flooded and needs to be secured. Hence, lack of resources, need in closing roads/bridges or a flooded EPP force process manager to change his/her intention from Secure the city towards Handle emergency. In order to fulfill the goal and leave the state, the process manager has to request reinforce-ments, close roads/bridges or secure EPP. In other words, he/she has to make a decision, which strategy to use.

In our example of crisis, the decision-making process in statecharts can easily be operationalized.

Each state of the statechart is associated with the list of mandatory and optional activities that must/can be carried out upon entering, upon exiting and while in this state. With the state-oriented paradigm, the objective of the flood management process is as follows: the process participants (i.e., MES and Police Taskforce) should respond to the events that occur in the environment (e.g., rise of water, flooded EPP, etc.) by executing the operation procedures and producing the outcomes in order to maintain the secure functioning of the city in specified domains.

Thus, transforming a MAP representation to a Statechart representation enables operationalization of MAP and, therefore, linking them to the process scenarios for further simulation.

Process simulation with Yakindu Statecharts Tools

In this section, we consider the executable level of scenarios of the flood management process by simulating statechart model in YAKINDU Statecharts tool.

Fig. 4 illustrates the simulation process of the Statechart model (Fig. 1) and Statechart representation of a MAP model (Fig. 3). For clarity, the bottom right model represents a water level detector. The statecharts are executed concurrently. Current situation is described by the six active (red) states: the water level is above 45 cm; the active intention is Handle emergency, which is not yet achieved; extremely high water level triggers a set of procedures in High risk state in Living Area; the EPP is flooded and Unsecured at the moment; roads/bridges are closed; resources are under Crisis Control.

In order to fulfill the Handle emergency intention and return to Secure the city, a process manager needs to provide EPP with security, so that the Unsecured state would not be active.

The state-oriented paradigm allows for deferred activity planning: an activity can be defined at run time, based on the desired outcome and on the context (i.e., resources, etc.). In response to unforeseen conditions, the process manager can select the next best step from the list of available activities. Thanks to deferred binding, he/she can also define a new activity better adapted for a situation.

Thus, the state-oriented paradigm creates a recommendation system where the process manager plays the leading role in scenario definition.

Conclusion

Crisis management process is safety-critical its failure could result in loss of life, significant property or environment damage. To ensure safety and security, the activities performed during crisis management are highly regulated at federal level. However, crisis handling requires high agility and never follows the same scenario.

Our experience with COSOC processes shows that a concrete flood management process relies a lot on the experience and decisions of the process manager. Assessment of a situation, adaptive scenario planning and handling the unpredictable situations represent challenges for the supporting information system.

By combining the MAP and Statecharts we arrived at a formalism which defines how human intentions drive a process. The result is an intention-driven approach to process modeling that offers an intention operationalization and provides a process manager with guidelines from goals identification to scenarios execution.

In our future work, we intend to test this process modeling approach on other cases and implement it as a part of recommendation system within COSOC.

Fig. 1 .

 1 Fig. 1. Statechart model of a flood management process

Fig. 2 .

 2 Fig. 2. MAP model of the flood management process

Fig. 3 .

 3 Fig. 3. Statechart representation of a MAP flood management model

Fig. 4 .

 4 Fig. 4. Simulation of the flood management process in YAKINDU SCT


Benoît Lebeaupin
email: benoit.lebeaupin@centralesupelec.fr

A Language for Writing System Specifications in an Aeronautical Context

The ambiguity of natural language is an issue which predates requirement engineering. This issue is, in the general case, obviously unsolvable, nor actually needing a solution. However, we think that in particular contexts, it is feasible and desirable to reduce the ambiguity of free text specifications. We look at how specifications are actually handled in a company to be able to propose an useful but not too disruptive method for writing better specifications. We are currently developing and investigating how to validate this method.

I. INTRODUCTION

Requirement engineering (RE), even if it is a relatively young field, is quite a vast subject with different subfields which can refer to various sciences such as computer science, ethnography and logic. The aim of the present work is to facilitate communication between actors who want to build complex systems which can comprise both software and physical parts, particularly in an aeronautical context, and could therefore be classified as of type 1.1 in Zave's classification [START_REF] Zave | Classification of research efforts in requirements engineering[END_REF].

For example, an aircraft manufacturer may want to buy landing gears from another company, an original equipment manufacturer (OEM). To do so, the aircraft manufacturer sends a specification document to the OEM stating what the landing gear system shall or shall not do. The OEM itself may want to decompose the landing gear into several subsystems, and buy these subsystems from other parties or build them in-house with different teams, requiring other specification documents. Complex systems can thus be incrementally divided into smaller parts which can be more easily designed by specialized teams.

A specification document is the way to tell the supplier what the buyer exactly wants and is a part of the contract engaging both parties. Obviously, it should be made the less ambiguous possible. However, it should also be readable easily by a lot of different persons, including aircraft certification authorities. Thus specifications need, at least for the near future, to be written mainly using natural language. Companies complain about the ambiguity of natural language and estimate that it is a major problem but cannot easily do without it.

This work aim to answer to the question "how to write less ambiguous specifications, which are however still understandable and writable easily, more processable by computers and more easily reusable ?" Eventually, we may wonder how we can avoid using natural language. The systems we want to specify can theoretically be anything, but practically, this work focuses on systems which include both physical (e.g. motors, brakes, hydraulic components...) and software parts and which interact mainly with other technical systems (rather than humans for example).

There are several technical challenges associated with the question in the previous paragraph: they focus on an interface between formal (what the system can or cannot do) and the informal (human communication during the requirement engineering process) and such interfaces are always complicated. We also want to be able to develop a method which is useful but which does not disturb too much existing processes and training, or it simply will not be used in the industry. Another challenge is the difficulty of evaluating the usefulness of such a method.

In the following section, we will look at what previous works in the field proposed to reduce specifications' ambiguity and why we think it is not adapted to the industry needs in this particular case. In the section 3, we introduce our contribution which focuses on the inputs and outputs of systems. The section 4 raises the complex problem of validation in the field of RE. Eventually, we conclude and look at various perspectives which could stem from our work.

II. RELATED WORK

We should begin by stating that "requirement engineering" covers a lot of different things. For example, the "requirements" as the atomic components of an aeronautical system specification have few things in common with the high-level "goals" of Goal-Oriented Requirements Engineering (GORE) in a software engineering context. A large part of research works (such as i* [START_REF] Yu | Modelling strategic relationships for process reengineering[END_REF] or KAOS [START_REF] Van Lamsweerde | Goal-oriented requirements engineering: A guided tour[END_REF]) in the RE domain thus concern a different part of the RE process compared to what we need for this work.

Another discrepancy is that, understandably when we look at the origin of the field, most of RE works concern software-only systems, but the systems we focus on are physical systems which may include software. What differences does it make? Firstly, software systems are usually considered as discrete and various RE methods are based on this (such as the transition axiom method [START_REF] Lamport | A simple approach to specifying concurrent systems[END_REF], or Event-B [START_REF]Modeling in Event-B: system and software engineering[END_REF]), but the inputs and outputs of a motor or the ambient temperature for example, are continuous and are better modeled as continuous. Another difference is that physical systems directly interact with the physical world, which adds less predictable and less formalizable parameters.

The matter of formalization is something important in specification because it is closely linked to ambiguity: a formal language is usually non ambiguous, but is using a formal language the only option to communicate unambiguously? One obvious problem is that a formal language allows to communicate only with those who know it. Another problem is that because of complex interactions with the physical world, system engineers usually agree that a completely formalized physical system specification is impossible. Thus we did not try to develop a self-contained, completely formal language such as Event-B, but rather tried to create something less ambiguous than free text, but more expressive than a formal language.

One of the ways to make natural language less ambiguous is to restrict it, for example by using templates such as "The system shall do something with a given level of performance in a given context" [START_REF] Pohl | Requirements engineering: fundamentals, principles, and techniques[END_REF]. It is a general advice often found in RE fundamentals books, however books' authors themselves warn against its mandatory use. In [START_REF] Mavin | Easy approach to requirements syntax (EARS)[END_REF], the authors propose 5 templates which can be composed to support the writing of various requirements.We think that these kinds of templates are both too generic because they may not help engineers a lot and too restrictive because a lot of requirements do not fit the templates.

Controlled Natural Languages (CNL) are restrictions of natural language by various means, depending on the type of CNL. We can identify two main type of CNL:

• "Simplified" or "technical" languages such as Simplified Technical English (STE) [START_REF]ASD Simplified Technical English[END_REF] are made to facilitate human communication, particularly for non-native speakers, and are used, for example, for technical documentation. • "Logic-based" languages such as Attempto Controlled English (ACE) [START_REF] Fuchs | Attempto Controlled English (ACE)[END_REF] aim to facilitate human-computer communication Both types of languages have usually a controlled vocabulary, composed of predefined words (which are close to protected words in programming languages) and content words, defined by the user. These languages also restrict the syntax, but using different rules, adapted to the language purpose: For ACE, we can only write sentences which are automatically and unambiguously translatable into first-order logic, easily "understandable" by a computer, whereas for "technical" languages, we could have rules such as "sentences will be composed of less than 15 words", since long sentences are harder to understand for humans. Our work is closely related to "logic-based" languages: we essentially search to have a language of this type which includes the needs of requirement engineers. The authors of [START_REF] Gervasi | Lightweight validation of natural language requirements[END_REF] automatically extract models from textual requirements and check that these models satisfy certain properties. This "lightweight formal method" is interesting and relatively economical, however it seems to need requirements which use a very precise language and are highly structured and regular. The aim of our work is to be able to write this kind of requirement with the less additional cost possible.

Our work builds upon various sources 1 , among these, an interesting article is [START_REF] Zave | Four dark corners of requirements engineering[END_REF], which will be mentioned several times in the next section. We however did not find a lot of works focusing on the precise needs presented here, even if there is a real industrial demand for such methods and tools. The CRYSTAL [START_REF]CRitical sYSTem engineering AcceLeration[END_REF] project is focusing on this aspect: ontologies and patterns are used to obtain less ambiguous and more processable requirements [START_REF] Fraga | Ontology-assisted systems engineering process with focus in the requirements engineering process[END_REF]. We believe our work is different and complete these efforts by proposing a more flexible approach than static, predefined patterns and by requiring less effort than the construction of a complete ontology before beginning to write a specification.

III. CONSIDERATIONS ON SPECIFICATION WRITING

A. Observations and First Goals

Together with a literature search, we began our work by analyzing specification documents sent to or written at Safran and by discussing with the persons responsible of requirement engineering in the company. The following observations are thus obviously not representative of the state of the art of academic RE, but we think they represent reasonably well what actually happen in the industrial context presented earlier.

• It is practically impossible to write a non-trivial, completely formal specification. • It is however possible to rewrite at least some parts of existing specifications to make them less ambiguous. • This kind of specifications is created using preexisting work, such as client specifications and engineering studies. The usual step of requirement elicitation is largely absent, at least at the OEM level. • We often find the same, or almost the same, requirements in different specification documents. • There are confusions between requirements, assumptions, and "hypotheses", where assumptions, in the sense of [START_REF] Zave | Four dark corners of requirements engineering[END_REF], "describe the environment as it is in the absence of the machine or regardless of the actions of the machine" and hypotheses are implementation biases: suppositions the customer makes about the design of the system.

We think that writing "better" requirements will allow us not only to have more readable individual requirements, but will also make the complete process easier (for example, to determine if some given requirements should be linked to other lower-or higher-level requirements).

How can we write "better" requirements? The first axis we identified is to write two equivalent things the same way. It applies of course to the vocabulary (for example, if the studied system is a landing gear, it should not be called "the system" in a requirement and "the landing gear" in another), but also to syntax2 :

following conditions are met: -1) The signal ON is true -2)..." 3 and • "The system shall transition into STANDBY state when all the following conditions are met: -1) the OFF state is true -2) The signal ON is true -3)..." are strictly equivalent, but written differently.

How then can we determine if two things are equivalent? Basically, if they refer to the same "concept". This is related to what Zave and Jackson call a "designation" in [START_REF] Zave | Four dark corners of requirements engineering[END_REF], an informal explanation of a term. Additionally, since we agree with their statement that "a specification should contain nothing but information about the environment", what kind of concepts can be mentioned in a specification? Zave and Jackson classify "actions" 4 into three different types:

• environment-controlled and unobservable by the system, • environment-controlled and observable by the system,

• system-controlled and observable by the system. They consider that actions cannot be controlled by the system if it cannot observe them. Additionally, we think that unobservable actions are not relevant to specifications: if we need to mention something in a specification, then it must have an impact on the system. If this impact can be unambiguously traced back to observable actions controlled by the environment, it should be done to clarify the specification instead of having unobservable actions. If this impact cannot be traced back to observable actions controlled by the environment, then it means either there is no impact, or we do not know it and this will cause ambiguity.

We therefore want to restrict what is present in a specification to the part of environment which directly interacts with the system. The distinction inputs/outputs (environmentcontrolled/system-controlled) is less absolute for physical systems than it may be for software 5 , but it is still a practical way to describe things, so we will use these terms in the rest of the paper.

B. A Proposition of Formalization

Concretely, how can we use what is presented earlier to write less ambiguous specifications? We consider that each requirement is a boolean formula, basically: "if we have such properties on the inputs, we want such properties on the outputs". The system respects the specification if all requirements are true. Attached to each input/output (I/O) would be values, such as false/true for discrete signals, or rotational speed, torque or current for physical I/O. Using, for example, relational operators, we can write atomic formulas and compose them using boolean 3 Sentences written in this font are requirements or parts of requirements, usually taken from an industrial specification document. They were modified to make them generic for obvious intellectual property issues 4 Once again, this is a software, event-based point of view, in our context, "action" could be replaced roughly by "property of the environment" 5 For example, the rotational speed of a motor axis may be an output for a functional requirement and an input for a safety requirement operators to create a requirement. For example, the requirement "if the signal CMD_FWD is true and the rotational speed of the wheel axis is less than 18 rpm then the system shall generate a 5 N.m torque on the wheel axis" can be decomposed into (CM D_F W D = 1), (rot_speed wa < 18 rpm) and (T wa = 5 N.m), and connected using a boolean "and" and a boolean "implies", where rot_speed wa is the input modeling the rotational speed of the wheel axis and T wa the output modeling the torque on the wheel axis.

The textual requirement is more readable and writable, especially for non-technical people, than the "logical" form ((CM D_F W D = 1) ∧ (rot_speed wa < 18 rpm)) ⇒ (T wa = 5 N.m), which explains why we are still using natural language for specification documents. Therefore requirements should, at least for now, stay in textual form. However, we think that encouraging requirement engineers to write textual requirements which can be translated to a logical substrate should reduce requirement ambiguity. An interesting question is which logical substrate among the various existing ones do we choose for our language?

We have analyzed several different industrial specifications as well as talked with requirement engineers, and continue to do so, to be able to know what constructs are typically needed in a specification. There are two necessary kinds of constructs: construct to get atomic, boolean-valued formulas from I/O values (e.g. relational operators) and operators to get formulas from other formulas (e.g. boolean "and"). For the moment being, we have identified classical constructs ("and", "or") or more domain-specific ones, such as "the probability of a failure leading to X shall be less than p", where X is a boolean formula (for example "the rotational speed of the wheel axis is null" which could be written "rot_speed wa = 0") and p a probability, usually expressed in events per flight hour in an aeronautical context.

We have to be cautious when adding such constructs to our language since we do not want to reintroduce the ambiguity we aim to remove by using our language, but these construct may not be formal: in the previous example, "failure" or "leading to" cannot be formally defined. Since these expressions are used in actual specifications and engineers do not seem to have any problem interpreting them, we have to assume that these expressions are not ambiguous even if they are not formally defined, and are what Chantree and al. would call "innocuous ambiguities" in [START_REF] Chantree | Identifying nocuous ambiguities in natural language requirements[END_REF]. We have to find, and integrate in the language, the constructs which are useful for specification writing and either formally defined or not formally defined, but understood the same way by all potential readers and writers of a specification. It may seem to be an impossible task, but we should note that all current system specifications are made using natural languages and the assumption that everyone understand the same thing when reading the same sentence. Our aim is not to create perfectly formal specifications, but to write "less ambiguous" specifications.

We wrote earlier that environmental variables which are not identified as I/O of the system should not appear in the 1 2 E > 4 Fig. 1. A simple state machine, "E > 4" is a guard specification, but an user may want to write a requirement such as "during takeoff, the system shall..." and "takeoff" is not an input of the system. Firstly, as we proposed, the user should be able to decompose "takeoff" into one or more properties on one or more inputs of the system. If he cannot do that, how is the system supposed to "know" that the airplane is taking off? Assuming the user does have such a decomposition, one problem could be that this decomposition is a complicated formula A, which would reduce the clarity of the specification and could prevent the engineers from understanding what is the "physical" meaning of a requirement where A appears. One conceptually simple way to solve this problem would be to define the string "takeoff" as equivalent to the formula, the same way we create new variables which refer to the results of complicated formulas in a program, and most importantly, to precise that you're doing so in (the preamble of) the specification. Thus the original requirement would stay the same, but "takeoff" would refer to a formal definition. "takeoff" is now what we call a "composed input".

C. The Issue of "States"

When we look at real specifications, we notice that the example given in the previous subsection is quite simple: almost no requirement are simply combinational, and they usually refer to "states" (for example "In state BKWD, if the rotational speed of the wheel axis is less than 18 rpm and the signal CMD_BKWD is true, then the system shall generate a -5 N.m torque on the wheel axis"). These states are sometimes defined in the specification by cryptic requirements such as "The system shall have an ON state", but specifications never define exactly what is a state, nor how a system can "have" them. It can create quite ambiguous requirements such as "The probability of inadvertent activation of the system (transition from OFF to STANDBY or ON state) shall be less than 10 -8 per Flight Hour".

This problem, mentioned for example in [START_REF] Zave | Four dark corners of requirements engineering[END_REF], is mainly caused by the fact that such requirements are a blatant implementation bias. If we consider, as Zave and Jackson do, that requirements can only be statements about the environment, the states exist only in the environment. We consider that states are simply what we introduced as "composed inputs" in the previous subsection, which are simple names used as placeholders for properties on the environment of a system. A simple example could be that the condition "when in state 2", where the state 2 is defined by the state machine given in fig. 1, is equivalent to the condition "if the value of the input E has been greater than 4 in the past". Of course, the example is quite simple, but the principle does not change for a more complicated state machine: the so-called "states" are just a faster way to write properties, particularly temporal properties, on the environment of a system. As for other composed inputs, the definitions of the states should be explicitly written and identified as such in the specification.

D. More on Inputs/Outputs

What are exactly the inputs and outputs that we mention in this paper? First of all they are abstractions of properties of the environment. The difficult question is how much abstracted should an I/O be? For example, a three-phase line power supply could be modeled as one input with a "power" value, or 2 inputs of value "tension" and "current", or 6 inputs, 2 tension-current couple for each phase. The optimal abstraction level will obviously depend on how the I/O is used in the specification. A simple abstraction is easier to model but will not have the same expressing power as more complicated ones. For example, if we model a 3-phase line with one "power" input, it will not be possible to express a phase loss, but in the 6-input abstraction, a phase loss is expressed simply by having a null current for one of the phase.

One of the way we could "give back" this expressing power to the simpler abstractions would be to add "attributes" to I/O, for example the 3-phase line could be modeled as one input with a "power" value and two attributes "electrical" and "three-phased". If we know that "three-phased" "electrical" inputs can lose a phase, and have written it in an ontology for example, we can then write requirements such as "If (the power supply) have (a phase loss), the system shall...". As for what we wrote earlier, an attribute and its properties may not be formally defined if we consider that everyone have the same interpretation of it.

We mentioned that what is written in a specification, like I/O, must refer to some concepts so we can know what they mean. We can wonder if the cost of defining these concepts is too important compared to the eventual profits, and would make what we are proposing useless. However, in the specification documents we study, most inputs and outputs (I/O) are defined, although usually incompletely and imperfectly, to give a context for the system specification or simply to help define the system boundaries (for example by drawing a box representing the system, linked with arrows to other boxes representing other systems in the environment). So even if this kind of information is not, as far as we know, currently used how we envision it, companies do dedicate resources to create it and write it. It means our proposal requires less resources and adaptation: one of the point of our work is that the I/O we use should correspond relatively well to the I/O used by system engineers when they are writing "boxes and arrows" architectural models such as SADT, so we can reuse what was done in these models to write better specifications.

E. How Can We Treat Non-Formalizable Requirements?

The principle we present here is quite generic, and we think that all requirements could be written in the form "if we have such properties on the inputs, then we want such properties on the outputs". However, we do not think it is a good idea, because the effort needed for the conceptualization and formalization of various inputs and outputs is too important. For example, a requirement may demand that "The materials used in the system shall not suffer corrosion under the environmental conditions described in document A Category C", where document A is an external, possibly normative document. We think this is an useful requirement and that formalizing, in the specification, the "inputs" it refers to (for example, the levels of humidity, pH, percentage of various chemicals in the ambient air...) is possible, but it would require too many efforts for almost no profit, since it is presumably already done in document A and it would reduce the readability of the specification. We notice the same thing for a lot of requirements: they are not "formal" and it would be too difficult to model the I/O they implicitly refers to, so we have to continue using free text and try to make them as unambiguous as possible. Thus, when writing a specification document, there should be a compromise to find: at which point do we stop modeling I/O and write the usual free text requirements?

We think this compromise is more interesting in the aeronautical context, since the systems we focus on are technical systems, mostly surrounded by other technical systems, whose I/O are relatively easy to represent and formalize. It is not a surprise that the majority of the "difficult-to-formalize" requirements are those which involve humans, such as requirements related to maintenance.

One way to reduce the effort needed to write these requirements is that some of them are what we could call "generic" requirements: requirements which are present in every aeronautical system specification. For example, "All units and sub-units shall be protected against Electro Static Damage (ESD) during repair, exchange, maintenance and handling" could be found in any specification. For companies which are designing several systems for the same context, it may be useful to have a library of well written requirements of this type, which is automatically added to a new specification document, in a crude yet simple reuse strategy.

Related to these "generic" requirements, another type could be the "parametric" type: requirements that change only by a numerical value (for example "The service life target of the system shall be 24,000 flight cycles") or only by the document or part of the document it refers to, like in "system shall not suffer corrosion under the environmental conditions described in document A Category C". Once we know the pertinent information (for environmental requirements such as the second example, the exact reference is typically given by the location of the system in the aircraft) engineers could directly generate this kind of requirements without having to actually write them. Once again, this is a relatively crude method for reusing requirements and it was not tested to see if it is profitable, but it could be useful and it is not necessarily done in the industry.

F. Preliminary Results

To test the principles we propose, we tried to put each requirement from a real aeronautical system specification from Safran into one of these categories "generic", "parametric" (both introduced in the previous subsection) or "translatable into the I/O formalism", the results are given in the table I. Some remarks on these results:

In the first place, the classification of the various requirements in these categories was not an exact process, for several reasons: we considered that a requirement was translatable in our formalism if we could find a translation and that translation required only a "reasonable" effort for modeling the inputs and outputs. Moreover, as all translation, this translation is rarely exactly equivalent to the original requirement, especially since the aim of this work is to better write requirements and that some requirements in this specification were quite ambiguous. Since we did not have access to all the specifications of the company, we did not know for sure that "generic" and "parametric" requirements are used in all the specifications. These results are here only for illustration and we do not claim that it proves that our work is useful, but our industrial partners think they are interesting and that such cover rates are sufficient to be of economic interest. The specification was neither a completely finalized work nor a rough first draft, and this is interesting because it was a relatively good specification, but we could still find errors or ambiguity.

The requirements we could not put into the previous categories because they were both too specific to the studied system and too difficult to formalize may still be dealt with using another method. For example, some were envelope requirements: they defined where the system could be installed in the airplane. We could imagine that these requirements could be replaced by one requirement referring to an external CAD model describing the installation envelop of the system.

IV. EVALUATION OF RE PRACTICES

As mentioned in [START_REF] Cheng | Research directions in requirements engineering[END_REF], few works in the RE field concern or even mention the scientific evaluation of RE practices. It is an important problem since if we don't have a serious evaluation of the method presented in a paper, we, and industrial actors, cannot be sure that this method is really useful. Experimentation is, after all, the basis of scientific method. The main issue is how to do these evaluations: the evaluation of a complicated design process involving humans and subtle communications between them, or even of a part of this process, is something quite complicated, especially since RE authors usually come from a computer science background and may not know experimental methods from, for example, social sciences, which may be quite adapted to the difficulties of evaluation in RE.

As a beginning researcher in the field of RE, the author of this paper would like to be able to know if the ideas presented here are useful or how they can be improved and wonders if there exist standard, "benchmark" tests, which could be used to compare the different steps of various RE methods.

V. CONCLUSION

We searched how aeronautical system specifications were written at Safran and how they could be improved, notably by discussing with engineers responsible of RE in the company. We believe that it is possible to make requirements less ambiguous and thus to improve the whole process of RE. One of the goal of this work is to propose a method which could realistically be adopted in the industry: specifications would be less ambiguous if they were (and could be) written in first order logic instead of natural language, but it is simply not possible to ask a whole industry to learn first order logic.

We searched in the fields of RE, language generation, natural language processing and controlled languages for methods which could be used to reduce the ambiguity of requirements in specifications. We did not find methods which could be directly applied to our problem, but some ideas and general concepts were found to be useful and constitute the foundation of our work.

We proposed principles aiming to reduce the ambiguity of natural language system specifications while trying to keep most of the expressiveness and ease of use of natural languages. Our work is designed to reuse as much as possible the efforts already done in a company when it needs information. The core of our work consists in writing the requirements as boolean formulas, where atomic formulas are properties on the environment (the inputs and outputs of the specified system). The results of this process are not formal requirements, but we are trying to obtain requirements which are the less ambiguous possible, by linking the concepts used in a requirement to exterior and agreed upon definitions. Of course, the work on both theoretical and practical aspects of our proposal is not finished and will be continued in the following years as the author finish his PhD.

We think it is impossible to write a complete specification without unconstrained natural language and some part of ambiguity, so any specification writing method should be able to tolerate free text, and compromises have to be found by requirement engineers between an easy to write, but potentially ambiguous or even wrong, free text and harder to write, but hopefully less ambiguous, constrained language.

Among future works, beside the needed development and scientific evaluation of our ideas, we think that we could write at least some parts of specifications using more or less formal models instead of natural language, and if we ever need to have these parts written in natural languages, the models could be automatically translated into natural language requirements. Another perspective would be to be able to realize automated reasoning on the "formalized" parts of the specification.

including internal methodology at Safran

We will see later that the "states" mentioned here are not a good practice in RE, but it does not change the pertinence of the example

ACKNOWLEDGMENT

The author is supported by the Blériot-Fabre chair, codirected between CentraleSupelec and Safran.


domain: info scco

text:
Pierre-Emmanuel Arduin
email: pierre-emmanuel.arduin@dauphine.fr

On the Measurement of Cooperative Compatibility to Predict Meaning Variance

Computer Supported Cooperative Work may rely on information technology in order to share information regardless where stakeholders are. Nevertheless, cooperative work needs more than just information sharing, notably because of meaning variance.

Considering that during cooperative work the same information may have different meanings from one person to another, we propose an approach in order to predict meaning variance by measuring cooperative compatibility. We study the expectations individuals may have from their colleagues during a given cooperative work. Such study leads to the measurement of cooperative compatibility, which has been used to predict meaning variance.

The calculation method proposed, as well as its relationships with meaning variance are discussed in this paper and currently tested within organizations.

I. INTRODUCTION

Information technology gives individuals the means to work together even if they are not in the same physical place. Information technology ensures information sharing between individuals, nevertheless authors as [START_REF] Schmidt | Taking CSCW seriously: supporting articulation work[END_REF] highlight how much cooperative work needs more than just information sharing, leading to focus on innovation and knowledge intensive approaches for Computer Supported Cooperative Work. Indeed, knowledge is a resource necessary to realize processes ( [START_REF] Grundstein | New Research on Knowledge Management Models and Methods, chapter Three Postulates That Change Knowledge Management Paradigm[END_REF]), and it results of the interpretation by someone of information ( [START_REF] Tsuchiya | Improving knowledge creation ability through organizational learning[END_REF]). Such information may be processed, stored and disseminated through information systems, but it is not knowledge, due to the possibility of meaning variance.

Within organizations, and particularly within extended enterprises, i.e. a network of firms collaborating in a project to achieve a common goal ( [START_REF] Ross | Enterprise Architecture As Strategy: Creating a Foundation for Business Execution[END_REF]), the limit of computers is reached when there is no awareness that during cooperative work the same information shared through the same information system may lead to create different knowledge from one person to another ( [START_REF] Landauer | The Trouble With Computers: Usefulness, Usability, and Productivity[END_REF], [START_REF] Walsham | Knowledge management: The benefits and limitations of computer systems[END_REF], [START_REF] Cardona | ICT and productivity: conclusions from the empirical literature[END_REF]), i.e. may lead to meaning variance.

In this paper, we propose an approach to measure how much individuals have common expectations from each other during a given cooperative work in order to highlight those who might create different knowledge from the same information. In other words, our approach aims at measuring cooperative compatibility in order to predict meaning variance.

After introducing background theories in the area of knowledge management, and particularly on the way different knowledge may be created from the same information, our approach is explained and discussed, from the interviewing of the respondents to the prediction of meaning variance through the measurement of cooperative compatibility.

II. BACKGROUND THEORY AND ASSUMPTIONS

The work presented in this paper relies on the assumption that two individuals may give different meanings to the same information. The way we give a meaning to information relying on knowledge management theories is introduced in this section.

As the author of this paper, I have got tacit knowledge, i.e. an individual cognitive construction, that I have structured into information during a process of sense-giving by writing these words. As the reader of this paper, you have interpreted this information by perceiving forms and colors, during a process of sense-reading. You have created new tacit knowledge that has a meaning for you (see Fig. 1). Such meaning may differ from one person to another.

For R.L. Daft and K.E. Weick, "Interpretation gives meaning to data, but it occurs before organizational learning and action." ( [START_REF] Daft | Toward a model of organizations as interpretation systems[END_REF], p. 286), that it the reason why we consider that predicting meaning variance could be useful during Computer Supported Cooperative Work. Authors as T.K. Haavik in [START_REF] Haavik | [END_REF] have already focused on meaning during Computer Supported Cooperative Work in the case of safety-critical operations. Indeed during cooperative work, information may be shared, stored and disseminated through an information system. Nevertheless, as knowledge is the result of the interpretation by someone of information ( [START_REF] Tsuchiya | Improving knowledge creation ability through organizational learning[END_REF]), information may have different meanings from one person to another. Meaning is given to information during processes introduced and studied by M. Polanyi in [START_REF] Polanyi | Sense-giving and sense-reading[END_REF]. He notably focuses on the way we read a sense in information that we perceive (by listening or by reading for example). He considers sense-giving and sensereading processes, and he defines them as follows: "Both the way we endow our own utterance with meaning and our attribution of meaning to the utterances of others are acts of tacit knowing. They represent sense-giving and sensereading within the structure of tacit knowing." ( [START_REF] Polanyi | Sense-giving and sense-reading[END_REF], p. 301). For S. Tsuchiya: "When information is sense-read through interpretative framework, it becomes knowledge." ( [START_REF] Tsuchiya | Improving knowledge creation ability through organizational learning[END_REF], p. 88). Such concept of interpretative framework has already been studied in the literature, being related to the concept of mental model ( [START_REF] Arduin | On the use of cognitive maps to identify meaning variance[END_REF], [START_REF] Jones | Mental models: An interdisciplinary synthesis of theory and methods[END_REF], [START_REF] Ozesmi | Ecological models based on peoples knowledge: a multi-step fuzzy cognitive mapping approach[END_REF]).

Information is continuously interpreted through sensereading processes. During cooperative work, information may be transmitted by speaking, writing, acting, and also through information systems. Knowledge can then be:

• explicited, i.e. it has been made explicit by someone within a certain context, it is socially constructed and can be supported by information technology such as information. Individuals, as well as computers are "information processing systems" ([7], p. 9),

• tacit, it is not always articulated and cannot always be articulated, relying on [START_REF] Polanyi | Personal Knowledge: Towards a Post Critical Philosophy[END_REF] notably: "we can know more than we can tell".

So that explicited knowledge is tacit knowledge that has been made explicit by someone within a certain context. It is information source of tacit knowledge for someone else.

It is "what we know and can tell" answering to [START_REF] Polanyi | Personal Knowledge: Towards a Post Critical Philosophy[END_REF] quoted above. The term explicit knowledge is often used ( [START_REF] Nonaka | The concept of ba: building a foundation for knowledge creation[END_REF] and [START_REF] Nonaka | The knowledge-Creating Company[END_REF], notably), whereas it does not reflect the dynamic of the sense-giving process as well as the term explicited knowledge. Indeed such process is attached to a certain person acting within a certain context. That is the reason why we prefer to use the term explicited knowledge, which clearly shows how every piece of information can be seen as a piece of tacit knowledge that has been made explicit by someone within a certain context. One interprets information and creates a piece of tacit knowledge, which has a meaning for him/her. During cooperative work, there may be someone who has received the same information and, interpreting it, has created a piece of tacit knowledge, which has a meaning for him/her. Such meaning may differ from one person to another, this is meaning variance.

III. OUR APPROACH TO PREDICT MEANING VARIANCE BY MEASURING COOPERATIVE COMPATIBILITY

The idea of measuring cooperative compatibility to predict meaning variance relies on [START_REF] Murakami | Hankoten no keizaigaku[END_REF], where Y. Murakami considers that there exists a "common denominator" of meanings given by several individuals to the same information. We argue that such common denominator may be predicted by measuring cooperative compatibility for a sample of individuals.

The formalism used by our approach is introduced in the first part of this section. The approach and its protocol are then presented in the second part of this section. A discussion on the construct validity of cooperative compatibility is finally proposed in the last part of this section.

A. Introducing a Formalism on Cooperative Compatibility and Meaning Variance

Throughout experimentations within industrial fields, we observed that the predisposition of individuals to give the same meaning to the same information may be related to the expectations they have from each other during a given cooperative work. The idea of our approach is to associate to each person i ∈ N a surface S i , corresponding to his/her expectations Σ i from his/her colleagues during a given cooperative work. For all pairwise distinct persons i, j ∈ N, we denote by Σ i ∩Σ j the value of their cooperative compatibility. The surfaces S i and S j will have a large area of intersection if and only if Σ i ∩ Σ j is high, and this area will be small if and only if Σ i ∩ Σ j is low.

Then for three distinct persons i, j, k ∈ N, the cooperative compatibility of the persons i and j is higher than the cooperative compatibility of the persons i and k (i.e. Σ i ∩ Σ j > Σ i ∩ Σ k ) if and only if the surfaces S i and S j have a larger area of intersection than the one of S i and S k (i.e. S i ∩ S j > S i ∩ S k ), meaning that:

∀i, j, k ∈ N, i = j = k, S i ∩ S j > S i ∩ S k ⇔ Σ i ∩ Σ j > Σ i ∩ Σ k
The order between such areas (S i ∩ S j ) induces an ordering of cooperative compatibilities (Σ i ∩ Σ j ).

We postulate that meaning variance is strongly related to cooperative compatibility: the higher cooperative compatibility is, the lower is meaning variance. This is a strong postulate of our approach, which is currently confronted with industrial fields. For all pairwise distinct persons i, j ∈ N, let ∆µ i,j be the meaning variance between these two persons during a given cooperative work. Our proposition relies on the postulate that for three distinct persons i, j, k ∈ N, the meaning variance between persons i and j is lower than the meaning variance between persons i and k (i.e. ∆µ i,j < ∆µ i,k ) if and only if the cooperative compatibility of the persons i and j is higher than the cooperative compatibility of the persons i and k (i.e.

Σ i ∩ Σ j > Σ i ∩ Σ k ), meaning that: ∀i, j, k ∈ N, i = j = k, Σ i ∩Σ j > Σ i ∩Σ k ⇔ ∆µ i,j < ∆µ i,k
Meaning variance may now be predicted through the measurement of cooperative compatibility. Nevertheless such measurement needs the elaboration of surfaces representing individuals' expectations from each other during a given cooperative work. Let us now present the way of collecting such data.

B. Predicting Meaning Variance by Measuring Cooperative Compatibility

We are now aiming at collecting data on the expectations individuals may have from their colleagues during a given cooperative work. We absolutely banned the use of a formal framework produced a priori and we proposed to give respondents the means to produce their own framework by designing axes they consider relevant in order to characterize their expectations from each other during a given cooperative work. The considered sample of respondents is composed of 10 persons (5♂ and 5♀) with an average age of 30 years. Respondents have the following professional profiles: 3 are computer scientists, 2 are civil engineers, 2 work in the area of marketing, 2 are retired teachers, and 1 works in an hospital. These respondents do not work in the same organization and it is important to notice that the sample of respondents does not evolve between the first form and the second form. Collected data will concern this sample of respondents and will be irrelevant for another sample of respondents. So that in our approach the number of respondents is not as important as the diversity of their profiles. Indeed our approach relies on such diversity to highlight meaning variance by measuring cooperative compatibility.

After having introduced our study, we used a form in HTML in order to collect answers. Every respondent saw the following text: "You are going into a team asked to develop a Web site for a new client. You are an expert in this area and often confronted to colleagues less qualified than you are. From your point of view, what are the qualifications, skills, qualities and / or knowledge that should have your colleagues in order to successfully perform this project with you? Take your time to answer, no more than ten dimensions. When you are ready, click Send."

Then the respondent could see a form with ten open text fields (see Fig. 2) or contact us (we have never been contacted).

First of all we have to notice the ambiguity with which the question is asked: "qualifications, skills, qualities and / or knowledge". The question is quite open and leaded to a set of various and disordered answers, from "kindness" to "Web development (languages, libraries or frameworks)". These answers qualify what the considered sample of respondents could expect from colleagues during the given cooperative work. The answers have been gathered together into equivalence classes in order to design assessment axes. These axes allow to characterize respondents' expectations from their colleagues during the given cooperative work. In the case of our study, we obtained the following axes: The last axis (Self-assessment) has been added in order to weight the answers of each respondent. All the other axes result of a semantic gathering procedure that should be done as closely as possible from the respondents, for example through ethnographic fieldwork as proposed in [START_REF] Jordan | The Design of Computer-Supported Cooperative Work and Groupware Systems, chapter Ethnographic workplace studies and computer supported cooperative work[END_REF] or [START_REF] Greenbaum | Design at Work: Cooperative Design of Computer Systems[END_REF]. We already proposed a procedure closer from the respondents through the use of cognitive maps ( [START_REF] Arduin | On the use of cognitive maps to identify meaning variance[END_REF]), but which did not focus on cooperative compatibility. Indeed, we prefer gathering procedures involving the sense-reading and sense-giving processes of the person who is realizing them than gathering procedures involving information gathering software. The person who is gathering information can be aware of his/her sense-reading and sense-giving processes, contrary to information gathering software that relies on the sense-reading and sense-giving processes of the person who developed it.

The respondents are then invited to answer to a second form where they have to assess themselves on each axis in order to characterize their expectations from their colleagues during the given cooperative work. The axes are presented to the respondents in a mind map (see Fig. 3), so that they can find their answers to the first form and understand the meaning of each axis. The following text introduced the second form: "This is the second part of the experiment. In the first part, you said what you considered important during a given cooperative work. Aggregated, your answers have induced axes covering the expectations of each one. The following mind map represents the different answers gathered into axes. Read carefully the different answers gathered by each axis. Browse the map by trying to find your answers and by understanding the meaning of each axis. Then assess yourself on each axis on a scale from 0 (this axis does not represent me) to 10 (this axis represents me)." An extract of the second form is presented in Fig. 4. With the answers to this form it is possible to produce for each respondent a characterization of the expectations he/she has from his/her colleagues during the given cooperative work. Such characterization may be represented by a surface relying on the scores given by a respondent on each axis (see Fig. 5).

With such representation, it is possible to highlight how much two individuals have common expectations from each other during the given cooperative work. Cooperative compatibility being then higher for individuals with more common expectations. Fig. 6 represents three respondents' expectations and highlights their cooperative compatibilities. One can see in this figure that the cooperative compatibility of respondents 1 and 3 seems to be higher than the cooperative compatibility of respondents 1 and 2, i.e.

Σ 1 ∩ Σ 3 > Σ 1 ∩ Σ 2 .
In other words, meaning variance will be lower between respondents 1 and 3 than between respondents 1 and 2, i.e. ∆µ 1,3 < ∆µ 1,2 .

Nevertheless, this study lacks a measure more than representations. Let us now introduce a way of calculating for two surfaces representing two distinct respondents' expectations from their colleagues during the given cooperative work, the area of their intersection. We consider on each axis the minimal value of respondents' scores on this axis. For a form with n axes, for all pairwise distinct respondents x and y, on each axis i ∈ [[1, n]], x i being the score of the first respondent and y i being the score of the second respondent, we propose a measure of cooperative compatibility defined by:

Σ x ∩ Σ y = n i=1 min(x i , y i ).
For the case of the respondents considered in Fig. 6, table I shows how cooperative compatibility is calculated for respondents 1 and 2. The calculation leads to a cooperative compatibility of 104 for respondents 1 and 2 and of 117 for respondents 1 and 3. So that respondents 1 and 3 have more common expectations from their colleagues during the given cooperative work than respondents 1 and 2. We say that respondents 1 and 3 are more cooperatively compatible than respondents 1 and 2, and we predict that there will be less meaning variance between respondents 1 and 3 than between respondents 1 and 2.

C. Discussing the Construct Validity of Cooperative Compatibility

In this paper, we propose an approach to predict meaning variance by measuring cooperative compatibility. In psychometry, the construct validity of a measure reflects "the degree to which a measurement technique assesses the construct it is meant to assess" ( [START_REF] Kearney | Toward a methodology for the measurement of the knowledge structures of ordinary people: The conceptual content cognitive map (3CM)[END_REF], p. 600). There is high validity when: (1) "the measure performs in accordance with theoretically derived expectations", and (2) "the measure shows the expected relationships with other measures" ( [START_REF] Kearney | Toward a methodology for the measurement of the knowledge structures of ordinary people: The conceptual content cognitive map (3CM)[END_REF], p. 600). Let us now discuss the construct validity of the measure we proposed of cooperative compatibility.

1) The measure performs in accordance with theoretically derived expectations: Theoretically derived expectations aim here at doing cooperative compatibility increase when individuals have more common expectations from their colleagues during a given cooperative work. Inversely, cooperative compatibility will theoretically decrease when individuals have less common expectations from their colleagues during a given cooperative work. The calculation method we proposed defines cooperative compatibility as the sum of the minimum scores obtained by individuals on each axis defined by the first part of the experiment: Σ x ∩ Σ y = n i=1 min(x i , y i ). The min operator ensures that the lowest score on each axis is considered, what means that cooperative compatibility will increase if and only if the lowest score increases. That happens if and only if respondents have more common expectations from their colleagues during a given cooperative work. Inversely, cooperative compatibility will decrease if and only if the lowest score decreases. That happens if and only if respondents have less common expectations from their colleagues during a given cooperative work. So that the measure performs in accordance with theoretically derived expectations.

2) The measure shows the expected relationships with other measures: There are numerous measures with which cooperative compatibility may be compared in order to study if it shows the expected relationships with other measures: affinity, education level, hierarchical level, etc. Such measures are not only numerous, but also ambiguous. For example it is clear that the more affinity there is, the more will be high cooperative compatibility, and inversely. Nevertheless, no empirical study validating or invalidating that has been found in the scientific literature. We are currently studying the behaviour of cooperative compatibility within industrial fields and particularly regarding to other measures such as notably education level and hierarchical level.

Besides the construct validity of cooperative compatibility, this work is now focusing on ways to understand and to demonstrate how much meaning variance is related to cooperative compatibility. This is a strong postulate of the proposed approach that we are currently testing through industrial fieldworks.

Within organizations, in the context of Computer Supported Cooperative Work in Design, the proposed approach ensures that not only (1) information is shared through information technology, but also (2) meaning variance is predicted through the measurement of cooperative compatibility. Predicting meaning variance allows to share more than just information. We are currently studying through industrial fieldworks how to implement our approach in the context of Computer Supported Cooperative Work in Design. We are notably focusing on the ways to give individuals the means, the time, and the wish to answers forms in order to measure their cooperative compatibilities with the aim of predicting meaning variance.

IV. CONCLUSIONS AND FUTURE WORKS

In this paper we presented an approach in order to predict meaning variance between individuals by measuring cooperative compatibility. We began introducing background theories in the area of knowledge management, and particularly on the way different knowledge may be created from the same information. Then we explained and discussed our approach from the interviewing of the respondents to the prediction of meaning variance through the measurement of cooperative compatibility.

A case of cooperative work is given to a sample of respondents. They have to qualify what they expect from their colleagues during the given cooperative work. Their answers are gathered into axes in order to characterize their expectations from their colleagues during the given cooperative work. Then they have to assess themselves on these axes. So that it becomes possible to highlight how much two respondents have common expectations from their colleagues during the given cooperative work. Cooperative compatibility being then higher for respondents with more common expectations.

Relying on knowledge management theories as well as on industrial fieldworks, we argue that the higher cooperative compatibility is, the lower is meaning variance. This is a strong postulate of our work that is discussed in this paper and currently tested within organizations.

Whereas information technology gives individuals the means to share information regardless where they are, cooperative work needs more than just information sharing. Focusing on individuals and on the ways they create knowledge from information leads to understand how much meaning may differ from one person to another. Such understanding allows to imagine how meaning variance may be managed in the future design of Computer Supported Cooperative Work.

Fig. 1 .

 1 Fig. 1. Sharing information is not sharing knowledge, due to the possibility of meaning variance (Meaning 2 may differ from Meaning 1)

Fig. 2 .

 2 Fig. 2. Extract of the first form, maximum ten answers are expected from each respondent

Fig. 3 .

 3 Fig. 3. Extract of the mind map representing the axes and the answers they gather

Fig. 4 .

 4 Fig. 4. Extract of the second form, each respondent have to assess himself/herself on each axis

TABLE I

 I

	.	MEASURING COOPERATIVE COMPATIBILITY
			Resp. 1	Resp. 2	min(xi, yi)
	Writing		8	4	4
	Pedagogy		9	7	7
	Openness		8	8	8
	Computing		8	4	4
	Initiative		7	6	6
	Web Environment	9	4	4
	Creativity		7	6	6
	Autonomy		10	7	7
	Analysis and reflection	8	8	8
	Rigor		8	4	4
	Timesliness		7	6	6
	Patience		7	9	7
	Marketing		2	8	2
	Graphics		3	5	3
	Teamwork		8	8	8
	Curiosity		6	9	6
	Communication	7	9	7
	Self-assessment		7	8	7
		n
	Σx ∩ Σy =	min(xi, yi)		104
		i=1

ACKNOWLEDGMENT

The work presented in this paper has been prepared during the PhD of the author under the direction of Camille Rosenthal-Sabroux and Michel Grundstein. He is grateful to both of them for their support and advice. He would also like to thank the respondents who have accepted to take the time to be interviewed.