Jacqueline Konate

Abd-El-Kader Sahraoui

) G L Kolfschoten

Collaborative Requirements Elicitation: a Process-Centred Approach

Keywords: Requirements Engineering, Collaboration Engineering, Product Development, Standard EIA-632

Requirements Engineering is one of the first and most critical processes in system engineering. In this paper we will focus on the collaborative aspects of requirement engineering, in the context of product development. To do so, we adopted the separation of concerns method. Using this method we separate engineering aspects from collaboration aspects in order to study both aspects and finally integrate them. For the collaborative aspect of requirements engineering we looked at Collaboration Engineering. Collaboration Engineering is an approach to design and deploy processes for recurring collaborative tasks that can be transferred to practitioners to execute for themselves without intervention of professional facilitators. From an engineering perspective we will use the requirements engineering processes described by system engineering standard EIA-632 as a starting point. To integrate these we will use methods and techniques from Collaboration Engineering to specify the collaborative processes involved in this requirements engineering approach. An object model was build using Unified Modelling Language (UML). This model shows different concepts underlying our approach. Finally two case studies are presented to evaluate this approach.

1 Introduction : The success of a system development project depends on the successful identification of the needs that a system must satisfy. Several years ago, systems were often developed according to the visions of engineers and designers without the involvement of users and other stakeholders. This caused the abandonment of many systems that were technologically sound, but have been considered as failed systems, because they did not meet the needs of users. In recent years, system design has been more successful, as engineers realized that customers and end-users must play a central role in the system development process and especially in the process of defining the envisioned functionalities of the system. To establish a sound set of requirements, many things have to be taken into account such as: the problem or the user needs, budget, resources and even political aspects [START_REF] Boehm | Developing Groupware for Requirements Negotiation: Lessons Learned[END_REF]. Taking into account all these issues requires the involvement of several skills and therefore the involvement of multiple participants. Thus, collaboration is essential to ensure efficient and effective involvement of all relevant stakeholders. Increasingly, information systems offer support to multiple users that collaborate to create products and make decisions. The current economic context encourages organizations to consider fusion-acquisitions and to externalize activities. Consequently, organizations are forced to improve the communication and interaction with their customers, their partners, their suppliers, their subsidiary companies, etc. to produce better products or services faster and at lower cost [START_REF] Monford | Web Services et Interopérabilité des SI[END_REF]. Furthermore, organizations increasingly rely on collaborative teams to perform recurrent and collaborative tasks. However, when collaboration exceeds a limited context and when it relates to projects of considerable size, it poses significant challenges [START_REF] Nunamaker | Lessons from a Dozen Years of Group Support Systems Research: A Discussion of Lab and Field Findings[END_REF]. To overcome these challenges it is important to structure and organize collaboration in order to reap the benefits of collaboration in an effective way. Collaboration has an important human and social dimension making it difficult to design and predict the effect of interventions to support collaboration.

Requirements engineering is considered as a reconciliation approach of social and technical issues (Goguen, 1994). Tools can be masterpieces from a technical viewpoint; however, this does not guarantee that the system supports collaborative interaction and productivity of its users. It is therefore important to define processes to support (collaborative) tasks of stakeholders and users of the system. Given these challenges, this paper proposes an approach to address collaborative requirements engineering for product development. To do this, we adopted an enhanced separation of concerns approach, i.e., we separate engineering aspects from collaboration aspects. We firstly consider the engineering process based on a system engineering standard EIA-632 (EIA-632, 1999) secondly, we defined a collaboration process for requirement engineering using the Collaboration Engineering approach. Collaboration Engineering is an evolving research area which aims to design and to deploy processes for recurring collaborative tasks. In Collaboration Engineering collaboration processes are designed by collaboration experts and transferred to practitioners in the organisation, so they can execute these processes without the intervention of professional facilitators. From engineering perspective we propose that it is possible to define collaboration processes that are predictable, reusable and transferable to novice or practitioners [START_REF] Briggs | Collaboration Engineering with ThinkLets to Pursue Sustained Success with Group Support Systems[END_REF][START_REF] Vreede | Collaboration Engineering: Designing Repeatable Processes for High-Value Collaborative Tasks[END_REF]. The multidisciplinary character of requirements engineering justifies the need for a collaborative approach, as the development of complex products requires effective and efficient collaboration between various experts.

The remainder of this document is organized as follows: Section 2 presents a background on systems engineering, especially requirements engineering, collaboration issues and collaboration engineering. Section 3 is devoted to explain our approach. Section 4 shows a conceptual model of our approach. Section 5 gives an example to illustrate our approach. Section 6 presents the case study, the results, analysis, discussions and our prototype for specification. Finally, conclusions and suggestions for future research are outlined in section 7. The appendix contains descriptions and definitions of key terms.

Background

In this section we present the context and basis of our work in two parts: Requirements Engineering and Collaboration Engineering.

Requirements engineering in a system engineering framework

In this part, we present Requirement Engineering (RE) as a process which is a sub process of System Engineering. Many approaches exist for design and systems engineering. We used the System Engineering Standard EIA-632 as a starting point for our research.

Requirements Engineering

According to standard EIA-632, a requirement can be defined as "something that governs what, how well, and under what conditions a product will achieve a given purpose" (EIA-632, 1999). The IEEE defines a requirement as "a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents" (IEEE, 1990). In others words, a requirement is simply something that the system must do, must satisfy, or that is determined by someone concerned with the development of that system. Thus, Requirement Engineering is concerned with understanding what a system must do, whereas the 'design' is concerned with how the system should do this. RE is defined as "the activities that cover discovering, analyzing, documenting and maintaining a set of requirements for a system" (Sommerville, Sawyer, 1997). It is very important to note that a RE process is not only a process of collecting facts, but that it encompasses all the project lifecycle activities associated with understanding the necessary capabilities and attributes of any given system [START_REF] Wiegers | Process Impact[END_REF]. In RE we specifically distinguish between a need and a requirement. Needs are perceptions of the system from the client, end-users and other stakeholders, whereas requirements represent perceptions of the system from the project manager, analyst and designer. Consequently, a key challenge is to translate needs into requirements. Such translation can cause misunderstandings and misinterpretation, leading to false requirements. As shown in (a) in figure 1, the RE process consists in identifying needs from clients, users and other stakeholders and transforming them into technical requirements for a system.

Figure 1: Requirements engineering process. [START_REF] Essame | La méthode B et l'ingénierie système[END_REF][START_REF] Kotonya | Requirements Engineering: Processes and Techniques[END_REF][START_REF] Coulin | A Situational Approach and Intelligent Tool for Collaborative Requirements Elicitation[END_REF]. Requirements engineering does not only concern collecting needs, but rather it covers the lifecycle of the system as shown in (b) in the figure 1. According to [START_REF] Kotonya | Requirements Engineering: Processes and Techniques[END_REF][START_REF] Coulin | A Situational Approach and Intelligent Tool for Collaborative Requirements Elicitation[END_REF], the essential phases of requirements engineering are Elicitation, Analysis, Specification, Validation and Management. In the requirements elicitation phase, the purpose is to collect, capture, discover, and develop the requirements from a variety of sources including human stakeholders. In the analysis phase, the purpose is examining, understanding and modelling the elicited requirements, and evaluating them on quality in terms of correctness, completeness, clarity, and consistency. Further, requirements have consequences in terms of costs, resources, and possibly they might conflict with other requirements. Such consequences can lead to the judgement that some needs are more or less important, and that some needs should be abandoned. This requires negotiation about requirements among designers and analysis, and possibly among stakeholders, clients and users [START_REF] Boehm | Software Requirements as Negotiated Win Conditions[END_REF]. In the specification step, we record and document the requirements in such a way that they can be used by stakeholders and especially developers who will design and construct the system. In the requirements validation phase the quality of the requirements needs to be confirmed, to ensure that they actually represent the needs of the stakeholders, and that no translation errors from needs to requirements have been made. Requirements are managed throughout the RE process. Managing requirements includes activities such as change control and requirements traceability. RE is one of the most important branches of research in the System Engineering (SE) field [START_REF] Sahraoui | Systems Engineering Reasearch[END_REF]. For the purpose of our study, we chose the standard EIA-632 (EIA-632, 1999) for requirements engineering that is presented in the next subsection. 2.1.2 The standard EIA-632 Because of the increasing complexity of systems, rigor of design approaches has changed accordingly over the years. Systems engineering approaches propose a set of rules and processes according to which systems must be developed. Thus, several standards of system engineering evolved to cover different phases of a systems lifecycle. In this paper we focused on the EIA-632 (EIA-632, 1999) standard, which we used as a starting point for our design approach (see Figure 2). This standard comprises thirteen processes, which cover different phases of the product life cycle. Since some stages of this life cycle are beyond the scope of our research, we focus only on the product realization processes and the technical evaluation processes. Systems engineering is based on an iterative process that starts with (1) understanding a problem, then (2) examining alternative solutions, and finally (3) verifying that the selected solution is correct before continuing to the definition of activities or proceeding to the next problem. Each process is a succession of activities involving three types of participants: the developer who is for example requirements engineer, the end-user who represents people for whom the system is constructed and other the stakeholders with respect to the system. -632, 1999) In the above engineering processes, there is a sequence of system engineering tasks that prescribe the required activities at each stage of product development. For example, at the system design step it is necessary to define the requirements and to define the solution. To accomplish these tasks, actors must collaborate. Indeed, figure 2 shows that there is interaction between processes indicated by the different arrows. However, the activities in the lifecycle prescribe only tasks, and do not explain how these tasks should be performed collaboratively, and how different perspectives should be integrated to create the required products for these different phases of the lifecycle. Studies revealed that engineers collaborate during about 74% of the time devoted to product development (PTC, 2007) as depicted by figure 3, and yet information on how they collaborate is very limited. According to a study by [START_REF] Frost | Meetings around the world: The impact of collaboration on business performance[END_REF] more than 36% of the performance of an enterprise depends the organization's capacities to collaborate. This represents more than twice its strategic orientation impact, and more than five times the impact of market influences and technological turbulences. Collaboration increasingly occupies a considerable part in products development; and consequently, improving collaboration is becoming an important factor in productivity.

In light of these observations, this article proposes a method for collaborative requirements elicitation, which distinguishes collaborative aspects from engineering aspects. This distinction aims to help in structuring and organizing collaborative aspects of requirements elicitation to increase the effectiveness of these collaborative task elements. For this purpose, we present a case study on requirements elicitation. Requirements elicitation is considered the most critical and collaborative sub-process of systems engineering according to the EIA-632 standard. We rely on the Collaboration Engineering approach to define a collaboration process that we present in the following subsection.

Collaboration and collaboration engineering

We approached collaboration issues through a general vision and perspective of Collaboration Engineering which is a new approach to structure and design collaborative work practices.

Collaboration in general

In literature, the terms collaboration, coordination and cooperation are used interchangeably. In some cases the difference between cooperation and collaboration is not made explicit, which leads to confusion. Cooperation is the process of reasoning and/or pooling of knowledge in the context of problem solving (Soubie et al., 1996). De Terssac and Maggi state that cooperation is a mean to overpass individual limitations [START_REF] Terssac (de) G | Autonomie et conception[END_REF]. Others definitions of cooperation can be found in (Schmidt, Bannon, 1992), [START_REF] Soubie | Modelling in Cooperative knowledge based systems[END_REF]. According to Rebetez [START_REF] Rebetez | Concepts de base[END_REF] participants in a cooperation process divide the workload between them; each of them has a part to accomplish. The final result is the combination of all individual parts, each participant being responsible for his own work. However, every participant has to interact with the other participants to assure the coherence of the final result. Coordination is described as all rules of action to structure and harmonize cooperation. Thus, coordination is part of a cooperation activity [START_REF] Maggi | Coopération et coordination dans et pour l'ergonomie: quelques repères[END_REF]. Collaboration is joint effort toward a common goal [START_REF] Briggs | Collaboration Engineering with ThinkLets to Pursue Sustained Success with Group Support Systems[END_REF]. It is also seen by [START_REF] Gray | Collaborating: Finding common ground for multiparty problems[END_REF] as a process in which stakeholders with different perspectives of a problem, can constructively explore the differences and can search for solutions that go beyond their own limited visions. Unlike cooperation, in a collaborative context all participants co-construct together even if the task can be divided in several other subtasks. In collaboration, all participants intervene in each step so that it is not possible to distinguish individual work in the final result [START_REF] Rebetez | Concepts de base[END_REF]. Unlike cooperation, collaboration is often done synchronously even if it is possible in asynchronous way [START_REF] Potin | Travail Collaboratif: Quand la distance permet le rapprochement[END_REF] to create synergy and benefit most from interaction. Communication or interaction is an essential component in cooperation, collaboration and coordination. However, communication is different from the other terms because it does not necessarily have an objective and it can be used as a means to cooperate, collaborate and coordinate.

Through the above definitions we can notice that collaboration is a complex task because it is more difficult to co-construct than to emit or receive information (communication) and more difficult than to assemble information by gathering and coordinating work of individuals (cooperation and coordination).

To overcome challenges of collaboration, one can use group support systems (GSS). Research has shown that under certain circumstances teams using GSS can be more productive than teams which do not use it [START_REF] Fjermestad | A Descriptive Evaluation of Group Support Systems Case and Field Studies[END_REF]. According to [START_REF] Hengst | Assessing the quality of collaborative processes[END_REF], it is important that the explicit design and management of collaboration processes is integrated with the development and deployment of collaboration technologies in order to support these collaboration processes. For this, an approach called Collaboration Engineering is advancing (see next subsection).

Collaboration Engineering

Collaboration Engineering aims to design and deploy processes for high value recurring collaborative tasks. Its purpose is also to design these processes so that practitioners can execute them, successfully without the intervention of professional facilitators [START_REF] Briggs | Collaboration Engineering with ThinkLets to Pursue Sustained Success with Group Support Systems[END_REF][START_REF] Vreede | Collaboration Engineering: Designing Repeatable Processes for High-Value Collaborative Tasks[END_REF]. There are three key roles in Collaboration Engineering, which are the role of facilitator, practitioner and collaboration engineer. A facilitator is a professional in collaboration support, who designs and conducts collaboration processes in order to support a specific group in achieving its specific goals [START_REF] Briggs | Defining Key Concepts for Collaboration Engineering[END_REF]. A collaboration engineer designs and documents collaborative work practices and deploys them in organisations for practitioners to use. So, a process designed by a collaboration engineer has to be transferable and reusable to enable practitioners to execute it independently [START_REF] Kolfschoten | A conceptual foundation of the thinkLet concept for Collaboration Engineering[END_REF]. A practitioner is a domain expert who learns to execute a particular work practice based on a design made by a collaboration engineer [START_REF] Briggs | Defining Key Concepts for Collaboration Engineering[END_REF]. Practitioners do not design collaborative processes, they only execute them. This reduces the skills required, as they focus on part of the facilitation task, and apply these skills only in the context of one specific collaboration process. Processes are built up as a sequence of facilitation interventions that create patterns of collaboration and predictable group behaviour with respect to a common goal. There are six basic patterns of collaboration according to which processes are organized [START_REF] Briggs | Defining Key Concepts for Collaboration Engineering[END_REF]:

 "Generate" allows the move from having few to having more concepts,  "Clarify" allows moving from having less to having more shared meaning of the concepts under consideration,  "Reduce" is the opposite of the Generate pattern,  "Organize" is moving from having less to having more understanding of the relationships among the concepts,  "Evaluate" is to move from having less to having more understanding of the utility of the concepts priority with respect to goal attainment.,  "Build Consensus" is to move from having more to having less disagreement on the course of action.

The fundamental building block in Collaboration Engineering is the thinkLet. A thinkLet is defined as "the smallest unit of intellectual capital to create a pattern of collaboration" [START_REF] Briggs | Collaboration Engineering with ThinkLets to Pursue Sustained Success with Group Support Systems[END_REF]. ThinkLets are design patterns and as such have advantages such as transferability, predictability and its use as a shared language among designers and users alike. Section 3 presents the approach we proposed for collaborative system engineering.

3 An approach: Collaborative System Engineering

Introduction

Initially, we consider engineering and collaboration aspects as merged; this is illustrated by situation (a) in figure 4. In order to organize and structure collaborative work, we distinguish the engineering processes from the collaboration processes as presented in situation (b). However, the collaboration processes depend on engineering tasks, i.e., engineering processes. This leads to the integration state (c) where engineering processes are designed as collaborative processes. We carried out the separation of concerns approach by considering collaboration and engineering as disjoint, to later integrate these two perspectives. The engineering processes we consider are already known and standardized, as the EIA-632 standard. Therefore we will not further define them; we consider them known (EIA-632 1999). However, the collaborative processes associated to this standard have to be identified and defined. We rely on the Collaboration Engineering approach for defining collaboration processes within the EIA-632 standard. This leads us to focus on collaborative engineering tasks. The envisioned collaboration process should fit the standards of systems engineering, because Collaboration Engineering offers reusable, predictable and transferable collaboration processes based on the thinkLet concept. In the next section we propose a model for collaborative engineering, based on the separation of concerns approach described above.

Collaboration Model

Our vision of collaboration can be summarized as the following formal notation. Here, collaboration is defined as a function: Collaboration: (PROCE x PROCC, CON) -> RESULT Where: PROCE represents a subset of engineering processes which is essentially included in PROCEIA-632, PROCEIA-632 represents the processes of standard EIA-632, PROCC is a subset of collaboration processes to be defined, CON is the set of constraints for the collaboration process, RESULT is a set of results from collaboration. This definition forms the basis of our approach; indeed, we see collaboration in the area of engineering as a function that uses conditioned engineering and collaboration processes, which describes the different interactions between participants and the data flow. In this context, PROCE is one of the EIA-632 engineering processes.

RESULT represents the outcome of the collaboration process. According to the context, it changes. For example, it can be a decision in a collaborative decision making context. In a Requirement Engineering context, RESULT is a product requirement specification, documented in a specifications book. Rules that enable efficient collaboration are defined based on constraints on the behavior of the participants, organizations and activities. CON and PROCC are the unknowns in the definition above. The following subsections are devoted to determining them.

Collaboration Constraints: CON

Like any process, collaboration processes are subject to constraints for the actors, activities and resources used. For example, constraints to the actors involved are: availability, competencies, and confidentiality. Collaboration activities depend on the requirements engineering activities structuration and the constraints relating to collaboration processes. The number of constraints can increase exponentially, and therefore it is important to make a conscious choice of the constraints that we wish to consider when designing collaboration processes. This choice has to be made to balance the tradeoff between the collaborative goal on one side and the individual stakes of the participants on the other side. This balance needs to be established to ensure that the collaboration process demands an acceptable contribution and sacrifice on the part of the participants, while remaining instrumental to the collaborative goal [START_REF] Kolfschoten | A Design Approach for Collaboration Processes: A Multi-Method Design Science Study in Collaboration Engineering[END_REF].

In short, we can identify three types of constraints: (1) Actor constraints, these are related to the participants of the collaboration process, their competencies, and their role in the process; (2) Task constraints, these are related to activities performed during process execution and the structuration of the process (see section 3.4.2); and (3) Resource constraints, these are related to the capabilities used during process execution, such as the functionalities of technologies used. While task constraints are encapsulated in structure of the collaboration process activities, Actor and Resource constraints are expressed through sentences written down in a document. This document is made by collaboration engineer during both stakeholder identification phase and process design phase. This document can be integrated in collaboration process documentation.

The constraints to a collaboration process are formulated as collaboration rules, specifying a condition for which a role needs to perform an activity with a specific capability (Kolfschoten et al 2006). A proper definition of collaboration constraints is essential because it is the basis of a well-defined collaboration processes and it allows specification of assumptions for these processes. Depending on the situations, specificities of each situation have to be taken into account in constraints definition.

Collaboration Processes: PROCc

We define a collaboration process in two parts. First, we define interaction flow between actors in collaboration processes and secondly we establish structure of activities.

Interactions

From the preceding description, we can deduce the following model which can be used as a collaboration model for the standard EIA-632. As is described in section 2, this standard distinguishes between three types of actors: the developer, the acquirer and the other stakeholders of the system. For the collaboration process, we use the same set of actors. An actor can represent an individual or a team. Figure 6 summarizes our collaboration model. It is the same logic as classical Input-Process-Output model, and is represented by a graphic, outlining all concepts used in our model. In this model the participants collaborate on a list of tasks.

The dotted box represents a collaboration process whit input and output; the collaboration process is subjected to three types of constraints defined in section 3.3. This model is applied to requirements engineering using UML (Rocques, Vallée, 2006) in section 5. This part is focused on the constraints for activities. The interactions and the sequence of activities are in the center of a collaboration model. In our approach, the structuration of a collaboration process is not identical to that of an engineering process. However, they are interdependent. The structuration of the process defines the order of execution for the activities.

The thinkLet language allows expressing this order in a facilitation process model as shown in figure 6. This example is from a quick session on requirements elicitation. The session starts with a set of needs. This session continues with other activities supported by thinkLets named 'FreeBrainstorm' (used to elicit needs), 'PopcorSort' (used to categorize needs to functional aspects) and 'BucketWalk' (used for verification) (Briggs et al., 2001). Categories used in the second step have been defined before the collaboration process in the design phase.

When the number of generated ideas is not high, it is not necessary to use a reduction thinkLet before the evaluation. In such case, each category contains a small number of ideas which can be evaluated using a thinkLet like BucketWalk. When the brainstorming step produces a large number of ideas, a reduction step is necessary before any evaluation activity.

Above thinkLets are specific techniques to instantiate the generic patterns 'Generate', 'Organize' and 'Evaluate'. To allow users to remember thinkLets their names are catchy. However, whatever their denomination is, they are a variation of one of the six patterns of collaboration mentioned in subsection 2.2.2.

i )) = Comp(thinkLet(task i )) = Comp(thinkLet i ) if P e = Comp(task i ), i є [1, N]} {thinkLet(Seq(task i )) = Seq(thinkLet(task i )) = Seq(thinkLet i ) if P e = Seq(task i ), i є [1, N]}
{C is consigned in thinkLet script (see appendix section)} From above formulation, we can consider that for an engineering process P e , a collaboration process P c , and a set of constraints C, the collaboration is made by the collaboration pattern, the thinkLet, which is also considered as a particular function that can be used to create compound patterns or sequential patterns. Indeed, collaboration patterns can be combined (Kolschoten el al., 2004). This definition of collaboration requires an analysis of tasks in an engineering process (P e ) and their complexity in order to determine elementary and composite collaborative tasks. When these tasks are identified, collaboration process (P c ) is designed with thinkLets. When designing collaboration patterns for P e , the thinkLets library is used to select existing thinkLets which are suitable to the engineering process. New thinkLets can be created if there is no existing thinkLet fitting to the situation or when other thinkLets would be more suitable than those already existing (see section appendix section). In order to link all concepts discussed above, we propose a conceptual model which is described below.

A conceptual model

As mentioned previously, we distinguish between two kinds of processes: Engineering Processes and Collaboration Processes. The engineering processes are defined by a standard; therefore we do not redefine them. The collaboration processes have to be defined with the use of Collaboration Engineering. For this purpose, thinkLets are a fundamental concept in our model. A major conceptualization of thinkLets, based on an object oriented approach is presented by [START_REF] Kolfschoten | A conceptual foundation of the thinkLet concept for Collaboration Engineering[END_REF], which we used for our model. The model in Figure 7 formalizes the phase of Engineering and Collaboration processes integration phase as previously presented in figure 4, page 7. It does so by mapping tasks and thinkLets according to the model proposed in section 3. In other words, a ThinkLet has to allow collaborative execution of a Task. Indeed, a ThinkLet encapsulates the information describing how to collaboratively perform a Task. This description is part of ThinkLet components and it is called a Script in Collaboration Engineering terminology (see appendix section). Since a ThinkLet is a design pattern, it can be adapted to the context by changing the script, while maintaining the fundamental principles of the collaborative technique. It is also possible to propose a new ThinkLet if no existing ThinkLet is suitable to the current situation. Figure 7 is the conceptualisation of the different components of the collaborative requirements elicitation process. This model offers a clear overview of the concepts involved and their interaction. As previously mentioned, we have chosen Requirements Engineering as the context for our experiment. In section 5 we present the experiment and describe the different processes involved. We also present an UML interaction diagram to describe the experiment.

5 Toward a Collaborative Working Environment for Requirements Engineering (SEC-WE)

Modelling Collaborative Actors

Here, we illustrate our approach to the requirements definition processes (EIA-632, 1999), [START_REF] Coulin | A Situational Approach and Intelligent Tool for Collaborative Requirements Elicitation[END_REF]. Figure 8 describes process P: 'Collaboration process for requirements engineering' with four sub-processes P1, P2, P3, P4. These sub-processes represent 'Collaboration process for identification and collection of needs' for example Brainstorming [START_REF] Osborn | [END_REF] and Storytelling [START_REF] Acosta | Supporting the Collaborative Collection of User's Requirements[END_REF], 'Collaboration process for needs transformation into technical requirements' for example the specification template named Volere (Robinson, 2007), 'Collaboration process for requirements validation' and 'Collaboration process to record requirements' (EIA-632, 1999) respectively. The recording process starts with writing down the specified requirements on paper or using an automated tool like [START_REF] Truereq | [END_REF]. The involvement of actors in this process is indicated by an arrow from the actor directed towards the tasks of the process. The arrows directed downwards symbolize the data flow (input and output). In particular, input is needed from the acquirers' team (AT) and the other stakeholder team (OST). The needs are identified and collected in collaboration with the requirements definition team (RET). A set of needs resulting from the first process (P1) is used as input for the second process (P2). In this process the needs are transformed into technical requirements. In the third process (P3), the technical requirements are validated by all actors. Finally the requirements are recorded by the requirements definition team (P4). The output of the process P is a specifications book. We use the formal modelling language UML to model the process (P). We show interactions between the participants and we show data exchanges.

Interaction Model with UML

Figure 9a shows the actors and the activities they must execute in the requirements engineering process. In figure 9b we present an interaction diagram to describe how actors interact in the collaborative requirements definition process. Like a use case diagram, an interaction diagram is a high level representation of the requirements engineering process, hiding more detailed interactions. In Collaboration Engineering terminology, AT, OST and RET are participants of a collaboration process. One of the participants of the RET can be a practitioner and execute the requirements elicitation process (P1 in figure 8) designed by a collaboration engineer; an expert in collaboration support. We will describe this process in section 6. As mentioned previously, we mainly focus on the elicitation phase of the Requirements Engineering process. We will present the case study on the elicitation process and its results in the following subsections.

Requirements elicitation process

In the Requirements elicitation process, we identify two main phases; the preparation phase and the needs identification phase. This is shown in figure 10. These phases are described in following subsections.

Preparation phase

Requirements Elicitation starts with a preparation phase. In this phase it is important to involve the relevant stakeholders in the requirements elicitation process. We can identify a Start step in which participants introduce themselves. In this step first informal social contacts are established and participants explain their role and their expectations of the activity. Den [START_REF] Hengst | Designing Mobile Information Services: User Requirements Elicitation with GSS Design and Application of a Repeatable Process[END_REF]) name this step Warm-up. Next, we have to choose/focus on boundaries for the scope of the requirements elicitation effort. This scope describes the environment in which the target system will be used, including all related domains. This step is very important in the elicitation process because the following activities depend on how the boundaries are chosen [START_REF] Nuseibeh | Requirements Engineering: A Roadmap[END_REF]. The step identify stakeholders consists of identifying stakeholders to represent different aspects of the system requirements within the boundaries determined in the previous step. Finally the preparation phase requires analysis of the domain and organization(s) related to the system in order to gain a basic understanding and common ground [START_REF] Machado | Supporting the System Requirements Elicitation through Collaborative Observations[END_REF].

Identify needs phase

Once the preparation phase is completed, the specific stakeholders and the boundaries of the concerned domain are identified. The next step consists of selecting the methods and techniques to collect, capture and gather the needs from the different stakeholders. Figure 1 shows a nonexhaustive list of methods and techniques to support the need identification step. Among them are Dialogue [START_REF] Hoa | Goal Management for a Multisession Dialogue[END_REF], Group Storytelling [START_REF] Acosta | Supporting the Collaborative Collection of User's Requirements[END_REF] and Brainstorming [START_REF] Osborn | [END_REF] which are all collaborative approaches that can be used to brainstorm needs. The choice of methods and techniques depends on the time and resources available, and depends on the kind of information to be elicited [START_REF] Nuseibeh | Requirements Engineering: A Roadmap[END_REF]. In addition, every technique has some limitations [START_REF] Goguen | Techniques for Requirements Elicitation[END_REF]. A combination of these techniques might therefore help the group to approach the identification from different perspectives and to trigger different creativity and thinking patterns [START_REF] Knoll | Changing the Perspective: Improving Generate thinkLets for Ideation[END_REF] In the following section, we present the requirements elicitation case study we did to evaluate our approach.

Case study and prototype

We performed a case study with two groups of students in order to evaluate and compare a couple of need elicitation methods from literature. The first group consisted of 44 students, the second group of 14 students.

Approach

According to the conceptual model we presented in section 4, we first considered the engineering process which is an elicitation process in this case. Then, we selected some existing collaborative methods for the requirements elicitation process. In our workshops we chose Storytelling [START_REF] Acosta | Supporting the Collaborative Collection of User's Requirements[END_REF], and Dialogue [START_REF] Hoa | Goal Management for a Multisession Dialogue[END_REF], which we conceptualized as thinkLets and the existing thinkLets FreeBrainstorm and LeafHopper (Briggs and Vreede, 2001). We propose two new thinkLets to support these two methods which are named after the method they support (story telling & dialogue). The new thinkLets are presented in detail in the appendix. Although all these methods allow for the elicitation of needs, the specific tasks performed vary per method. Once the thinkLets are identified, we design a collaborative process to support collaborative need elicitation. Figure 11 shows the collaborative processes designed by a Collaboration Engineer for both sessions. The order in which the thinkLets were placed was deliberate. In brainstorming literature it is described that people will first share those ideas that are on the top of their mind. Later, they will benefit from stimuli that motivate them to think about new ideas [START_REF] Santanen | Causal Relationships in Creative Problem Solving: Comparing Facilitation interventions for Ideation[END_REF].

We used ThinkTank (GroupSystems, 2006) developed by GroupSystems as a collaboration tool to support joint need elicitation. ThinkTank is a web-based tool supporting the main activities of a collaboration process. It allows users to brainstorm, vote, organize and revise ideas in a collaborative mode. ThinkTank also provides functionality to capture and store a full electronic meeting record.

Both sessions were on need elicitation for the design of an Electronic Medical Record (EMR) system. Start: the facilitator started the session by introducing herself and by explaining the purpose of the session. The session was anonymous, i.e., each participant could connect to the GSS and contribute under a fictive ID. This allowed the participants to be free in expressing their ideas. FreeBrainstorm: in this stage, participants elicited needs, and responded, reflected or elaborated on needs proposed by others. During about 15 minutes, participants produced ideas related to system requirements. The facilitator often had to intervene to further motivate and challenge the participants in expressing their ideas. The facilitator removed ideas which did not contribute to need elicitation, like "It is true" and "I agree". At the end of this step, we had a list of system requirements to which all participants had contributed. StoryTelling: in this step, participant has to write a short story or experience to explain the problem that is to be addressed using system, and to elaborate on the stories from others. The facilitator asked the participants to think from the perspective of a stakeholder by telling a story of what happened, asking them to come up with a use case from that stakeholder's perspective. In other words, they had to tell a story from a specific perspective on what the system should do, and what kind of problems / challenges this stakeholder could encounter when interacting with the system. Then, the facilitator asked them to read the stories from other participants and to try to elaborate on them. After 15 minutes of story telling, the facilitator asked them to summarize the stories in terms of needs only. In the summary, the needs described in the stories were extracted. Dialogue: in this step, a role is assigned to a participant. In this role participants are asked to engage in a question-answer dialogue. Participants asked questions and answered questions from the perspective of their particular role. The facilitator asked the participants to exchange needs from different stakeholder perspectives. This step lasted for about 10 minutes; based on the resulting dialogues the summary of needs was updated again. LeafHopper: in this step, participant has to elicit needs based on different functions of the system. People contributed needs based on functional categories related to the system (an Electronic Medical Record) such as e.g. enclosure of medical knowledge, collecting data for performance management, automating financial aspects, etc.). About 8 minutes later, when the facilitator noticed that the participants were not contributing new needs any more she asked them to stop this step. Summary: After each step, requirements were added to a summary in which the requirements were collected. This summary was made initially by the facilitator, and later participants added needs to the summary. The Dialogue, StoryTelling and LeafHopper were used to help the group to get inspiration for new ideas. However, these steps did not lead to concise needs. Therefore, needs were elicited based on the brainstorm and added to the summary. The method for this was rather ad-hoc and needs refinement to be captured as a thinkLet, it had elements of both expert choice and fast focus. Once all different methods had been used, the facilitator asked the participants to summarize all needs and to check the resulting set of needs for completeness. Subsequently, the participants answered questions which aimed to further confirm the completeness of the needs. In order to get more complete requirements, the facilitator tried to motivate the participants to elaborate. Some quotes used for motivation are: "are security aspects covered in the needs?", "are technical aspects covered in the needs?". This plenary group discussion lasted for approximately twenty minutes. StrawPoll: The participants had to select the ten most important needs. To do so, the StrawPoll thinkLet was used, supported by the voting functionality of the GSS. This produced a list of needs, ordered according to participant perception of importance. Finally, the participants selected a sub set of about 10 key needs which mostly correspond to the top needs on the list. In our case study, subsequent steps to refine needs to requirements and to further validate the resulting set of requirements and build consensus around them were not performed. These would be important further steps, and a collaboration process needs to be developed for these steps. Both sessions were executed in the way described above. There were some differences in step duration between the two sessions. The reason for this was the difference in group size. The first group had more participants than the second group. The steps of the first group took more time because there were more contributions and more discussion.

After the sessions, the students who participated filled out our questionnaires for qualitative and quantitative evaluation of the methods used. In the next subsection we present the results of these evaluations.

Results

Comparing the requirement elicitation methods

Table 1 presents the results of the questionnaire from the participants of the first and second workshops. In the first session 20 requirements were summarized, in the second session 21 requirements were summarized. 44 students participated in the first workshop, and from them we collected 34 usable questionnaires. In the second workshop 14 students participated, and from them we collected 10 usable questionnaires. So, we had 44 usable questionnaires from both first and second sessions. The respondents were students in a master program on System Engineering, Policy Analysis and Management. They had a moderate knowledge of Requirements Engineering methods and techniques. Therefore, there was value in asking these students about the quality, completeness, etc. of requirements. In addition, the evaluation aimed to compare methods. Responses were not absolute, but they present interesting first insights.

Concluding we find that students evaluated FreeBrainstorm and LeafHopper as more practical, but when regarding, rigor and completeness, participants recognized added value from the more elaborate methods; Dialogue and StoryTelling. All thinkLets scored high on ease of use. For clarity of the method FreeBrainstorm (5,55) and LeafHopper (4,98) scored higher. For efficiency and helpfulness of the method as well (FreeBrainstorm (5,00,5,11) and LeafHopper (4,89,5,23)).

In terms of usefulness and quality of the resulting requirements, LeafHopper scored highest, (5,23 and 4,98) this could be partly because it was the last thinkLet, but the effect of that could also have been that participants were "empty" and had no more additional requirements. The high score for usefulness and quality could also have been because the thinkLet asked for more specific requirements, focussing the group on functional aspects of the design. For completeness and rigour, high scores were also found for LeafHopper (4,82,4,98), but in these questions Dialogue (4,41,4,36) and StoryTelling (4,27, 4,5) also scored higher, indicating that participants valued these more elaborate methods to ensure a full exploration of the needs from different stakeholder perspectives.

Limitations of this case study are the following:

 Students participated in the study, while they did use the requirements for a future assignment and thus had a stake in their quality, a field study would be better to assess the usefulness and quality of the requirements  We had no objective evaluation of the quality of the requirements. The case was based on a real case, but never the less had a fictive element. Therefore real assessment of the quality of requirements was not possible.

 The order of the thinkLets was fixed, a different sequence might have had different effects.

 ThinkLets were evaluated after the entire process, this allows comparison on one hand, but also could have caused less accurate evaluation, especially for the earlier thinkLets.

Requirements specification prototype

To support the subsequent processes (processes P2, P3 and P4, see figure 8), we need a more specific tool, which supports the transformation of needs to requirements, their organization in a specification book and their verification. For this purpose we developed SPECJ. SPECJ is a web based tool for collaborative requirements specification. The figure 12 shows its architecture which is based on MVC2 (Model, View and Controller). The Model represents entities used by an application, these entities are collected in a database. The View represents the interface of the application. The Controller is the component of application which replies to input from user, i.e., the Controller translates the events from View to modifications of Model, and then defines the way the View has to react to these events. The main functionalities offered are: create, delete and update specification, look for specifications based on criteria (category, description, priority and rational), check the specifications list and their categories, check the list of all registered users (who opened an account), check the list of logged in users, check and display the specifications book, etc. The figure 13 shows the SPECJ interface with three active users specifying requirements for their category, description, rational and priority. Figure 14 presents an example of a specification book made with SPECJ. Figure 15 shows the categories of the specifications book with their subcategories and descriptions. As previously announced, SPECJ allows to support the other steps of Collaborative requirements definition process. ThinkTank supports elicitation process, and SPECJ supports the transformation of needs into requirements, the verification and validation of requirements, and finally the requirement recording.

Conclusion

This paper suggests an approach for Requirements Engineering based on separation of engineering and collaboration concerns. We firstly considered the engineering processes provided by the standard EIA-632 and we proposed a collaboration model based on this standard. This model of collaboration is formally defined as a function of the EIA-632 engineering processes, based on guidelines for collaboration process design from the Collaboration Engineering literature. The result of this function depends on the process at hand, in particular a requirements document, in a requirements definition context. We also defined a conceptual model of collaborative requirements engineering using the thinkLet concept provided by the Collaboration Engineering approach. In order to evaluate the approach, we did two case studies in a requirements elicitation context. We have used four different methods for requirements engineering, based on new and existing thinkLets.

It is important to note that only needs were generated from these thinkLets and that needs have to be transformed into requirements. Each need can give rise to zero or several requirements because needs are high level requirements. The transformation of needs into requirements is made in the requirements specification phase, which is out of the scope of this study even though our prototype SPECJ partly supports this phase. To transform needs into requirements, a shared understanding between users and engineers needs to be established, which is a critical and challenging task. Further research is required to develop a collaborative approach to this step. For this the easy win win negotiation [START_REF] Boehm | Developing Groupware for Requirements Negotiation: Lessons Learned[END_REF] process could be a basis. The contribution of this article is the proposition to use a collaboration model in which both the System Engineering and Collaboration Engineering approach is integrated. System Engineering provides engineering processes whereas Collaboration Engineering provides collaboration processes. This contributes to the originality of our approach. A class diagram illustrates this conceptualization. We also contributed by creating two new thinkLets that enrich the thinkLet library. Equally, we presented the results of two case studies on a collaborative requirements elicitation process to evaluate our approach. From the results of the questionnaire we can conclude that the LeafHopper thinkLet was the most effective way to elicit needs. We also developed the prototype SPECJ supporting following step of generation, especially collaborative documenting. It is an implementation of the model presented in section 4. Indeed, SPECJ architecture is based on the same concepts of this model. However, we think that the combination of methods helps the participants to look at the system requirements from different perspectives, which will helped to increase completeness and rigour of the requirements. Further research is required to understand the added value and combinatory value of the different thinkLets for requirements elicitation. Additionally, field experiments with both the combination of thinkLets to elicit requirements would be next step in this research. Further development of the SPECJ application to improve its robustness and its function as a GSS for requirements elicitation would be another next step.

Clear understanding of the purpose of storytelling

Outputs

A common and collective story created from experiences of all participants. This thinkLet is based on GSS allowing people to speak and write their stories. Each team member shares a story with his/her experience to elicit one perspective of a common problem. Each member can elaborate and reflect on stories from other participants. Members can also ask questions for clarification. The stories are merged to create a collective story. In this technique a highly elaborative way of generation is used. People share experiences about a problem or issue. The results will be detailed, but fuzzy stories, which will offer contextual information. Extensive convergence is required to integrate stories and to elicit key aspects or characteristics of the problem. Story telling can also be used in a more visionary sense, to envision future scenario's and use cases of systems that are to be developed. A challenge is to ensure that the stories are sufficiently anonymous, and that naming and blaming is avoided. Another challenge is to ensure that stories are complete and open reports of experiences, and that vagueness such as 'and we all know what that meant' or 'the rest is history' is avoided.

How to use

Dialogue: generate

Choose this thinkLet if

 Participants need to envision solutions from different perspectives  A shared understanding of the needs and challenges of each perspective is required Overview Participants will engage in a dialogue in which they will assume the role of a stakeholder in the issue or topic. In this way they will look at the challenge from a different perspective. Assign each participant a stakeholders role, ensure that they understand their role, and that they stay in their role for the duration of the activity 2.

Input

A clearly defined topic or issue to generate reflections or contributions on A set of stakeholder roles

Assign each participant to a discussion page with the title of the role he/she represents Steps 1.

Ask each participant to write a brief statement from the perspective of his/her role about the issue 2.

Ask participants to stay in their role and respond to one or more statements opening a dialogue. You can ask questions for clarification of the statement, reflect on it, or make a counter proposal.

3.

After each contribution, return to your own page and respond, in your role to the remarks, or issues raised, keep your dialogue updated alternating between contributions to others and responding to issues raised on your own page.

Dialogue Insights

A dialogue is a natural way to engage in discussion about issues and suggestions or reflections. In this way for instance a requirements negotiation can be done. As each participant is asked to discuss the requirements from a different perspective than his own, they will gain mutual understanding of the challenges and issues of each of the perspectives.

Some Definitions:

System Engineering (SE) is methodological, cooperative and interdisciplinary approach covering overall suitable activities to design, develop, evolve and verify a system by giving satisfying solution to all stakeholders needs during the system life cycle (IEEE, 1999).

Stakeholder is an enterprise, an organization, or individual having an interest or a stake in the outcome of the engineering of a system (EIA-632, 1999).

Client is an enterprise, organization, or individual that: (1) commissions the engineering of a system; (2) is a prospective purchaser of the parts of a system, or portions thereof; or (3) is an acquirer of a system (EIA-632, 1999).

End user is an enterprise, organization, or individual that operates directly on the system (EIA-632, 1999). He/she can be the client.

Acquirer is an enterprise, organization, or individual that obtains a product (good or service) from a supplier (EIA-632, 1999).

Figure 2 :

 2 Figure 2: Relationships of processes for engineering a system. (EIA-632, 1999)

Figure 3 :

 3 Figure 3: Time devoted to products development by engineers. (PTC, 2007)

Figure 4 :

 4 Figure 4: Problem indication

Figure 5 :

 5 Figure 5: Collaboration model for EIA-632 3.4.2 Behaviour in the Collaborative ProcessesThis part is focused on the constraints for activities. The interactions and the sequence of activities are in the center of a collaboration model. In our approach, the structuration of a collaboration process is not identical to that of an engineering process. However, they are interdependent. The structuration of the process defines the order of execution for the activities. The thinkLet language allows expressing this order in a facilitation process model as shown in figure6. This example is from a quick session on requirements elicitation.

Figure 6 :

 6 Figure 6: facilitation process model for requirements elicitation.

Figure 7

 7 Figure 7 shows a class diagram with the different concepts in collaborative requirements engineering: Requirement is a technical definition of a Constraint or a Need even through it is not always possible to translate any constraint and need into a requirement. Requirements are sorted into Categories. Categories can have sub-categories, they are recorded in a Specifications book. Requirements are defined according to an Engineering Process, which is a sequence of Tasks. Each collaborative task has Activities supported by one or more ThinkLets. A Collaboration Process is constructed with thinkLets and involves at least three Participants.

Figure 7 :

 7 Figure 7: Class model of engineering and collaboration processes.

Figure 8 :

 8 Figure 8: Collaborative Requirements Engineering process.

Figure 9 :

 9 Figure 9: High level use case and interaction diagram for the requirements engineering process

Figure 10 :

 10 Figure 10: Requirements Elicitation phase.

Figure 11 :

 11 Figure 11: Repeatable process for requirements elicitation

Figure 12 :

 12 Figure 12: Functional Architecture of SPECJ

Figure 13 :

 13 Figure 13: Collaborative requirements specification

  3.4.3 Formal definition insightThe function called Collaboration has been defined as following: (PROCE x PROCC, CON) -> RESULT We consider the thinkLet as a function in present formulation of collaboration definition. So, let P e є PROCE and P c є PROCC and C є CON

	{task, collaborative elementary task}
	P e = {Comp(task i ), collaborative composite task composed of task i , i є [1, N]}
	{Seq(task i ), collaborative sequential task with task i , i є [1, N]}
	and
	{thinkLet, collaborative elementary process}
	P c = {Comp(thinkLet i ), composite collaborative process composed of
	thinkLet i , i є [1, N]}
	{Seq(thinkLet i ), sequential collaborative process with thinkLet i ,
	i є [1, N]}
	and
		{thinkLet(task) if P e = task}
	Collaboration (P e , P c , C) =	{thinkLet(Comp(task

1= strongly disagree 7= strongly agree

	Dialogue	4,41	1,42
	Group Storytelling	4,27	1,34
	LeafHopper	4,82	1,39
	h. This method helped to ensure rigor of the requirements
	Brainstorming	4,25	1,38
	Dialogue	4,36	1,30
	Group Storytelling	4,50	1,20
	LeafHopper	4,98	1,32
		Means (n=44)	Standard deviations (n=44)
	a. The method was easy to learn
	Brainstorming	6,00	1,17
	Dialogue	5,32	1,36
	Group Storytelling	4,93	1,42
	LeafHopper	5,43	1,40
	b. The rules & instructions of method were clear
	Brainstorming	5,55	1,23
	Dialogue	4,61	1,28
	Group Storytelling	4,34	1,40
	LeafHopper	4,98	1,25
	c. The method was efficient, it took little effort/time for maximum results
	Brainstorming	5,00	1,60
	Dialogue	4,39	1,46
	Group Storytelling	4,11	1,48
	LeafHopper	4,89	1,54
	d. The method was helpful to express needs
	Brainstorming	5,11	1,35
	Dialogue	4,80	1,27
	Group Storytelling	4,61	1,48
	LeafHopper	5,23	1,35
	e. The requirements created with this method were useful for our design project
	Brainstorming	5,27	1,50
	Dialogue	4,84	1,26
	Group Storytelling	4,57	1,39
	LeafHopper	5,23	1,28
	f. The requirements generated with this method were of high quality
	Brainstorming	4,16	1,36
	Dialogue	4,27	1,29
	Group Storytelling	4,14	1,22
	LeafHopper	4,98	1,39
	g. This method helped to ensure completeness of the requirements
	Brainstorming	4,27	1,60

Table 1 :

 1 Summary of the results from the first and second session.

Storytelling Setup 1

  . Create story pages in GSS a. each participant sees a page and can add part of the story b. one or two extra pages, depending on the group size 2. Present the problem that is the focus points of the story Steps 1. Says this: a. Please click on the "start button". The system will bring you to empty electronic page. Each of you has a different electronic page. You will each start on a different electronic page. b. You may each type a story on the problem presented, up to 50 words long. Then you must click the submit button to send the page back to the group. c. The system will randomly bring you a different page. That page will have somebody else's story on it. d. When you see a page with somebody else's story on it, you may respond in following ways: i. You can enrich the story with complementary points ii. You can reflect or react on the story, give comments iii. You may argue against and add your own experience if you have counter example. e. You may type new episode of a story on new page. Then you must send that page back to the group. The system will bring you a new page. f. We will continue swapping pages and submitting comments, suggestions and elaborations about stories until we have a complete picture of the problem. g. Any questions?

	Storytelling Insight

Appendix

Storytelling: generate

Choose this thinkLet

 to create collective story from experiences of all participants  to make link between participant problems and real-world situations  when people need to understand the context of the contribution  to gather rich and detailed contributions based on experience Overview

In this thinkLet the group members tell stories of their experiences.

Inputs


Jan Beirlant

Mikael Escobar-Bach

Yuri Goegebeur

Armelle Guillou

Bias-corrected estimation of stable tail dependence function

Keywords: Multivariate extreme value statistics, stable tail dependence function, bias correction AMS Subject classification: 62G05, 62G20, 62G32

We consider the estimation of the stable tail dependence function. We propose a biascorrected estimator and we establish its asymptotic behaviour under suitable assumptions.

The finite sample performance of the proposed estimator is evaluated by means of an extensive simulation study where a comparison with alternatives from the recent literature is provided.

Introduction and notations

Many problems involving extreme events are inherently multivariate. For instance, de Haan and de Ronde (1998) estimate the probability that a storm will cause a sea wall near the town of Petten (the Netherlands) to collapse because of a dangerous combination of sea level and wave height. Other examples can be found in actuarial science, finance, environmental science and geology, to name but a few. A fundamental question that arises when studying more than one variable is that of extremal dependence. Similarly to classical statistics one can summarise extremal dependency in a number of well-chosen coefficients that give a representative picture 1 of the dependency structure. Here, the prime example of such a dependency measure is the coefficient of tail dependence [START_REF] Ledford | Modelling dependence within joint tail regions[END_REF]. Alternatively, a full characterization of the extremal dependence between variables can be obtained from functions like e.g. the stable tail dependence function, the spectral distribution function or the Pickands dependence function. We refer to [START_REF] Beirlant | Statistics of Extremes -Theory and Applications[END_REF] and de [START_REF] De Haan | Extreme Value Theory -An Introduction[END_REF], and the references therein, for more details. In this paper we will focus on bias-corrected estimation of the stable tail dependence function.

For any arbitrary dimension d, let pX p1q , ..., X pdq q be a multivariate vector with continuous marginal cumulative distribution functions (cdfs) F 1 , ..., F d . The stable tail dependence function is defined for each x i R , i 1, ..., d, as lim tÑV tP ¡ 1 ¡ F 1 pX p1q q ¤ t ¡1 x 1 or ... or 1 ¡ F d pX pdq q ¤ t ¡1 x d © Lpx 1 , ..., x d q which can be rewritten as

lim tÑV t 1 ¡ F F ¡1 1 p1 ¡ t ¡1 x 1 q, ..., F ¡1 d p1 ¡ t ¡1 x d q ¨$ Lpx 1 , ..., x d q (1)
where F is the multivariate distribution function of the vector pX p1q , ..., X pdq q.

Now, consider a sample of size n drawn from F and an intermediate sequence k k n , i.e. k Ñ V as n Ñ V with k{n Ñ 0. Let us denote x px 1 , ..., x d q a vector of the positive quadrant R d and X pjq k,n the k¡th order statistic among n realisations of the margins X pjq , j 1, ..., d. The empirical estimator of L is then given by

p L k pxq 1 k n i1
1l tX p1q i ¥X p1q n¡rkx 1 s 1,n or ... or X pdq i ¥X pdq n¡rkx d s 1,n u .

The asymptotic behaviour of this estimator was first studied by [START_REF] Huang | Statistics of bivariate extremes[END_REF]; see also [START_REF] Drees | Best attainable rates of convergence for estimators of the stable tail dependence function[END_REF], and de [START_REF] De Haan | Extreme Value Theory -An Introduction[END_REF]. As is common in extreme value statistics, the empirical estimator p L k pxq is affected by bias, which often complicates its application in practice. This bias-issue will be addressed in the present paper.

In the univariate framework there are numerous contributions to the bias-corrected estimation of the extreme value index and tail probabilities. Typically, the bias reduction of estimators for For the sequel, in order to study the behaviour of p L k pxq or a function of it, we need to assume some conditions mentioned below and well-known in the extreme value framework:

First order condition: The limit in (1) exists and the convergence is uniform on r0, T s d for T ¡ 0;

Second order condition: There exist a positive function α such that αptq Ñ 0 as t Ñ V and a non null function M such that for all x with positive coordinates

lim tÑV 1 αptq 2 t 1 ¡ F F ¡1 1 p1 ¡ t ¡1 x 1 q, ..., F ¡1 d p1 ¡ t ¡1 x d q ¨$ ¡ Lpxq @ M pxq, (2)
uniformly on r0, T s d for T ¡ 0;

Third order condition: There exist a positive function β such that βptq Ñ 0 as t Ñ V and a non null function N such that for all x with positive coordinates lim tÑV 1 βptq

5 t 1 ¡ F F ¡1 1 p1 ¡ t ¡1 x 1 q, ..., F ¡1 d p1 ¡ t ¡1 x d q ¨$ ¡ Lpxq αptq ¡ M pxq C N pxq, (3)
uniformly on r0, T s d for T ¡ 0. This requires that N is not a multiple of M .

Note that these assumptions imply that the functions α and β are both regularly varying with indices ρ and ρ I respectively which are non positive. In the sequel we assume that both indices are negative. Remark also that the functions L, M and N have an homogeneity property, that is

Lpaxq aLpxq, M paxq a 1¡ρ M pxq and N paxq a 1¡ρ¡ρ I N pxq for a positive scale parameter a.

The remainder of the paper is organised as follows. In the next section we introduce our estimators for Lpxq, as well as for the second order quantities ρ and α, and study their asymptotic properties. The finite sample performance of the proposed bias-corrected estimator and of some estimators from the recent literature are evaluated by a simulation experiment in Section 3. The proofs of all results are given in the Appendix.

Estimators and asymptotic properties

Consider now the rescaled version p L k,a pxq : a ¡1 p L k paxq for a positive scale parameter a. Our first aim is to look at the behaviour of

r L k pxq : 1 k k j1
Kpa j q p L k,a j pxq where a j : j k 1 , j 1, ..., k, and K is a function defined on p0, 1q which is positive and such that ³ 1 0 Kpuqdu 1. This function is called a kernel function in the sequel. Let e j be a d¡vector with zeros, except for position j where it is one.

Theorem 1: Let X 1 , ..., X n be independent multivariate random vectors in R d with common joint cdf F and continuous marginal cdfs F j , j 1, ..., d. Assume that the third order condition

(3) holds with negative indices ρ and ρ I and that the first order partial derivatives of L, say δ j L, exist and that δ j L is continuous on the set of points tx R d : x j ¡ 0u. Suppose further that the function M is continuously differentiable and N continuous. Let K be a kernel such that

³ 1 0 Kpuqu ¡1{2 du V. Assuming that the intermediate sequence k satisfies c kαpn{kq Ñ V and c kαpn{kqβpn{kq Ñ 0 as n Ñ V, we have c k 5 r L k pxq ¡ 1 k k j1 Kpa j qLpxq ¡ α ¡ n k © M pxq 1 k k j1 Kpa j qa ¡ρ j C d ÝÑ ¢» 1 0 Kpuqu ¡ 1 2 du Z L pxq (4)
in Dpr0, T s d q for every T ¡ 0 where

Z L pxq : W L pxq ¡ d j1
W L px j e j qδ j Lpxq with W L a continuous centered Gaussian process with covariance structure ErW L pxqW L pyqs µtRpxq Rpyqu where Rpxq tu R d : there exists j such that 0 ¤ u j ¤ x j u and µ is the measure defined as µ tRpxqu : Lpxq. uZ L pxq. From our Theorem 1, we can easily deduce the following corollary which gives the asymptotic behaviour of an uncorrected estimator,

r L k pxq 1 k °k j1 Kpa j q , for L.
Corollary 1: Under the assumptions of Theorem 1, we have

c k 5 r L k pxq 1 k °k j1 Kpa j q ¡ Lpxq ¡ α ¡ n k © M pxq 1 k °k j1 Kpa j qa ¡ρ j 1 k °k j1 Kpa j q C d ÝÑ ¢» 1 0 Kpuqu ¡ 1 2 du Z L pxq in Dpr0, T s d q for every T ¡ 0.
Now the idea is to remove from r L k pxq 1 k °k j1 Kpa j q the bias term by estimating the function α n k ¨M pxq as well as the second order rate parameter ρ. These quantities will be estimated externally with the same intermediate sequence k k n , which is such that k opkq. This idea was originally proposed in the univariate framework by Gomes and co-authors (see [START_REF] Caeiro | Reduced-bias tail index estimators under a third order framework[END_REF] and has the advantage that the variance of the reduced bias estimator is the same as that of the uncorrected estimator.

First we have to define an estimator for ρ. Similarly to [START_REF] Fougères | Bias correction in multivariate extremes[END_REF], we propose the following estimator:

r ρ k px ¦ q : ¢ 1 ¡ 1 log r log § § § § ∆ k,a prx ¦ q ∆ k,a px ¦ q § § § § 0 ( 5
)
at a fixed d¡vector x ¦ , where r p0, 1q and

∆ k,a pxq : a ¡1 r L k paxq ¡ r L k pxq.
Proposition 1. For any fixed d¡vector x ¦ , under the assumptions of Theorem 1, we have

c kα ¡ n k © pr ρ k px ¦ q ¡ ρq d ÝÑ 1 ¡ r ρ¡ 1 2 log r Z L px ¦ q M px ¦ q ³ 1 0 Kpuqu ¡ 1 2 du ³ 1 0 Kpuqu ¡ρ du a ¡1{2 ¡ 1 a ¡ρ ¡ 1 .
Secondly we study the estimation of q α k pxq : αpn{kqM pxq.

p L k,a j pxq Lpxq q α k pxqa ¡ρ j ε j , j 1, . . . , k, (6)
where ε 1 , . . . , ε k are random error terms. Straightforward application of least squares estimation to [START_REF] Drees | Best attainable rates of convergence for estimators of the stable tail dependence function[END_REF], where ρ is fixed at r ρ k px ¦ q given in ( 5), leads to

r α k pxq : °k j1 °k 1 ¡ a ¡r ρ k px ¦ q j ¡ a ¡r ρ k px ¦ q © p L k,a j pxq °k j1 °k 1 a ¡r ρ k px ¦ q j ¡ a ¡r ρ k px ¦ q j ¡ a ¡r ρ k px ¦ q © . (7)
The aim of the next proposition is to establish the asymptotic behaviour of this estimator.

Proposition 2. For any fixed d¡vector x ¦ , under the assumptions of Theorem 1, we have

c k ¡ r α k pxq ¡ α ¡ n k © M pxq © d ÝÑ 1 ¡ r ρ¡ 1 2 log r M pxq M px ¦ q ³ 1 0 Kpuqu ¡ 1 2 du ³ 1 0 Kpuqu ¡ρ du a ¡1{2 ¡ 1 a ¡ρ ¡ 1 ρ 2 ρ ¡ 1 ρp1 ¡ ρqp1 ¡ 2ρq Z L px ¦ q 2p1 ¡ ρq ρ Z L pxq
in Dpr0, T s d q for every T ¡ 0.

We have now all the ingredients to study the behaviour of our bias-corrected estimator for L, namely

L k,k pxq : r L k pxq ¡ ¡ k k © r ρ k px ¦ q r α k pxq 1 k °k j1 Kpa j qa ¡r ρ k px ¦ q j 1 k °k j1 Kpa j q .
This leads to our Theorem 2.

Theorem 2: Under the assumptions of Theorem 1, satisfied for two intermediate sequences k

and k such that k op kq we have c

k ¡ L k,k pxq ¡ Lpxq © d ÝÑ ¢» 1 0 Kpuqu ¡ 1 2 du Z L pxq (8)
in Dpr0, T s d q for every T ¡ 0.

Note that the limiting process is independent of the value of ρ, and that the bias-corrected estimator has the same asymptotic variance as the uncorrected estimator of Corollary 1.

A problem of interest could be now to minimize the variance in our Theorem 2. To this aim, we illustrate in Corollary 2 that if we take a power kernel, that is a kernel of the form Kptq pτ 1q t τ 1l ttp0,1qu with τ ¡ ¡1{2, the variance of our bias-corrected estimator L k,k pxq is decreasing as τ increases, and it can reach the variance of the empirical estimator p L k pxq, i.e. the variance of Z L pxq (see Proposition 2 in Fougères et al., 2015).

Corollary 2: Under the assumptions of Theorem 2, for the power kernel Kptq pτ 1q t τ 1l ttp0,1qu with τ ¡ ¡1{2, we have c

k ¡ L k,k pxq ¡ Lpxq © d ÝÑ 2 1 τ 1 2τ Z L pxq
in Dpr0, T s d q for every T ¡ 0.

Simulation experiment

In order to evaluate the finite sample behaviour of our estimator L k,k pxq, we perform a simulation study and we compare our estimator with the empirical one, p L k pxq, and two bias-corrected estimators recently proposed by [START_REF] Fougères | Bias correction in multivariate extremes[END_REF], defined as follows

9 L k,a,k pxq : p L k,a pxq ¡ p ∆ k,pa ¡p ρ k px ¦ q 1q ¡1{p ρ k px ¦ q pxq r L k,a,k pxq : p L k pxq p ∆ k,a paxq ¡ p L k paxq p ∆ k,a pxq p ∆ k,a paxq ¡ a p ∆ k,a pxq
where p ∆ k,a pxq is defined similarly as ∆ k,a pxq but based on the empirical estimator, that is

p ∆ k,a pxq : a ¡1 p L k paxq ¡ p L k pxq and p ρ k px ¦ q similarly as r ρ k px ¦ q but based on p ∆ k,a pxq: p ρ k px ¦ q : £ 1 ¡ 1 log r log § § § § § p ∆ k,a prx ¦ q p ∆ k,a px ¦ q § § § § § 0. (9)
For simplicity, we focus on R 2 and using the homogeneity property, we consider only the estimation of Lpt, 1 ¡tq for t p0, 1q, corresponding to Pickands dependence function, and the same distributions as in [START_REF] Fougères | Bias correction in multivariate extremes[END_REF], namely the Cauchy distribution, for which Lpx, yq px 2 y 2 q 1{2 ; the Student(ν) distribution, for which

Lpx, yq y F ν 1 £ py{xq 1{ν ¡ θ c 1 ¡ θ 2 c ν 1 x F ν 1 £ px{yq 1{ν ¡ θ c 1 ¡ θ 2 c ν 1
where F ν 1 is the cdf of the univariate Student distribution with ν 1 degrees of freedom and θ is the Pearson correlation coefficient. We set θ 0.5 and ν 2; the bivariate Pareto of type II model, for which Lpx, yq x y ¡ px ¡p y ¡p q ¡1{p . We set p 3 and we called this model BPII(3); the Symmetric logistic model, for which Lpx, yq px 1{s y 1{s q s . We set s 1{3; the Archimax model with the logistic generator Lpx, yq px 2 y 2 q 1{2 and with the mixed generator Lpx, yq px 2 y 2 xyq{px yq.

For each distribution, we simulate 1000 samples of size 1000. As recommended by Fougères et al. (2015), we use the values a r 0.4, k 990, and we take x ¦ x. Since any stable tail dependence function satisfies maxpt, 1 ¡ tq ¤ Lpt, 1 ¡ tq ¤ 1, all the estimators have been corrected so that they satisfy these bounds.

First, in Figure 1 we give the boxplots of p ρ k p0.5, 0.5q and r ρ k p0.5, 0.5q for a power kernel with τ 0, 5 and 10 in case of a Studentp2q distribution. It is clear from these boxplots that the estimators for ρ perform reasonably well with respect to the median, but with some volatility, except in case τ 0 where it is reduced. However, as we will see in the other figures, these uncertainties seem to have fortunately no impact on the performance of our estimators for L. Note also that our estimator r ρ k px ¦ q is at least as competitive as the one proposed by [START_REF] Fougères | Bias correction in multivariate extremes[END_REF], whatever the value of τ ¥ 0. Moreover, to avoid problems in the computation of 9 L k,a,k pxq due to the fact that p ρ k px ¦ q can be too close to 0, we set p ρ k px ¦ q ¡1 if p ρ k px ¦ q r¡0.1, 0s and its definition given in (9) otherwise. Similarly, for consistency, this modification has been used for r ρ k px ¦ q.

Next, we examine the performance of the estimators for Lpxq at specific points in R 2 . In Figure 2 L k,a,k pxq (dotted line) and r L k,a,k pxq (dashed line), and the empirical one, p L k pxq (dash-dotted line), for x p0.5, 0.5q and x p0.2, 0.8q, respectively. From the plots of the sample means we can clearly see the bias-correcting effect of L k,k pxq and r L k,a,k pxq: compared to the empirical estimator these estimators have a stable sample path that is close to the true value of Lpxq and this for a wide range of values of k. The estimator 9

L k,a,k pxq has some bias-correcting effect, though the gain relative to the empirical estimator is quite distribution dependent. Unlike r L k,a,k pxq, the estimator L k,k pxq has a very smooth sample path, which can be expected as we take essentially a weighted sum of the empirical estimator calculated over different values of x.

In terms of MSE, L k,k pxq has a better performance than 9 L k,a,k pxq and r L k,a,k pxq. Compared to the empirical estimator, one can see that it has an MSE value that is at least as good as that of the minimum MSE for p L k pxq, but it has this low MSE over a very wide range of k-values.

Finally, we compare the different estimators for L not at a single point but for the whole function, using the absolute bias and MSE, computed over N 1000 replications as follows:

Abiaspkq : 1 10

10 ţ1 § § § § § 1 N N i1 p L piq k px t q ¡ Lpx t q § § § § § MSEpkq : 1 10N 10 ţ1 N i1 ¡ p L piq k px t q ¡ Lpx t q © 2
where tx t : 4 Appendix: Proofs

Proof of Proposition 1

The key elements in the proof are the homogeneity of the functions L and M together with the equality in distribution between the processes Z L paxq and c aZ L pxq. Thus from our Theorem q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q rho_hat tau=0 tau=5 tau=10 1, we deduce that

∆ k,a px ¦ q α ¡ n k © M px ¦ q 1 k k j1 Kpa j qa ¡ρ j ra ¡ρ ¡ 1s Z L px ¦ q c k » 1 0 Kpuqu ¡ 1 2 dura ¡ 1 2 ¡ 1s o P ¢ 1 c k .
A similar expression can be obtained for ∆ k,a prx ¦ q from which we can easily justify the expression of our estimator r ρ k px ¦ q given in ( 5), and deduce that r

ρ k px ¦ q ρ 1 ¡ r ρ¡ 1 2 log r 1 c k Z L px ¦ q α n k ¨M px ¦ q ³ 1 0 Kpuqu ¡ 1 2 du 1 k °k j1 Kpa j qa ¡ρ j a ¡ 1 2 ¡ 1 a ¡ρ ¡ 1 o P £ 1 c kα n k ¨ ,
from which we can easily deduce our Proposition 1.

Proof of Proposition 2

To prove the proposition, we use the Skorohod construction, meaning that we have to look at the difference and to show that it tends almost surely uniformly to 0 as n Ñ V. According to Proposition 2 in Fougères et al. (2015) and using [START_REF] Dutang | Robust and bias-corrected estimation of the coefficient of tail dependence[END_REF], we have

D : § § § § § c k ¡ r α k pxq ¡ α ¡ n k © M pxq © ¡ 1 ¡ r ρ¡ 1 2 log r M pxq M px ¦ q ³ 1 0 Kpuqu ¡ 1 2 du ³ 1 0 Kpuqu ¡ρ du a ¡1{2 ¡ 1 a ¡ρ ¡ 1 ρ 2 ρ ¡ 1 ρp1 ¡ ρqp1 ¡ 2ρq Z L px ¦ q ¡ 2p1 ¡ ρq ρ Z L pxq § § § § 0
D ¤ § § § § § § c kα ¡ n k © M pxq °k j1 °k 1 ra ¡ρ j ¡ a ¡r ρ k px ¦ q j sra ¡r ρ k px ¦ q j ¡ a ¡r ρ k px ¦ q s °k j1 °k 1 a ¡r ρ k px ¦ q j ra ¡r ρ k px ¦ q j ¡ a ¡r ρ k px ¦ q s ¡ 1 ¡ r ρ¡ 1 2 log r M pxq M px ¦ q ³ 1 0 Kpuqu ¡ 1 2 du ³ 1 0 Kpuqu ¡ρ du a ¡1{2 ¡ 1 a ¡ρ ¡ 1 ρ 2 ρ ¡ 1 ρp1 ¡ ρqp1 ¡ 2ρq Z L px ¦ q § § § § § § § § § § § ¤ ¥ °k j1 °k 1 a ¡ 1 2 j ra ¡r ρ k px ¦ q j ¡ a ¡r ρ k px ¦ q s °k j1 °k 1 a ¡r ρ k px ¦ q j ra ¡r ρ k px ¦ q j ¡ a ¡r ρ k px ¦ q s ¡ 2p1 ¡ ρq ρ Z L pxq § § § § § § op1q.
The main idea now is to replace everywhere the terms with r ρ k px ¦ q by the same terms with ρ and to study the difference by the mean value theorem. For instance, if we look at the term

1 k 2 k j1 k ¸ 1 a ¡r ρ k px ¦ q j ra ¡r ρ k px ¦ q j ¡ a ¡r ρ k px ¦ q s
appearing several times as a denominator in the bound of D, we can rewrite it as follows:

1 k 2 k j1 k ¸ 1 a ¡ρ j ra ¡ρ j ¡ a ¡ρ s 1 k 2 k j1 k ¸ 1 a ¡r ρ k px ¦ q j pa ¡r ρ k px ¦ q j ¡ a ¡r ρ k px ¦ q q ¡ a ¡ρ j pa ¡ρ j ¡ a ¡ρ q % ρ 2 p1 ¡ ρq 2 p1 ¡ 2ρq o ¢ 1 c k ¡2pr ρ k px ¦ q ¡ ρq £ 1 k k j1 a ¡2q ρ k px ¦ q j ln a j 2pr ρ k px ¦ q ¡ ρq £ 1 k k j1 a ¡q ρ k px ¦ q j £ 1 k k j1
a ¡q ρ k px ¦ q j ln a j by the mean value theorem where q ρ k px ¦ q is an intermediate value between r ρ k px ¦ q and ρ. Using the same approach for each term combining with Proposition 1 leads to Proposition 2.

Proof of Theorem 2

According to our Theorem 1, we clearly have the following decomposition

c k ¡ L k,k pxq ¡ Lpxq © c k α ¡ n k © M pxq ¡ ¢ k k r ρ k px ¦ q r α k pxq ' 1 k °k j1 Kpa j qa ¡ρ j 1 k °k j1 Kpa j q c k ¢ k k r ρ k px ¦ q r α k pxq 1 k °k j1 Kpa j qra ¡ρ j ¡ a ¡r ρ k px ¦ q j s 1 k °k j1 Kpa j q £ ³ 1 0 Kpuqu ¡ 1 2 du 1 k °k j1 Kpa j q Z L pxq o P p1q c k α ¡ n k © M pxq ¡ ¢ k k r ρ k px ¦ q α ¢ n k M pxq ' 1 k °k j1 Kpa j qa ¡ρ j 1 k °k j1 Kpa j q O P ¤ ¥ ¢ k k r ρ k px ¦ q¡ 1 2 kα ¢ n k pr ρ k px ¦ q ¡ ρq £ ³ 1 0 Kpuqu ¡ 1 2 du 1 k °k j1 Kpa j q Z L pxq o P p1q
by applying our Proposition 2 and again the mean value theorem. Under the assumptions of our Theorem 2, we have

c k ¡ L k,k pxq ¡ Lpxq © c k α ¡ n k © M pxq ¡ ¢ k k r ρ k px ¦ q α ¢ n k M pxq ' 1 k °k j1 Kpa j qa ¡ρ j 1 k °k j1 Kpa j q £ ³ 1 0 Kpuqu ¡ 1 2 du 1 k °k j1 Kpa j q Z L pxq o P p1q.
Recall now that the function α is regularly varying with index ρ 0, that is αptq t ρ α ptq where α is slowly varying at infinity. Thus when t Ñ V and c cptq Ñ V. To be convinced by [START_REF] Goegebeur | Asymptotically unbiased estimation of the coefficient of tail dependence[END_REF], remark that for all x, y ¡ 0 and t ¡ 0 we have with β 1 ptq αptqβptq and L t px1q t 1 ¡ F F ¡1 x ¡ρ ψp1{xq, with ψpxq a x ρ I ¡1 ρ I and a ¡ 0 (in case a 0 one can redefine α as ¡ α and the result will follow with a ¡ 0). Note that the positive constant a can in fact be incorporated in the function β, so from now on we take without loss of generality a 1. We have thus, with r where 0 δ ¡ρ I and κ ¡ 0. Since both functions in the right-hand side are bounded for

c k ¡ L k,k pxq ¡ Lpxq © k k k α ¢ n k M pxq ¢ k k ρ ¡ ¢ k k r ρ k px ¦ q ' 1 k °k j1 Kpa j qa ¡ρ j 1 k °k j1 Kpa j q k k k α ¢ n k ¢ k k ρ M pxq α p n k q α p n k q ¡ 1 ' 1 k °k j1 Kpa j qa ¡ρ j 1 k °k j1 Kpa j q £ ³ 1 0 Kpuqu ¡ 1 2 du 1 k °k j1 Kpa j q Z L pxq o P p1q £ ³ 1 0 Kpuqu ¡ 1 2 du 1 k °k j1 Kpa j q Z L pxq o P p1q O P £ ¢ k k 1 2 ¡q ρ k px ¦ q ln ¢ k k k α ¢ n k pr ρ k px ¦ q ¡ ρq ¢ k k 1 2 ¡ρ k α ¢ n k β ¢ n k 1 β ¡ n k © α p n k q α p n k q ¡ 1
x rx 0 , Vq, x 0 ¡ 0, result [START_REF] Goegebeur | Asymptotically unbiased estimation of the coefficient of tail dependence[END_REF] follows.

  tail parameters is obtained by taking the second order structure of an extreme value model explicitly into account in the estimation stage. We refer here to Beirlant et al. (1999), Feuerverger and Hall (1999), Matthys and Beirlant (2003), and more recently, Gomes et al. (2008) and Caeiro et al. (2009) . In the bivariate framework some attention has been paid to bias-corrected estimation of the coefficient of tail dependence η. Goegebeur and Guillou (2013) obtained the bias correction by a properly weighted sum of two biased estimators, whereas Beirlant et al. (2011) fitted the extended Pareto distribution to properly transformed bivariate observations. Recently, a robust and bias-corrected estimator for η was introduced by Dutang et al. (2014). For what concerns the stable tail dependence function we are only aware of the estimator recently proposed by Fougères et al. (2015).

Theorem 1

 1 is a direct application of Proposition 2 in Fougères et al. (2015) combining with the homogeneity properties of L and M mentioned above and the equality in distribution between the processes Z L puxq and c

  and 3 we show the sample mean (left) and the empirical mean squared error (MSE, right) of L k,k pxq with τ 0 (dashed line), τ 5 (full line) and τ 10 (dotted line) as a function of k, for x p0.5, 0.5q and x p0.2, 0.8q, respectively, on three of the above mentioned distributions for brevity. As is clear from these figures, in general the estimators have for all values of τ a nice stable behaviour close to the true value of Lpxq. This can be expected since our estimators are bias-corrected. In terms of MSE the best performance is at both x positions obtained for τ 5, and therefore in subsequent comparisons of estimators we will focus on this choice for our estimator. It is noteworthy to observe that the MSE has a very low curvature, so the MSE-values are very close to the minimum of the MSE for a very wide range of values for k. In Figures4 and 5we compare the performance of L k,k pxq (full line) with the two estimators proposed by Fougères et al. (2015), 9

t 10 ,

 10 1 ¡ t 10 ¨; t 1, ..., 10u and p L piq k is the estimate based on the i¡th sample. We naturally replace p L piq k by L piq k,k , 9 L piq k,a,k and r L piq k,a,k . In Figure 6 we show the Abiaspkq of the estimators under consideration as a function of k for the six distributions mentioned above. Figure 7 displays MSEpkq. These global performance measures lead us to the same conclusions as the aforementioned study at specific points. Because of the bias-correction, the estimators L k,k and r L k,a,k keep the bias low for a wide range of k-values. Overall, the estimator L k,k has a more smooth sample path than 9 L k,a,k and r L k,a,k , and therefore it also outperforms the estimators of Fougères et al. (2015) in terms of minimal MSE. Also here, the MSE of our estimator is close to or better than the minimal MSE value of the empirical estimator, and this for a wide range of k-values.

Figure 1 :

 1 Figure 1: Boxplots of p ρ k p0.5, 0.5q and r ρ k p0.5, 0.5q for a power kernel with τ 0, 5 and 10 in case of a Studentp2q distribution.

Figure 2 :

 2 Figure 2: Mean (left) and MSE (right) of our estimator L k,k p0.5, 0.5q for different values of τ : τ 0 (dashed line), τ 5 (full line), τ 10 (dotted line). Three distributions have been considered: First line: Student(2); Second line: Cauchy; Third line: BPII(3).

Figure 3 :

 3 Figure 3: Mean (left) and MSE (right) of our estimator L k,k p0.2, 0.8q for different values of τ : τ 0 (dashed line), τ 5 (full line), τ 10 (dotted line). Three distributions have been considered: First line: Student(2); Second line: Cauchy; Third line: BPII(3).

Figure 4 :

 4 Figure 4: Mean (left) and MSE (right) of our estimator L k,k at x p0.5, 0.5q with τ 5 (full line) compared to the estimators of Fougères et al. (2015): 9 L k,a,k (dotted line) and r L k,a,k (dashed line) and the empirical estimator p L k (dash-dotted line). Three distributions have been considered: First line: Student(2); Second line: Cauchy; Third line: BPII(3).

Figure 5 :

 5 Figure 5: Mean (left) and MSE (right) of our estimator L k,k at x p0.2, 0.8q with τ 5 (full line) compared to the estimators of Fougères et al. (2015): 9 L k,a,k (dotted line) and r L k,a,k (dashed line) and the empirical estimator p L k (dash-dotted line). Three distributions have been considered: First line: Student(2); Second line: Cauchy; Third line: BPII(3).

Figure 6 :

 6 Figure 6: Absolute bias of our estimator L k,k with τ 5 (full line) compared to the estimators of Fougères et al. (2015): 9 L k,a,k (dotted line) and r L k,a,k (dashed line) and the empirical estimator p L k (dash-dotted line). Six distributions have been considered: First line: Student(2) (left), Cauchy (right); Second line: BPII(3) (left), Symmetric logistic (right); Third line: Archimax mixed (left), Archimax logistic (right).

.

  Now write, for some function r β ¦ where r By Theorem B.2.18 in de Haan and Ferreira (2006) (see also[START_REF] Drees | On smooth statistical tail functionals[END_REF] we have for any ε ¡ 0 there is a t 0 such that for t, tx ¡ t 0 , p1 κqr|ψpxq| εx ρ I δ s.

  1 p1 ¡ t ¡1 xq, ..., F ¡1 d p1 ¡ t ¡1 xq ¨$, and using the fact that L t px1q xL t{x p1q, that1 x 4 L t pxy1q ¡ Lpxy1q ¡ αptqM pxy1q β 1 ptq ¡ L t px1q ¡ Lpx1q ¡ αptqM px1q β 1 ptq B L t{x py1q ¡ Lpy1q ¡ αpt{xqM py1q β 1 pt{xq ¡ L t{x p1q ¡ Lp1q ¡ αpt{xqM p1q β 1 pt{xq αptqx ¡ρ @ {β 1 ptq $ pMpy1q ¡ M p1qq .Since the limit for t Ñ V of β 1 pt{xq{β 1 ptq exists, from[START_REF] Gomes | Tail index estimation for heavy-tailed models: accommodation of bias in weighted log-excesses[END_REF] the limit for t Ñ V of 1 βptq ¡ αpt{xq αptq ¡ x ¡ρ © exists such that, combining with Theorem B.2.1 in de Haan and Ferreira (2006):

	lim tÑV	1 βptq	¢	αpt{xq αptq ¡ x ¡ρ	x ¡ρ lim tÑV	1 βptq	¢	α pt{xq α ptq ¡ 1
	Taking limits for t Ñ V we obtain that
	1 x pNpxy1q ¡ N px1qq lim tÑV 4 pNpy1q ¡ N p1qq β 1 pt{xq β 1 ptq	1 βptq	¢	αpt{xq αptq ¡ x ¡ρ	pMpy1q ¡ M p1qq	B	.	(11)

& β 1 pt{xq β 1 ptq 2 αpt{xq ¡

Acknowledgement

The authors kindly acknowledge Anne-Laure Fougères, Laurens de Haan and Cécile Mercadier for providing the program of their six distributions considered. This work was supported by a research grant (VKR023480) from VILLUM FONDEN and an international project for scientific cooperation (PICS-6416).