Eliciting Requirements for an Inter-Company ... - Semantic Scholar

Eliciting Requirements for an Inter-Company Cooperative Information System Hakim Bendjenna1,2, Nacer eddine Zarour2, Pierre-Jean Charrel1 1

University of Toulouse and Institut de Recherche en Informatique de Toulouse, Toulouse, France 2 Lire Laboratory, University Mentouri of Constantine, Constantine, Algeria [email protected], [email protected], [email protected]

Abstract Purpose – Requirements Engineering (RE) process constitutes the earliest phase of the information system development life-cycle. Requirements elicitation is considered as one of the most critical activities of this phase. Moreover, requirements elicitation is still a challenge, especially in the distributed environment of so-called inter-company cooperative information system. The purpose of this paper is to propose a methodology to elicit requirements for an inter-company cooperative information system. Design/methodology/approach – An analytical research was conducted. We have firstly evaluating the current requirements engineering approaches which are based on goals, scenarios or viewpoint. Then we have showing the role of elicitation technique selection step within the requirements elicitation process. Finally we have study the factors that affect this step in a distributed environment. An example from textile

industry is used to illustrate the applicability of the proposed methodology. Findings – Even though existing requirements elicitation approaches based either on goal, scenario or viewpoint are effective techniques, however, they present some difficulties in the practice. Moreover, in a cooperative distributed environment, more issues are created by inadequate communication, time difference between sites, cultural, language, and characteristics diversity of stakeholders which affect the elicitation technique selection step and thus the requirements elicitation process. In order to tackle with these issues, this paper presents a methodology called MAMIE (from MAcro to MIcro level requirements Elicitation) to elicit requirements for an inter-company cooperative information system. Also, a tool has been developed to facilitate the operation of our methodology Research limitations/implications – The major limitation of the paper is that is not tested or used in an organisation. Practical implications –Provide the analyst by well defined steps to elicit requirements for an inter-company cooperative information system. Understanding the role of the elicitation technique selection step within the requirements elicitation process and identifying the factors which have an impact on this step. Selecting an appropriate elicitation technique according to these factors. Originality/value – MAMIE integrates the three notions of goal, scenario and viewpoint to elicit requirements for an inter-company cooperative information system. We argue that these concepts may be used simultaneously and in a complementary way to improve the requirements elicitation process. Moreover, in order to increase the quality of the elicited requirements and thus the system-to-be quality, selecting an elicitation technique in MAMIE is not based on personal preferences but on situation assessment. Key-words Requirements elicitation, Inter-company cooperative information system, Elicitation technique selection, Goals, Scenarios, Viewpoints Paper type Research paper

1. Introduction It is widely accepted that the misidentification of requirements is one of the most significant sources of customer dissatisfaction with delivered systems (Macaulay, 1996). One of the objectives of the Requirements Engineering (RE) process is to elicit requirements that accurately represent stakeholders` needs (Mishra et al., 1996). This task is difficult enough when done locally but it is more difficult when stakeholders are distributed [Damian and Zowghi, 2002). Requirements elicitation is performed by using a wide variety of elicitation techniques, e.g. interviewing, questioning, prototyping, observation, workshops, etc. (Hickey and Davis, 2003b). When companies are brought to cooperate together, stakeholders as consequence work in an environment that cross organizational and national boundaries, where they may find themselves isolated from one another by distance and time. The geographic and temporal distance between stakeholders increases the difficulty to develop the RE process (Damian and Zowghi, 2002). Communication is particularly less effective because of the different time zones which complicate synchronous communication, and distance which makes face-to-face meetings more difficult (Herbsleb, 2007). Communication is also made difficult by cultural differences (Herbsleb and Moitra, 2001) and lack of awareness (Herbsleb, 2007) which may cause misunderstandings (Coughlan and Macredie, 2002). Traditional requirements elicitation methods which are based either on goals, scenario or viewpoint on generally do not scale well to support those important settings sufficiently. Moreover, according to our best of knowledge, there has been a little focus on requirements elicitation for an Inter-Company Cooperative Information System (ICIS). For example, in (Colombo and Francalanci, 2004) and (Gans et al., 2001), the authors have proposed approaches to model companies’ cooperation: both are based on i* model. i* model (Yu, 1995) offers a goal oriented conceptual framework for modelling social setting. The i* framework includes the Strategic Dependency model (SD) used to describe the network of relationships among actors, as well as the Strategic Rationale model (SR) used to describe the rationale that each actor performs concerning his relationships with other actors. In (Colombo and Francalanci, 2004) and (Gans et al., 2001) the SD model is used to model

inter-company relations in terms of: goals to be achieved, tasks to be executed or resources to be delivered, whereas the SR model is used to describe how companies accomplish their roles. However, the absence of ordering information in the operationalization of the tasks as well as the complexity which arises when several alternatives are taken in consideration (Alencar et al., 2008) makes using i* model less beneficial in our context. In fact, empirical evaluation has indicated that there is a lack of modularity in the i* framework (Estrada et al., 2006). Moreover, currently, only two views are supported, the Strategic Dependency (SD) Model and the Strategic Rational (SR) Model. Therefore, as systems models evolve and become larger, better information hiding and structuring mechanisms are needed (Alencar et al., 2008). In this paper, we propose a methodology called MAMIE (from MAcro to MIcro level requirements Elicitation) accompanied by an appropriate tool to elicit requirements for an ICIS. Some principles of MAMIE have been discussed in (Bendjenna et al., 2008a). MAMIE integrates for the first time goals, scenarios and viewpoints within a requirements elicitation approach. It copes with three levels of requirements abstraction: the macro-level is dealt with goals. Scenarios are used to describe the medium level of requirements. The micro level puts forward the notion of viewpoint to elicit low level requirements. Moreover, in order to improve requirements elicitation practice, and thus raise the likelihood that the system-tobe will meet stakeholders’ needs, MAMIE integrates a method to select the most appropriate elicitation technique according to the current situation. The layout of the paper is as follows. Section 2 presents background information on the motivations to develop an ICIS, the existing requirements engineering approaches and the elicitation technique selection during requirements elicitation. Section 3 presents MAMIE methodology and section 4 applies it to a case study from the textile industry. Related works are discussed in section 5. Finally, we summarize our work and we sketch some future research.

2. Background In this section, we introduce the notion of an inter-company cooperative information system. Next, we present the existing requirements engineering approaches. Finally, we discuss the relation between requirements elicitation and elicitation technique selection. 2.1 Inter-Company Cooperative Information System To respond to an economic and competitive environment which is becoming more and more complex, as well as to the globalization of markets, companies opt more frequently for alliances and partnerships, thus developing new net-working forms. The emergence of the concept of extended enterprise, virtual enterprise or networked companies is the result of the hope of some firms to form alliances with others, after careful selection and to set up long-term and valuable exchange relationships, so as to lighten infra-structures. The network keeps going thanks to the competence that each brings to a common project participation which does not affect their legal independence (Kanellis and Paul, 1997), (Paché, 1993). In this context the concept appears in the form of companies showing capitalistic and legal independence and capable of specializing in one task in the same value chain (Jarillo, 1988), (Powell, 1990). The main idea of the network companies is to limit the internal activity of each to its strategic competence and subcontract the rest to suppliers, subcontractors or external partners. We define a networked company as a company which counts on certain key competence in certain specialized activities, and which delegates to others the execution of less strategic tasks required for product expected by clients (Jarillo, 1988). In addition, today’s economic environment requires new relationships between competitors. Relationships have changed and it is not unusual to see behaviour which is much closer to cooperation and collaboration than competition. Who could have believed a few years ago that IBM and Apple would decide to cooperate to launch a compatible computer working in both environments; such behaviour represents a new kind of cooperation between competitors (Boughzala et al., 2004). One of the keys to successful networked companies is their information system, referred to in this context as the InterCompany Cooperative Information System (ICIS). This system contains information and knowledge with a syntax and semantics shared and understood by all members of the networked companies (Kanellis and Paul, 1997). 2.2 Requirements Engineering Approaches Requirements engineering is one of the early processes of the system development life cycle and it involves stakeholders in an iterative and incremental process of problem analysis, requirements elicitation, specification and validation (Wiegers, 2003). Various researches (e.g., (Antón et al., 2000), (Lamsweerde, 2001), (Yu, 1995)) suggest that a goal oriented approach to requirements is a good one, since goals are more stable than requirements. A goal oriented approach starts with goals, and derives the requirements from them. A goal is defined as an intention of a stakeholder. Goal-driven approaches focus on why systems are constructed, expressing the rationale and justification for the proposed system. Similarly, an alternative approach to requirements engineering, the scenario-based approach, has been proposed. By capturing examples and illustrations, scenarios help people in reasoning about complex systems (Potts et al., 1994). Since scenarios describe real situations, they capture real requirements. However, because they deal with examples and illustrations, scenarios only provide restricted requirements descriptions which need to be generalised to obtain complete requirements. Although the merits and benefits of scenario-based and goal-based analysis in requirements engineering are well understood, researchers are faced with the question of how to use scenarios and goals in a complimentary fashion. In the CREWS project, Rolland et al. have proposed the coupling of goals and scenarios in requirements engineering with CREWS-L’Ecritoire (Rolland, 1999). In CREWS L’Ecritoire, scenarios are used as a means to elicit requirements/goals of the system-to-be. Both goals and scenarios are

represented as structured text. In addition, it has long been recognised that it is good practice to analyse software or systems engineering problem from the perspectives of the various actors who must interact with the system or who have some stake in the system. The term “viewpoint” is broadly synonymous with perspective. It encapsulates partial information about a system (Sommerville and Sawyer, 1997). The principal advantages offered by viewpoints to requirements engineering are the following (Sommerville and Sawyer, 1997):  By explicitly identifying the viewpoints on a system, the union of the sets of all the viewpoints’ requirements is likely to be more complete than if the viewpoints have not been identified.  A separation of concerns if provided which permits the requirements engineer to develop a set of “partial specifications” in isolation from other (possibly competing) viewpoints. This helps to master (a problem’s) complexity; the smaller problems should be simpler than the large problem.  Traceability is enhanced by the explicit association of requirements with the viewpoints from which they are derived. 2.3 Requirements Elicitation and Elicitation Technique Selection Requirements elicitation may be the key phase of requirements engineering and possibly of the entire software process. It is an iterative process by which analysts determine the problems and needs of customers, so that system development personnel can construct a system that actually resolves those problems and addresses stakeholders’ needs (Hickey and Davis, 2003a). Even though we have made significant progress in software development, we still face some challenges that we experienced already 20 years ago: software tends to be over budget and late. And when it is delivered, its quality is below customer expectation (Jiang et al., 2005). When one investigates the reasons why projects run into difficulties, a large percentage can be attributed to bad requirements elicitation practice. Using appropriate requirements elicitation techniques during the development of a software project has the potential of making a project successful (Jiang et al., 2005). Several requirements elicitation techniques exist, e.g., interviewing, collaborative workshops, prototyping, modeling, and observation, etc (Maiden and Rugg, 1996). Zheying (2007) classifies them into four categories according to the means of communication:  The conversational methods are handy and commonly used throughout the requirements development process (e.g. Interview, Brainstorming).  The observational method provides a means to develop a rich understanding of the application domain by observing human activities (e.g. social analysis, ethnographic study).  By using the conversational methods or the observational methods, requirements are directly extracted from people’s behavior and their verbalized thought. A variety of documentation may shed light on requirements of the desired product. By studying it, engineers capture the information about the application domain, the workflow, the product features, and map it to the requirements specification (e.g. content analysis, laddering).  The synthetic methods combine different communication channels, and provide models to demonstrate the system feature and interaction. They provide good cues for requirement recognition in the form of rich semantic models (e.g. prototyping, JAD/RAD sessions). But, why does an analyst decide using one elicitation technique rather than another? According to Hickey and Davis (2003a) there are four main reasons:  It is the only one the analyst knows.  It is the analyst's favourite technique, so she/he uses it for all situations.  The analyst follows a methodology which advocates a particular technique.  The analyst thinks (intuitively) the technique is the most effective in that situation. This suggests that it is possible to improve the success of the system-to-be by selecting the requirements elicitation technique, according to the current situation. It is for this relationship between the detailed characteristics of such situations and elicitation technique selection that Hickey and Davis (2003b) introduced a new model of requirements elicitation by adding a new elicitation technique selection process to its characteristics. On the basis of these results Aranda et al. (2005a, 2005b) proposed a process which can be used to select an elicitation technique in a distributed environment. They introduced the time difference between different sites, the level of knowledge of a common language and new concepts from cognitive informatics in order to consider stakeholder’s characteristics. In this process, stakeholders’ preferences on elicitation techniques are obtained from stakeholders’ characteristics, which result from Felder-Silverman's (1988) Learning Styles Model (LSM) classification. This model classifies people in four categories, each one into two sub-categories:  Sensing / Intuitive. Sensing people have rather learning facts, while Intuitive people prefer discovering possibilities and relationships.  Visual / Verbal. Visual people remember better what they see, while Verbal people prefer explanations.  Active / Reflective. Active people understand and remember information when they do something, while Reflective people have rather thinking solely first.  Sequential / Global. Sequential people understand easier when following a step by step procedure, while Global people try to get the rough features, to find connections and discover solutions in novel ways, even if they are not always able to explain them.

For example, if a stakeholder is classified as an active people for example then the use of the prototyping elicitation technique can be visualised. Every stakeholder is classified according to a multiple-choice test (available on the WWW1). Their preference for one category has a value the measure of which is strong, moderate, or mild. A stakeholder is classified as a member of a group, only if a strong preference can be measured for him. Besides, there are many other trivial factors that influence the method selection. They are more related to a specific situation or context. The discussion does not, by any means, aspire to reject or overwrite the existing frameworks (e.g. (Byrd et al., 1992), (Maiden and Rugg, 1996)) to guide the selection of requirements development methods. Rather, we aim at providing a simple and feasible in practice alternative for requirements elicitation selection, and guidance on when a specific elicitation technique should be used.

3. MAMIE: A Methodology to Elicit Requirements for an Inter-Company Cooperative Information System In this section, we start by introducing the basic concepts of MAMIE methodology. Next, we present an overview of MAMIE, before a description of MAMIE-Tool: a tool developed in order to help analysts when applying the proposed methodology. 3.1 Basic Concepts In this section we present an overview of the concepts used in MAMIE methodology. 3.1.1 Cooperation Use Cases In UML language, a use cases diagram defines a goal-oriented set of interactions between external actors and the system under consideration. Actors are parties outside the system which interact with it. A complete set of use cases specifies all the ways to use the system, and therefore defines all required behaviors of the system (Coockburn, 1997). However, in our context we consider only cooperation activities. Thus, we define the concept of cooperation use case. In MAMIE, a cooperation use cases diagram is composed of:  Actors. An actor is a company that participates in the cooperation process.  Cooperation use cases. We define them as interdependent use cases attached to different companies, i.e. one use case depends on the other to be run. A use case included in a cooperation use case is considered as cooperation use case too (see Figure 1). CUC-1

CUC-2 Company-1



CUC-3 Company-2 CUC : Cooperation Use Case

Figure 1. A cooperation use cases diagram Thus, a cooperation use cases diagram is used in order to:  Identify and specify the goals of the system-to-be and its limits.  Relate companies to their goals.  Relate goals between them i.e. relation include between cooperation use cases. 3.1.2 Inter-Company Interaction Sequence diagram describes how groups of objects collaborate in some behavior. It shows a number of objects and the messages that are passed between them during time within the use case in order to describe a specific scenario. It also allows showing looping and conditional behaviour (Coockburn, 1997). In MAMIE, we use the sequence diagram to elicit and specify the requirements which describe a specific inter- company cooperation scenario. Compared with the previous definition of a sequence diagram:  Objects are companies participating in the cooperation process.  Messages passed between objects are delegated tasks or goals from a company to another, associated with constraints or conditions to achieve them expressed with formal (ex: OCL language) or informal way. 1

see http://www.engr.ncsu.edu/learningstyles/ilsweb.html

Thus, we use the sequence diagram in MAMIE, to highlight who is asking what and when during inter-company cooperation process. 3.1.3 Coupling Goal, Scenario and Viewpoint As we have highlighted in section 2.2, each of the concepts goal, scenario and viewpoint presents an interest to be introduced in a requirements elicitation methodology. A question may be: how is it possible to use all these three concepts within an elicitation methodology? Figure 2 shows how these concepts may be interact by using an UML class diagram. This interaction starts when stakeholders describe their goals. A goal may be a Functional Concern (FC) or a Non-Functional Concern (NFC). A FC (e.g. production of an artifact) represents a business goal; a NFC is a global property (assumption, constraint, etc.) that can influence part or the whole system (e.g. production time or production cost). FCs do not exist in isolation, they are often related to NFCs. A scenario is a textual representation which describes a possible concretization of a FC. We note that scenarios are not intended to replace requirements, but act as a carrier for creating a shared vision between analyst and stakeholders. To obtain requirements each FC or scenario is decomposed into a set of questions. A question is to be asked by the analyst to stakeholder(s) in order to cope with a particular feature of the FC. Decomposing FCs into questions ensure that all the requirements specified in order to satisfy this FC are obtained. Finally, stakeholder gives its viewpoint on how to respond to each question by considering associated NFC(s). Viewpoints contain requirements which make concrete the initial goals. A viewpoint definition should answer three main questions: why requirements are needed (Question), what system features will serve to satisfy these requirements (NFC), and how this may be done (Requirements). Stakeholder

has

1..n

1..n

Requirement

Goal

1..n

1..n

1..n

Non-Functional concern

Functional concern

1..n described by 1..n

expressed by 1..n

1..n emerges influences

Scenario 1..n decomposed into 1..n

Question

provided by

1..n

1 influences 1..n

1..n

Viewpoint

1..n

Figure 2. Goal, scenario and viewpoint interaction In our context, goals are related to companies so; the above class diagram is revised as shown in Figure 3. Company

1..n

has

1..n

Goal

Requirement

1..n attached to 1..n

1..n

Stakeholder 1..n

Non-Functional concern

Functional concern

1..n expressed by 1..n

1..n described by

1..n

1..n

emerges influences

Scenario 1..n decomposed into 1..n

provided by

Question

1

influences

1..n 1..n

1..n

Viewpoint 1..n

Figure 3. Goal, scenario and viewpoint roles in MAMIE A goal is the objective of a cooperation use case and stakeholders are those people who have a stake with the future system and attached to one or several companies. 3.1.4 Non-Functional Concerns Relationships In MAMIE, requirements result from the composition of functional and non-functional concerns. When several NFCs must be taken into account at one time, it is necessary to identify relationships between them.

The most existing approaches differentiate three types of relationships: negative (-), positive (+) or null (no contribution) ((Diaz Pace et al., 2000), (Liu et al., 2005), (Truyen et al., 2006)). The opportunity to compose NFCs depends on the type of these relationships. For example, when two NFCs which contribute negatively to each other are composed, then one NFC will influence negatively the correct working of the other. Based on relationships types among NFCs, the analyst may decide if the composition is or is not possible. The interactions between NFCs need to prioritize NFCs and to define the degree of contribution of a NFC to another one: two or more NFCs may not contribute with the same degree to a specific NFC. For example, Functionality and Aesthetics are two NFCs that contribute positively to the NFC Service quality; however Functionality ensures Service quality more accurately than Aesthetics. Thus, defining explicit knowledge about NFCs interactions may help to improve the composition process and then the requirements elicitation process. In MAMIE, we use Fuzzy Cognitive Maps (FCMs) ((Axelrod, 1976), (Kosko, 1986)) to model interactions between NFCs. This formalism is known to be used in ill-structured problems solving. A FCM is a signed graph of concepts designed to capture the causal assertions of a person with respect to a certain domain, and it is used to analyze the effects of alternative, e.g. policies, business decisions, etc. upon certain goals. FCMs allow observing the significance of each factor and its influence on other factors and the final decision (Bueno and Salmeron, 2008). A FCM without fuzzy weights is called a Cognitive Map (CM). In our case, a FCM is composed of (1) NFCs, (2) the type of relationships between them, and (3) the weights of these relationships which indicate their importance. In order to model interactions between NFCs using a FCM, we propose a process composed of three steps: (1) Identify NFCs, (2) Identify relationships between NFCs, (3) Specify the fuzzy weights and so provide the FCM. Step 1: Identify NFCs. This step consists of identifying all the NFCs of a system. NFCs can be identified using several approaches such as those used to identify goals. Good sources to guide NFCs identification are the existing catalogues (Chung et al., 2000), (Moreira et al., 2002). The analyst with the other stakeholders identifies which subset of these NFCs is applicable. Step 2: Identify Relationships Between NFCs. The objective of this step is to understand and define the relationships between the identified NFCs. When the NFCs and their relationships are clearly recognized, it is possible to establish the final CM. In order to determine relationships between NFCs, the analyst asks advices to a panel of experts. The analyst chooses experts according to their experience and background in the field. The number of experts may depend on the characteristics of the field. One of the most recent studies suggests a range of 10 to 18 to be an ideal number for each panel of experts (Bryson et al., 1997). The analyst starts by designing an initial/draft CM, either alone or with help of an expert. In order to reach consensus between experts, several techniques have been proposed (Bryson et al., 1997). Here, we adopt Delphi methodology. Delphi is used to structure the communication process within a group of experts in order to reach a consensus regarding a complex problem (Dalkey and Helmer, 1963). Delphi method is organised in two consulting rounds. The goal is to obtain consensus and get all experts to go toward the average (Bryson et al., 1997). To apply Delphi in our context, we define the following steps: (1) The first round.  The analyst gives the initial CM to all chosen experts.  The analyst asks them to check and comments the initial CM.  Experts may change the type of relationships between NFCs in the initial CM (e.g. from negative contribution to positive contribution), they may also delete existing relationships; add new relationships or new NFCs.  The analyst revises the initial CM on the basis of the answers of experts and builds a new CM. For each relationship in the new CM, the analyst determines the number of experts who issues the same evaluation. These results are collected in a table. (2) The second round.  The new CM with the table resulting from the first round are sent to experts for revision. Instructions for giving advices are the same as in the first round.  The analyst collects the results of the second round. Often, a consensus is reached either because the experts are influenced by the others in the second round, or because they have realized that their previous opinion was erroneous.  The analyst builds the final version of the CM, based on the answers of the experts. The purpose of the next step is to extend this CM to a FCM. Step 3: Specify the Fuzzy Weights and so Provide the FCM. Up to the previous step, the cognitive map has been produced. In this cognitive map, no certain strengths for casual relationships between NFCs are considered. The objective of this step is to provide such strength for the relations using the fuzzy set theory. To do so, each mutual relationship includes one linguistic fuzzy weight which determines the accuracy of the expert choice. Following Zhang et al. (1989, 1992) we use the linguistic fuzzy weights instead of real values, since they make it easier for the planners to express their beliefs. These linguistic fuzzy weights bring about a more thorough and understandable vision for the decision makers by mapping the ideas of the experts into a logic which could be processed (Klir and Youan, 2005). In order to identify the linguistic fuzzy weights, the analyst identifies the response to the following question for each relationship in the CM:

How strong the causal relationship between NFCs in the final CM is? The response to this question is an element from the following set: {Weak; Moderate; Strong; Undefined}, where Weak < Moderate < Strong. In order to express their beliefs as the strength of a certain causal relationship as being (i.e. strong, moderate, or weak) the experts assign fuzzy weights to all of the relationships in the cognitive map. The corresponding fuzzy weights range is between 0 and 1. The goal of this step is not to reach a consensus between experts, thus the analyst is not limited by any number of experts. In order to give weights to the CM, the analyst chooses a number of experts from the panel of experts who agree with the CM obtained in the previous step. The evaluations of the weight of a specific relationship may be different over experts. In order to aggregate all these evaluations, we propose to compute the average of these weights. The result may classify the strength of relationships as weak, moderate or strong. A simple view of this process is depicted in Figure 4. Identify NFCs

A set of NFCs Design the initial CM Initial CM Apply Delphi method First round

Final CM

Specify the fuzzy weights

Second round Final FCM Step 1

Step 2

Step 3

Figure 4. Modeling NFCs interactions using a FCM 3.1.5 Improvement of the Requirements Elicitation Process Quality As discussed in section 2.3, it is widely accepted that a good understanding of the suitability of requirements elicitation techniques for a given project increases the quality of requirements, which, in turn, will increase the likelihood of high customer satisfaction and improve efficiency of the requirements elicitation process. Based on recent works in requirements elicitation technique selection, we proposed in (Bendjenna et al., 2008b) a method to select an appropriate elicitation technique in a distributed environment. This method attempts to warn the problems that are likely to take place, by taking into account stakeholders’ profile and their environment. It is a phase of MAMIE methodology composed by three steps: (1) Evaluation of the current situation, (2) Detection of factors that may be source of problems and (3) Selection of an elicitation technique according to the detected problems. Step 1: Evaluation of the current situation. In this step we: 1. Identify the abstraction level of requirements according to needed requirements. Taking into account the nature of requirements on different abstraction levels, a proper set of elicitation techniques have to be chosen. For example, to identify primary benefits of a desired product (high level abstraction), conversational elicitation techniques are good option, however, to elicit product features (low level abstraction), the prototyping elicitation technique can be regarded. In our context, the abstraction level is identified by knowing the current MAMIE step and thus the level of needed requirements. 2. Identify possible sources of requirements. We distinguish two types of requirements’ sources: stakeholders and documentation. Stakeholders may be: client, end-users, expert, customer, manager, etc. Documentation includes legislation, standards, organizational structure, and characteristics of the systems coexisting with the desired system. We consider all possible sources in order to not early eliminate some elicitation techniques. 3. Evaluate time difference between sites. In order to identify the level of time difference between sites, the analyst determines throughout how many sites stakeholders are distributed? How many hours are there in a work day in their company? And how many hours overlap with each other? For example, if time difference between sites is wide enough then synchronous elicitation techniques like brainstorming or interviewing techniques may not be applied. 4. Collect information about stakeholders concerned with the current iteration of the elicitation process and their environment. In order to help the analyst collecting this information, we provide two forms inspired from (Aranda et al., 2008):  The first form, form-1 (Figure 5) contains personal information about stakeholders. such as stakeholders’ cognitive

characteristics, foreign language, etc.  The second form, form-2 (Figure 6) contains information about stakeholders’ jobs, roles, experiences and schedules. Also, it is important for the analyst to know when and how to contact other stakeholders, thus the analyst must has information about time difference between sites, working hours, lunch time, e-mail, MSN, Yahoo messenger user names if exist, etc. In this form Stakeholder’s experience defines the level of certainly of requirements issued from her/him. For example, if stakeholder has not or has little experience with the application area, then the use of elicitation technique like prototyping or interactive story boards are recognized, else, the analyst can easily start eliciting requirements with conversational methods, such as interviews. Form-1 : Stakholder’s personal information form Family Name

First Name

Gender

Nickname (optional) Initial information

Female

Male

Country of origine

Date of birth Country of residence

Years of residence

Company Writing Reading Speaking Listening

Foreign Language (mark your level of knowledge with an X)

Mild Result of FeldeSilverman test

Low

Mo derate

Low-interm

Strong

Mild

interm

Hign-interm

Moderate

high

Strong

Active Sensitive Visual Sequential

Reflexive Intuitive Verbal Global

Figure 5. Stakeholder’s personal information form Form-2 : Stakeholder’s work information form Family Name

First Name Company

Contact Information

Site Information

Numbers (1) ……………………. (2) ……………………. (3) …………………….

E-mail : (1) ……………………………… (2) ……………………………… (3) ………………………………

Instant Messaging (User name) MSN …………………………. Yahoo Messenger .…………… Skype ………………………… Others …………………………

Country

Stakeholder’s role during RE process

Stakeholder’s experience

Stakeholder’s Daily Timetable Experience (3) Arrival Time Departure Time Coffee Break Lunch Break Time I prefer to be contacted

Fax Numbers

Telephone Numbers Country Code ……City code ……. Numbers (1) ……………………. (2) ……………………. (3) …………………….

City

User

Designer

Tester

Client

Developer

Project Manager

Tuesday

Other ……………..

Time in such a position Years Months

Position

Monday

Time difference (GM)

Wednesday

Thursday

Friday

Saturday

Sunday

Figure 6. Stakeholder’s Work Information Form Step 2: Detection of factors that may be source of problems. Once all needed information about stakeholders and their

environment are collected, the problems that we expect to solve may be identified. To do so, we need to analyze the information that has been gathered in the previous step. Form-3 is proposed in order to describe a specific situation, before using it to specify a suggested technique in the next step. This form contains information about: requirements abstraction level, time difference between sites, sources of requirements, stakeholders’ experience level, their classification according to Felder-Silverman (1988) model and the possibility to use a common language between stakeholders. In Figure 9 (section 4.2.1), we have used Form-3 within the case study to analysing a situation and detecting possible problems. Step 3: Selection of an elicitation technique according to the detected problems. In the third step we suggest an elicitation technique according to the possible sources of problems detected in the previous step. The third step is composed of two sub-steps: 1. Depending on the current situation, we identify the level of applicability of the different elicitation techniques categories according to Zheying (2007) classification (see Table 1). 2. We use stakeholders’ classification issued from Felder-Silverman (1988) model to choose an elicitation technique on the basis of their preferences techniques. As we have explained in section 2.2, Aranda et al. (2005a) have linked stakeholders’ features obtained from Felder-Silverman (1988) model to their preferences on requirements elicitation techniques. Table 1 allows identifying the level of applicability of the different elicitation techniques categories. *the parameters influencing on elicitation technique selection form the situational contexts, and are listed in the left column. The elicitation techniques categories are listed in the top row of the table. Table 1. Method selection table Elicitation techniques categories Parameter

Level

Requirements abstraction level

Intermediate to high Less than intermediate Human Other Intermediate to high Less than intermediate Intermediate to high Less than intermediate Intermediate to high Less than intermediate

Requirements source Time difference between sites Common language between stakeholders Stakeholder’s experience

Conversational methods +++ ++ +++ +++ + +++ + +++ ++

Observational methods +++ + + ++ + + + ++

Analytic methods ++ ++ + +++ + + + + +++ +

Synthetic methods + +++ ++ + +++ +++ ++ +++

In this table, the levels of applicability of elicitation techniques categories are designed by: +++, i.e. Methods strongly recognize the issue and provide a means to deal with it, ++, i.e. Methods support the issues, but not as strongly as the previous ones, +, i.e. Methods address the issues, but weakly or indirectly, -, i.e. Methods do not address the issues.    

On the basis of Table 1, a set of guidelines for method selection is summarized as below: The conversational methods are applicable in almost every situation when stakeholders are people. The observational methods are less effective than the others. However, they work perfectly at the beginning of a development project to achieve the basic understanding of the physical, organizational, political and cultural environment. The analytic methods provide approaches to acquiring corporate knowledge from exiting documents and the experts. Its underlying principle is to reuse the corporate knowledge that exists in different forms. The synthetic methods are more comprehensive than any individual methods, and of course consume more resource to perform. It is always a good choice when the project resources allow. Meanwhile, the synthetic methods are effective to refine the functional requirements. After presenting the main concepts used in MAMIE methodology, we present in the next section an overview of MAMIE.

3.2. MAMIE Requirements Elicitation Methodology: an Overview MAMIE (from MAcro to MIcro level requirements Elicitation) is a methodology which aims to elicit requirements of an Inter-company Cooperative Information System (ICIS). It is composed of 3 phases. Two phases are used to identify and specify requirements that describe the macro and micro levels of cooperation between companies. In the following, we start by presenting these two phases. Phase 1 consists to elicit and specify cooperative activities and the constraints of cooperation between companies (the macro level cooperation). Two steps compose this phase. In step 1.1, the analyst starts by eliciting and modeling so-called cooperation use cases, defined in section 3.1.1. As all the following MAMIE steps, the analyst identifies firstly appropriate elicitation technique by executing the integrated phase. After identifying cooperation use cases, the analyst outlines a general description of the normal scenario and the exceptional scenarios for each cooperation use case. Each cooperation use case is described using a template (see Table 2).

Table 2. Cooperation use case template Component

Description

Name

the name of the cooperation use case brief description of the cooperation use case‘s goal Company related to the cooperation use case

Goal Company Includes

included cooperation use case

Normal scenario

specification of the primary scenario

Exceptional scenarios

specification of the other scenarios

NF.C (s)and their priority(ies)

NF.Cs that affect this use case with the priority value of each one

Viewpoints

viewpoints associated with this cooperation use case

In step 1.2, for each base cooperation use case, i.e. not included in another cooperation use case, the analyst models the interactions and the constraints of cooperation by means of a sequence diagram. This diagram represents the companies that participate in a cooperation use cases, the chronological order of needed actions to achieve the goal of the current cooperation use case with associated constraints. Phase 2 is composed of three steps. In step 2.1, each FC corresponding to a goal of a cooperation use case is associated with a set of related questions. Questions may be identified through scenarios or by decomposing FC into sub-concerns and then to a set of questions following Sommerville and Sawyer (1997). In step 2.2, for each question, the analyst identifies and specifies which NFCs must be taken into account, their relationships, and their priorities. In section 3.1.4, we have detailed how to identify NFCs and their relationships using FCMs. For each identified NFC, the analyst gives a degree of priority ϵ {1 (low), 2 (low-intermediate), 3 (intermediate), 4 (highintermediate), 5 (high)} according to the importance of this NFC. Table 3 presents a template to describe a NFC. Table 3. NFC template Component

Description

Name

The name of the NFC

Description

brief description of the NFC

Viewpoints

viewpoints requiring the NFC

Priority

according to the importance of the NFC with the current question, it has a priority value ϵ({1:very low; 2:low; 3:medium; 4:high; 5:very high})

Affect

relationship with other NFCs

Notice that the information contained in table 2 and Table 3 must be filled incrementally. For example, it is not possible to fill the rows “NF.C(s) and their priorities” and “Viewpoints” until we have NFC(s) and viewpoints are specified. However, at the end of the process all the rows should be filled. Step 2.3 consists to identify and specify viewpoints which contain requirements. The questions identified in step 2.1 are the focuses of viewpoints and the NFCs are the drivers of the requirements elicitation. Requirements are the result of the composition of each FC with as set of NFCs. More precisely, the requirements are the response to each question associated with the corresponding NFCs. Based on Sommerville and Sawyer (1997) and Charrel (2002) viewpoint’s definition; we have proposed a template of 7 components for a viewpoint presented in Table 4. MAMIE attempts in advance to avoid possible sources of problems that might take place in a distributed requirements elicitation process, by suggesting the appropriate elicitation technique using collected information. This is the goal of the third phase that corresponds to the method detailed in section 3.1.5. It returns suggested elicitation technique (s) according to the current situation. Figure 7 illustrates MAMIE methodology steps. At the end of MAMIE process, the future system is organized in terms of a set of ordered viewpoints which contain requirements issued from initial business goals.

Table 4. The viewpoint template Component

Description

Name

identifies the viewpoint

Question (focus)

perspective taken by the viewpoint

NF.C(s)

List of NF.Cs applied to the viewpoint

Cooperation use case Source(s) Requirements

The cooperation use case relevant to the viewpoint Sources of viewpoint’s requirements requirements associated to this viewpoint

History

alterations of the viewpoint information

To conclude, MAMIE involves 3 levels of abstractions:  A coopeartive step is an atomic unit of activity inside the cooperative process. It is concerned with one question and the concept of viewpoint is used to describe it;  A cooperative process is a process meant to orchestrate the execution of a specific aspect of the cooperation between companies. We use in MAMIE, a sequence diagram to describe this level;  A cooperative framework which represents a set of inter-communicating coopeartive processes. A cooperation use cases digaram is used to describe it. 3.3 MAMIE-Tool Tools make a significant contribution to the requirements formulation process (Dorfman and Thayer, 1991). Their incorporation or support in methods improves the analyst’s ability to manage the complexity associated with requirements collection, structuring, verification, consistency checking and integrity preservation. Tool support becomes even more important when the set of requirements grows, and may change. To this end, we have developed MAMIE-Tool which aims to provide support to MAMIE methodology from the initial step through to detailed requirements specification. Figure 8 shows a screen dump provided by MAMIE-Tool during applying MAMIE to our case study. The underlying principle of MAMIETool is to implement the class diagram presented at Figure 3 in section 3.3 that shows how goal, scenario and viewpoint may interact each other. To do so, it is built around a data base that collects information about cooperation use cases, NFCs and viewpoints identified during requirements elicitation process. MAMIE-Tool helps the analyst to specify, save and restore cooperation use cases, NFCs and viewpoints which contain the requirements of the future system. They are organised as a tree in which the first node the project name. In this tree, a cooperation use case included in another cooperation use case is a subnode of it. Using viewpoints to encapsulate requirements allows associating a rationale and a source for every requirement with a reference to related quality attributes, i.e. NFCs. Other important functionalities have been added to MAMIE-Tool like the identification of viewpoints and requirements related to a NFC having a specific degree of priority. We have added these options in order to help the analyst at the requirements analysis step, the next step of the requirements engineering process. Specification of Micro-level cooperation

Specification of Macro-level cooperation

Identification and specification of viewpoints

Identification and specification of cooperation use-cases (FCs)

Identification and specification of inter-company interaction

Identification and specification of NFCs

Identification of question related to FCs

Elicitation Technique Selection

Evaluation of the current situation

Detection of factors that may be sources of problems

Figure 7. MAMIE steps

Selection of an elicitation technique according to the detected problems

Figure 8. MAMIE-Tool interface In the next section, we apply MAMIE methodology to a case study from the textile industry.

4. A Case Study In order to illustrate MAMIE methodology, we apply it to an example from the textile industry. In this example, a group of distributed specialized companies wish to cooperate together in order to reduce cost, time and investment in the production of a range of textile products. This group of 5 participating companies, their locations and the time difference between their sites and Greenwich Meridian (GM) are the following:  The fiber producer company (Morocco, GM- in summer GM+1) ;  The knitting mills and weaver company (France, GM+1-in summer GM+2);  The dyer and finisher company (France, GM+1-in summer GM+2);  The designer company (Spain, GM+1-in summer GM+2);  And the manufacturer company (Italy, GM+1-in summer GM+2). The analyst who is in France applies MAMIE methodology to elicit requirements for the future ICIS. Before applying MAMIE, we give in the next section outlines on the textile industry field. 4.1. Description of the Field The textile industry is one of the largest industries in the world (Wu and Chang, 2003). The first step of the textile production process is carried out by people responsible for product development and the planning of entire collections. At this stage market research is carried out, and advice is sought, with a view to deriving the knowledge required to adapt product lines to market demand. Criteria of profitability are applied to the making of preliminary decisions about the anticipated life cycle of these products and the steps that would be involved in continuing to make, modify or replace them. The second step is the design and prototyping of new models. Stylists sketch new models. Designers create detailed models of the different parts (collars. sleeves, cuffs, etc.) of the item of clothing. A production design department determines how each part is to be made, establishes quality standards for each part, determines how the product is to be assembled and costs the item. Then, fibers are combed and carded, and short fibers are removed. Fibers are drawn out into long pieces that look like rope to make them stronger. Many different kinds of textile workers run the machinery that does this work. They feed and start the machines, stop them, clean them, and repair broken fiber ends. Frame spinners operate machines that spin the fiber into yarn. These machines draw out and twist the ropes of fiber into yarn, which is wound around cones called bobbins. Frame spinners manage rows of spinning frames. They twist the fiber ends, repair breaks in the fiber ropes, and clean the machines regularly. Once the fibers have been spun into yarn, the yarn is ready for weaving or knitting. These are two different processes that require different kinds of machinery and are usually done in separate plants. Most textiles are woven. Several different kinds of workers prepare the yarn for weaving. They include loom winder tenders, spooler tenders, warper tenders, slasher tenders, and warp tying machine tenders. These workers place the yarn on the machines and thread it into place. They tie yarn ends and monitor the machines to make sure they are running properly. When the yarn is finished, they remove it and send it on to the weavers. Weavers are skilled workers who sometimes run as many as 200 looms at a time. The looms weave or interlace the yarn at right angles to make woven cloth. Sometimes there are as many as 2,000 looms in a single weaving room. The

weavers watch the looms, fix breaks in the cloth, and repair minor problems with the looms. Major repairs or adjustments are made by loom fixers (Wu and Chang, 2003). 4.2 Applying MAMIE Methodology In the following sub-sections, we apply MAMIE methodology to the case study. The results of the elicitation technique selection phase are detailed only for the first step, i.e. Identification and specification of cooperation use-cases. 4.2.1 Specification of Macro-level Cooperation The goal of this phase is to elicit and specify cooperation use cases and cooperation scenarios between companies. Its result is: (1) a cooperation use cases diagram where each cooperation use case is described by using a template and (2) a sequence diagram. Identification and specification of cooperation use-cases. The analyst starts by identifying an elicitation technique to be used according to the current situation. Form-3: Current situation, proposed strategy and stakeholders’ feedback Iteration: 1

Identification and specification of cooperation use cases

MAMIE step Requirements abstraction level Time difference between Sites

Low-interm

Low High-interm

Intermediate X High

Low-interm

X Low High-interm

Intermediate

High

X Stakeholders Stakeholder

O. Alberto

Fiber producer Knitting mills and weavers Dyer and finisfer Designer

B. Anna

Manufacturer

S. Karim Source of Requirements and Suggested elicitation technique

Company

D. Pierre A. Michel

Experience in the area

Classification Sub-category

High

Sensing

High

Sensing

High

Intuitive

High

Reflective

High-interm

Sequential

Suggested technique Structured interview Structured interview Open-ended interview Questionnaire Open-ended interview

Others ………………………………………………………....... Suggested technique …………………………………….. Possibility to use a common language

X Intermediate

Low-interm

Low High-interm

High

Figure 9. Current situation and proposed strategy form To do so, the elicitation technique selection phase is executed. In Figure 9, we summarize the result of the elicitation technique selection phase by using Form-3. Let us comments this from for the 3rd stakeholder, i.e. A. Michel. According to recommendation of Table 1, when:  Requirements abstraction level is high;  Time difference between sites is low;  Possibility to use a common language is intermediate;  Stakeholder’s experience is high. Then, using a conversational elicitation technique is regarded. A. Michel’s classification sub-category is intuitive which means that he prefers discovering possibilities and relationships. Thus, according to Aranda et al. (2005(Aranda et al., 2005), an open-ended interviewing technique is strongly recommended. In this technique questions are not early prepared and fixed. After applying the recommended elicitation technique and by analyzing the initial requirements, the analyst identifies cooperation use cases. We model and document them by using a cooperation use cases diagram (see Figure 10) and a template for each cooperation use case. 5 cooperation use cases have been identified and related to companies which will provide the service. In Table 5, the cooperation use case Manufacture Product is used as an example. Identification and specification of inter-company interaction. In this step, we start by identifying from the cooperation use case diagram, the base cooperation use cases. Here, the manufacture product cooperation use case is the only one. Let us recall that the information contained in Table 5 must be filled in an incrementally way. For example, the field viewpoints cannot be filled until viewpoints are specified in the last step.

Manufacture Product

Manufacturer

Design Product

Designer

Dey and finish fabric Dyer and Finisher Knit and weave yarn Weaver and Knitter

Produce Fiber

Fiber Producer

Figure 10. Cooperation use cases diagram Table 5. Manufacture product cooperation use case Component

Value

Name

manufacture product

Goal

It identifies in general way how to manufacture a textile product? Manufacturer Design Product, Dey and finish fabric, Knit and weave yarn, Produce Fiber The Manufacturer requests from the designer a design for a new product with specific characteristics. The Dyers and Finishers company receives product design and the related constraints from the Manufacturer to perform this command. if the Designer can’t meet the command there, it may send another proposal to the Manufacturer. Product cost (5), product Quality (3)

Company Includes Normal Scenario

Exceptional Scenarios NF.C (s) and their Priority(ies) Viewpoints

Manufacturer

Designer

related viewpoint

Dyer and Finisher

Weaver and Knitter

Fiber Producer

DesignProduct() {product’s cost and quality}

(1)

Product’s design FinishProduct() ProduceFabric()

{Product’s design, Quantity/ Time}

ProduceFiber() {Constraints}

{Constraints}

(3) Fabric OK

(4) Product OK

Figure 11. Cooperation process between companies

(2) Fiber OK

Next, the sequence diagram is used to describe how the involved companies cooperate to achieve the goal of this cooperation use case. We have identified 10 concerned stakeholders. In order to elicit requirements, the analyst starts by identifying the appropriate elicitation technique. After evaluating the current situation and detecting possible problems, the workshop elicitation technique is suggested. In this technique, stakeholders are gathered together for a short but intensely period so as to create requirements. Figure 11 sketches a simple version of the scenario that describes the cooperation process between companies to achieve the goal of the manufacture product cooperation use case. In Figure 11 cooperation activities are indicated with thick lines whereas thin lines are used for cooperation activities calls. There are four cooperation activities in Figure 11: (1) design product, (2) produce fiber, (3) Weave and knit product and (4) dye and finish product. In this scenario, the process starts by a request sent by the manufacturer to the designer to design a product by taking into consideration the constraints of cost and quality. The scenario ends by receiving the textile product from the Dyer and finisher after whole a cycle. 4.2.2 Specification of Micro-level Cooperation This phase aims to return a set of ordered viewpoints which contains requirements that describe the micro level of intercompany cooperation. To obtain them the following steps are executed. Identification of questions related to FCs. In this example all cooperation use cases are included directly or indirectly in the manufacture product cooperation use case. Thus, only the goal i.e. FC of this cooperation use case will be decomposed into a set of questions. Using the sequence diagram in Figure 11, 11 ordered questions have been identified. These questions are identified from the four cooperation activities existing in Figure 11. They are shown in level 1 at Figure 12. Level 0

Manufacture Product

Level 1

How to design product? (Q1) How to prepare fibre? (Q2) How to warp yarn? (Q3) How to slash yarn? (Q4) How to weave yarn? (Q5) How to knit yarn? (Q6) How to prepare fabric? (Q7) How to dye fabric? (Q8) How to finish fabric? (Q9) How to cut fabric? (Q10) How to sew fabric? (Q11)

Figure 12. Questions related to the manufacture product cooperation use case Identification and specification of NFC (s). For each identified question, this activity look for NFC (s) which must be taken into account with this question, their relationships and priorities. In order to identify NFCs and their relationships, we apply the process presented in section 3.1.4. 3 experts participated to this process. They early obtained consensus. This may be due to the simplicity of the case or to their experience in the field. As an example, 5 NFCs have been identified with the question how to design product?: product cost, product quality, aesthetics, competitiveness and comfort . In Figure 13, we present the FCM which models relationships between these NFCs. In this FCM, we may notice for example that reducing the product cost will increase the competitiveness but will decrease the product quality and thus product aesthetics and comfort. Thus, it is difficult to ensure at the same time a product with a low cost and a high quality. In our case, companies give more importance to the product cost than the product quality. Also, product aesthetics and product comfort do not contribute with the same degree to the product quality. Indeed, product comfort is more important to the product quality than the product aesthetics. Making explicit such knowledge is an advantage of using a FCM to model NFCs relationships. Besides, a NFC may be considered with a specific question and not with another. Each NFC is described using a template. The NFC product cost is used as an example in Table 6. Competitiveness

+ moderate

Product quality

+ moderate + moderate

- moderate Product cost

+ strong

Product aesthetics

Product comfort

Figure 13. NFCs interactions Once NFCs and their priorities identified for all questions, NFC(s) and their priority(ies) field may be filled in Table 5. The priority value of a NFC within a cooperation use case is the result of dividing the sum of its priorities values over the questions associated with this cooperation use case, by the number of these questions. For example, product cost is a NFC

taken into account in the 11 questions, resulting from the manufacture product cooperation use case. It has a high priority (=5) in all these questions. Thus, its priority within this cooperation use case is 5*11/11=5 (high). Table 6. Product cost NFC Component

Value

Name

Product cost actions performed in the production cycle should take into account the reduction of the product cost.

Description Question

how to design product? (Q1)

Priority

high (5)

Affect

(- moderate) Competitiveness

Identification and specification of viewpoints. Each question resulting from the previous step is a focus of a viewpoint. For illustration, in Table 7, the question (Q8) is used with the NFC product cost. Thus, requirements of the future system are the result of composing each question incrementally with the associated NFC(s). 11 viewpoints contain these requirements. Table 7. The dyers viewpoint Component

Value

Name

Dyers

Question ( Focus) NF.C(s) Cooperation use case Source(s)

how to dye fabric? (Q8) Product cost dye and finish fabric S. Patrick

Requirements

- Dyers shall modify rinsing procedures and becks - reduces water costs. - Dyers shall replace sodium sulfate with sodium chloride - reduces sulfate emissions below effluent standards and reduces chemical costs. - Dyers shall use Data color instrument to control process - reduces chemical use.

History

created on 15 January 2010 at 11H00

Figure 14 shows a screen dump of MAMIE-Tool when dyers viewpoint is created.

Figure 14. Adding a new viewpoint using MAMIE-Tool

4.3 Discussion Currently, many companies fail in the execution of strategic outsourcing. Eliciting requirements in a distributed environment can become a tough task if the process is not well defined and the teams are not experienced or prepared for this cooperation model. Key points which emerge from MAMIE evaluation are:  Integrating an elicitation technique selection process within an elicitation methodology, using specific forms to obtain information about stakeholders and evaluating the current situation show a positive result. It provides a practical starting point to select appropriate elicitation technique.  Stakeholders’ satisfaction may be assessed through their implication within the requirements elicitation process, their feedback and also the number of requirements that are changed or added over the elicitation process.  Requirements elicitation is more effective when stakeholders participate actively in synchronous activities (e.g. Interviews, brainstorming) that are supported by voice conferencing.  Goals, scenarios and viewpoints interact in a logical complementary way, where each concept plays a specific role: goals describe the macro-level of requirements; scenarios are used to describe the medium-level of requirements; whereas viewpoints describe the micro-level of requirements. Thus, scenarios may be considered as a means that allows going from a macro-level to a micro-level of requirements. We may note also the frequent involvement of stakeholders during the elicitation process in order to identify goals, scenarios and viewpoints. This helps to make requirements more stable.  Detecting inconsistencies between different viewpoints’ requirements in the next step of the RE process is difficult when the number of requirements increases. In order to simplify this task, viewpoints’ questions may be used as a guide to whether two viewpoints’ requirements are likely to interact. If their questions intersect (i.e. impose requirements which influence the same components of the system or its environment), then associated requirements should be checked for consistency. Thus, it can be seen that the salient features of our methodology are:  Explicit integration of the three concepts goal, scenario and viewpoint to cope with the limitations of existing approaches based on one of these concepts.  It links up the business goals (what?) to the individual goals (how?), which will increase the quality of elicited requirements.  It provides a system's analyst with a support to choose the most appropriate elicitation technique according to a specific situation.  It supports well known concepts (viewpoint, goal, etc.) and modelling notations (UML diagrams), rather than inventing new ones. Thus, the analyst is not required to learn about new concepts and notations to deal with it.

5. Related Works With the rise of inter-company cooperative information system, comes the great challenge in developing them successfully. Despite a wide variety of literature on whether and why to outsource, there is still a lack of research on how to achieve successful inter-company cooperative information system development. Requirements elicitation in a distributed environment has been a subject for researchers’ investigation. Most of the effort in distributed requirement engineering has been focusing on facilitation techniques (Macaulay, 1999), (Brodie and Seri, 1992). The nature of asynchronicity and stakeholders’ distribution in distributed environment has also been studied in ((Damian and Zowghi, 2002), (Damian et al., 2003)). And the impact of culture on facilitation and negotiation has been dealt in (Macaulay, 1999). In (Geisser and Hildenbrand, 2003), the authors have proposed a method that covers collaborative requirements elicitation in a distributed environment as well as quantitative decision support for distributed requirements prioritization and selection. However, these studies unanimously deal with distributed elicitation activities using traditional techniques and methods that are not accurately suitable for eliciting requirements of inter-company cooperative information system. However, all studies deem distributed requirements elicitation possible and even favourable compared to collocated approaches. In (Rolland et al., 2007), the authors proposed a goal driven approach to understand the needs of different organizations for a new added value composite service and to model the cooperative process supporting this service. The goal model called Map, is then used for service elicitation, distribution and orchestration. Thus, this approach is service-based and does not deal with low level requirements. Moreover, most existing methods do not address non-functional concerns explicitly, and those that address them have tended to address them as secondary to the ‘central’ issue of functional concerns. Existing methods lack support for the broad integration of functional and non-functional concerns. Effectively, the requirements elicitation process is often carried out through two independent cycles, one regarding the functional aspects of the system and the other the non-functional aspects. Since we consider them as dependent cycles we propose to establish convergence points between both cycles. Through the use of these convergence points we can express in the functional view all the actions and data that will be necessary to satisfy the non-functional view. Based on the analysis and evaluation of existing researches, we have proposed MAMIE methodology to elicit requirements for an inter-company cooperative information system. Using goals, scenarios and viewpoints as described by the class diagram in section 3.1.3 allows integrating non-functional concerns within functional concerns. In MAMIE, we don’t proposed to use specific elicitation techniques, but an elicitation technique is the result of a process that starts by evaluating the current situation before suggesting an appropriate one.

6. Conclusions and Future Works Our research has two related primary objectives: (1) to overcome the limitations of the current requirements elicitation methodologies for an inter-company cooperative information system, (2) to enhance the requirements elicitation process by providing guidance in selecting elicitation techniques. A set of global factors cause various threats that are specific to distributed environment. The survey results show that requirements elicitation in a distributed environment is one of the essential challenges that shall be paid adequate attention. This may be due to several issues like separation of stakeholders, diversity between processes, inconsistency in practices, linguistic and terminology differences, temporal distance etc. This makes practitioners to seek for new approaches and practices to be implemented in global projects for better performance. One of the main contributions of MAMIE methodology is coupling together goals, scenarios and viewpoints. Thus, requirements which do emerge from MAMIE methodology exhibit a high degree of completeness and consistency and, crucially, will embody the principal companies’ goals. Fuzzy cognitive maps used to model non-function concerns relationships is a very convenient, simple, and powerful tool, which is used in numerous fields. To obtain consensus for a final cognitive map between experts, Delphi method is used. The other main contribution of MAMIE is the integration of an elicitation technique selection phase in order to help analysts to choose an appropriate elicitation technique. To do so, specific forms are designed. They allow evaluating the current situation and detecting possible problems before proposing an elicitation technique. Furthermore, we consider stakeholders’ cognitive aspects. This is important since stakeholders might feel more comfortable when using a tool closer to the usual way they perceive and reason about the world. In summary, MAMIE methodology is based on well known concepts, thus an analyst will not spend time to learn about new concepts. It may be considered as a useful contribution to the field of requirements elicitation in a cooperative distributed environment. MAMIE methodology is a part of a project which deals with whole the requirements engineering process involved in the development of an inter-company cooperative information system, from requirements elicitation until their validation to deal with adapting requirements engineering processes for distributed environments. Thus, our future work will focus on the analysis of requirements which result from MAMIE methodology. Besides of, we plan to:  Apply MAMIE methodology on other industrial case studies in order to gain additional empirical evidence.  Integrate the forms used in the elicitation technique selection phase within MAMIE-Tool.  Transform MAMIE-Tool on a web-base tool.

Acknowledgements This research is partially supported by the PHC TASSILI project under the number 10MDU817. Many thanks go to the participants at MAMIE evaluation. We also thank the anonymous reviewers for providing valuable comments.

References Alencar, F., Silva, C., Lucena, M., Castro, J. F. B., Santos, E. and Ramos, R. A. (2008), “Improving the understandability of i* models”, 10th International Conference on Enterprise Information Systems, pp.129-136, Barcelona, Spain. Antón, A. I., Dempster John, H. and Devon, F. S. (2000), “Managing Use Cases During Goal-Driven Requirements Engineering: Challenges Encountered and Lessons Learned”, 22nd International Conference on Software Engineering. North Carolina State University Technical Report, TR-99-16, December 1, 1999. Limerick Ireland. Aranda, G., Vizcaíno, A., Cechich, A. and Piattini, M. (2005a), “A Cognitive-Based Approach to Improve Distributed Requirement Elicitation Processes”, 4th IEEE International Conference on Cognitive Informatics (ICCI 2005), Irvine, USA. Aranda, G., Vizcaíno, A., Cechich, A. and Piattini, M. (2005b), “A Cognitive Perspective for Choosing Groupware Tools and Elicitation Techniques in Virtual Teams”, ICCSA conference, LNCS Springer, Vol. 3480, pp. 1064-1074. Aranda, G., Vizcaíno, A. Cechich, A. and Piattini, M. (2008), “Strategies to minimize problems in global requirements elicitation” CLEI electronic journal, vol.11, N°1, paper 3. Axelrod, R. (1976), Structure of Decision: The Cognitive Maps of Political Elites”, Princeton University Press, Princeton, NJ. Bendjenna, H., Zaour, N. and Charrel, P.J. (2008a), “MAMIE: A Methodology to Elicit Requirements for an inter-company cooperative information system”, Innovation on Software Engineering conference (ISE), Vienne, Austria. IEEE conference, ISBN 13: 978-0-7695-3514-2, pp 290-295. Bendjenna, H., Zarour, N., Charrel, P.J. (2008b), “Enhancing the Elicitation Technique Selection process in a Cooperative distributed Environment”, REFSQ’08, France (Montpellier). LNCS Springer, vol.5025 pp.23-36. Boughzala, I. Chikhi, F. and Youcef-Boughzala, H. (2004), “A cooperative workspace for an extended enterprise”, European & Mediterranean conference on Information System, Tunisia.

Brodie, M-L and Seri, C. (1992), “On intelligent and cooperative information systems”, International Journal of Intelligent and Cooperative Information Systems, Vol.2, No.2, pp. 249-290. Bryson, N., Mobolurin, A. and Joseph, A. (1997), “Generating consensus fuzzy cognitive maps”, Intelligent Information Systems journal, Vol.8, No.10, pp.231-235. Bueno, S. and Salmeron, J. L. (2008), “Fuzzy modeling Enterprise Resource Planning tool selection”, Computer Standards & Interfaces journal, Vol.30, No.3, pp. 137-147. Byrd, T. A., Cossick, K.L. and Zmud, R.W. (1992), “A Synthesis of Research on Requirements Analysis and Knowledge Acquisition Techniques”, MIS Quarterly journal, Vol.16, No.1, pp.117-138. Charrel, P. J. (2002), “The viewpoint Paradigm: a semiotic based approach for the Intelligibility of a Cooperative Designing Process”, Australian journal of Information Systems, Vol.10, No.1, pp.3-19. Cheng, B.H.C. and Atlee, J.M. (2007), Research Directions in Requirements Engineering, Future of Software Engineering, IEEE Computer Society Washington, pp. 285-303. Chung, L., Nixon, B., Yu, E. and Mylopoulos, J. (2002), Non-Functional Requirements in Software Engineering, Kluwer Academic Publishers. Colombo, E. and Francalanci, C. (2004), “A methodology to design cooperative information systems within districts”, International workshop en Web Engineering, Greece august. Cockburn, A. (1997), “Structuring Use Cases with Goals”, Journal of Object-Oriented Programming, Vol.1, No.1, Sep-Oct. Coughlan, J. and Macredie, R. D. (2002), “Effective communication in requirements elicitation: A comparison of Methodologies”, Requirements Engineering journal, Vol.7, No.2, pp. 47-60. Dalkey, N. C., Helmer, O. (1963), “An experimental application of the Delphi method to the user of experts”, Management Science journal, Vol.9, No. 3, pp. 458-467. Damian, D. and Zowghi, D. (2002), “The impact of stakeholders’ geographical distribution on managing requirements in a multi-site organization”, IEEE Joint International Conference on Requirements Engineering, RE'02, Essen, Germany pp. 319-328. Damian, D., Eberlein, A., Shaw, M.L.G. and Gaines, B. R. (2003), “An exploratory study of facilitation in distributed requirements engineering”, Requirements Engineering journal, Vol.8, No.1, pp.23-41. Diaz Pace, J. A., Trilnik, F. and Campo, M. R. (2000), “How to handle interaction concerns?”, Workshop on advanced for separation of concerns in OO Systems, OOPLSA, Minneapolis, USA. Dorfman, M. and Thayer, R. H. (1991), Requirements definition guidelines, and examples on system and software requirements engineering, IEEE Computer Society Press. Estrada, H., Rebollar, A. M., Pastor, O. and Mylopoulos, J. (2006), “An Empirical Evaluation of the i* Framework in a Model-Based Software Generation Environment”, CAiSE’06. LNCS 4001, pp.513-527. Felder, R. and Silverman, L. (1988), “Learning and Teaching Styles in Engineering Education”, Engineering Education journal, Vol. 78, No.7, pp.674-681. Gans, G., Jarke, M., Kethers, S., Lakemeyer, G., Ellrich, L., Funken, C. and Meister, M. (2001), “Requirements Modeling for Organizations Networks: A (dis)trust-based Approach”, IEEE International symposium on Requirements Engineering (RE’01). Geisser, M. and Hildenbrand, T. (2003), “Advanced Software Engineering: Expanding the Frontiers of Software Technology”, IFIP International Federation for Information Processing, Vol.219, pp. 108-122, Boston- Springer. Herbsleb, J. D. and Moitra, D. (2001), “Global Software Development”, IEEE Software journal, Vol. 18, pp. 16-20. Herbsleb, J. D. (2007), “Global Software Engineering: The Future of Socio-technical Coordination”, International Conference on Software Engineering: Future of Software Engineering (FOSE'07), Minneapolis, IEEE Computer Society, pp.188198. Hickey, A.M. and Davis, A. (2003a) “Elicitation Technique Selection: How do experts do it?”, International Joint Conference on Requirements Engineering, California, IEEE Computer Society Press, pp.169-178. Hickey, A.M. and A. Davis (2003b), “Requirements Elicitation and Elicitation Technique Selection: A Model for Two Knowledge-Intensive Software Development Processes”, IEEE Annual Hawaii International Conference on Systems Sciences, pp. 96-105. Jarillo, C. (1988), “On Strategic Networks”, Strategic management Journal, Vol. 9, No.1, pp. 31-41.

Jiang, L., Eberlein, A. and Far Behrouz, H. (2005), “Combining Requirements Engineering Techniques — Theory and Case Study”, 12th IEEE International Conference and Workshops on the Engineering of Computer-Based Systems (ECBS'05), pp.105-112. Kanellis, P. and Paul, J. (1997), “On the Nature of Inter-Organisational Information Systems and the Issue of Adaptability”, Thirtieth Annual Hawaii International Conference on System Sciences ISBN 0-8186-7862-3, pp. 391-397. Klir, G. J. and Youan, B. (2005), “Fuzzy Sets and Fuzzy Logic”, Theory and Prentice Hall, India. Kosko, B. (1986), “Fuzzy cognitive maps”, International Journal on Man-Machine Studies, Vol. 24, pp. 65-75. van Lamsweerde, C. (2001), “Goal-Oriented Requirements Engineering: A Guided Tour”, Proceedings RE’01, 5th IEEE International Symposium on Requirements Engineering, Toronto, pp. 249-263. Liu, J., Batory, D. and Neduniry, S. (2005), “Modeling interactions in feature oriented systems”, International Conference Feature interactions (ICFI), UK. Macaulay, L. A. (1996), Requirements Engineering, Springer-Verlag London. Macaulay, L. A. (1999), “Seven-layer of the role of the facilitator in requirements engineering”, Requirements Engineering journal, Vol.4, No.1, pp.38-59. Maiden, N. and Rugg, G. (1996), ”ACRE: Selecting Methods for Requirements Acquisition”, Software Engineering Journal, Vol.11, No.5, pp. 183-192, 1996. Mishra, D. and Mishra, A. and Yazici, A. (2008), “Successful requirement elicitation by combining requirement engineering techniques”, First International Conference on the Applications of Digital Information and Web Technologies, pp.258-263, Ostrava. Moreira, A., Araújo, J. and Brito, I. (2002), “Crosscutting Quality Attributes for Requirements Engineering”, 14th International Conference on Software Engineering and Knowledge Engineering, ACM Press, Italy. Paché, G. (1993), L’entreprise en réseau, Presses Universitaires de France, Paris. Potts, C., Takahashi, K. and Anton, A. I. (1994), “Inquiry-based requirements analysis”, IEEE Software journal, Vol. 11, No.2, pp. 21-32. Powell, W. W. (1990), “Neither market nor hierarchy : Network Forms of organisation”, research in Organizational Behavior journal, Vol. 12, pp. 295-336. Rolland, C., Grosz, Gbh. and Kla, R. (1999), “Experience With Goal-Scenario Coupling In Requirements Engineering”, Proceedings of the IEEE International Symposium on Requirements Engineering, Limerick, Ireland. Rolland, C., Kaabi, R. S. and Kraeim, N. (2007), "On ISOA: Intentional Services Oriented Architecture", International Conference on Advanced information Systems Engineering (CAISE), Springer-Verlag, Norway. Sommerville, I. and Sawyer, P. (1997), Requirement Engineering- A Good Practice Guide, John Wiley and Sons,. Truyen, F., Joosen, E., Loughran, W., Rashid, N., Jackson, A., Nedos, A. and Clarke, S. (2006), “Study on interaction issues”, AOSD-Europe Deliverable 44. Wiegers, K.E. (2003), Software Requirements, 2nd edn. Microsoft Press. Wu, C. C. and Chang, N. B. (2003), “Global strategy for optimizing textile dyeing manufacturing process via GA-based grey non-linear integer programming”, Computers and Chemical Engineering, Elsevier journal, Vol.27 pp.833-854. Yu, E. (1995), “Modelling strategic Relationships for Process Reengineering”, PhD thesis, university of Toronto Canada. Zhang, W. R., Chen, S. S. and Bezdek, J. C. (1989), “A generic system for cognitive map development and decision analysis”, IEEE Transactions on Systems journal, Vol.19, No.1. Zhang, W. R., Chen, S. S., Wang, W. and King, R. (1992), “A cognitive-map-based approach to the coordination of distributed cooperative agents”, IEEE Transactions on Systems, Vol.22, No.1. Zheying, Z. (2007), “Effective Requirements Development - A Comparison of Requirements Elicitation Techniques” Software Quality Management journal, pp. 225-240.