{'fraction_non_alphanumeric': 0.02418720034348687, 'fraction_numerical': 0.007895427331059322, 'mean_word_length': 5.095376562954347, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 5, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
A model for the elicitation of organizational system interoperability requirements

Introduction: this article is the product of the research called a framework to support the elicitation of interoperability requirements (IR) based on the needs of an organization’s business processes, developed at the Universidad del Cauca in 2019. Problem: within the requirements elicitation process, stakeholders generally fail to articulate IR according to the business needs, causing the development of systems incompatible with systems in other functional areas. Objective: to identify, define and classify a set of attributes that constitute the interoperability at the business level, which must be considered during the elicitation of an IR. Methodology: the development of the model followed these activities: (i) establishment of the aspects to be considered in the interoperability at the business level, (ii) identification of the attributes that make up each aspect, (iii) definition of the identified attributes and the options that can be obtained in response, and (iv) classification of the attributes. Results: a model that describes 21 attributes that constitute the interoperability at the business level, classified in the following views: emitters and receivers, types of interaction, data flow properties, and conditions to use the communicated data. Conclusion: from the application of the model in the elicitation of a set of IR of two functional areas of an organization, it was identified that the attributes favor the common understanding among members of different areas and support the analysis and planning of the exchanges of information. Originality: to identify and define a set of attributes that constitute interoperability at the business level. Limitations: the model must be used by a process that guides the elicitation of the attributes that make up the IR.


INTRODUCTION
Organizations are changing from a vision of management by functional areas, to a vision of management by business processes transversal to the areas [1], therefore they assume as a challenge a coordinated integration of their business processes, human resources and ICT involved in the delivery of a product or service [2] [3]. At the same time, organizations want to facilitate, optimize and improve collaborative work interactions in their internal and external business processes [4].
In integration and collaboration projects, there must necessarily be interoperability as a quality attribute [5] [6], which is defined by ISO/IEC 25010 [7] as the ability of 2 or more systems to exchange information and use the information exchanged.
better understanding of the business factors and problems that influence its deployment [14] [15].
During the development, acquisition or improvement of the systems that make up the business processes of an organization, a fundamental stage are the activities of elicitation, analysis and specification of interoperability requirements (IR) [16] [17], understanding an IR as a need for exchange and use of information among systems, which within an organization can be: organizational roles, groups of people, functional areas, software or hardware. [17]. This stage is critical because it ensures that the systems have a common understanding of the information shared and are also aligned to the information use and exchange needs of the different stakeholders (end users of the business, management users of the organization, technical users, regulatory authorities) [18] [16] [19], however, from the reviewed literature, it has been possible to note that few works address it, and moreover, there is no systematic analysis on the associated business aspects [20] [21] [16] [22].
In this regard, within the elicitation of requirements, stakeholders generally fail to articulate IR according to business needs, because business analysts 1 focus on technical aspects of solutions instead of systematically conducting a holistic analysis of the interoperability and its relationship with aspects of the business [19] [23]. This Ingeniería Solidaria e-ISSN 2357-6014 / Vol. 16, no. 3 / 2020 / Bogotá D.C., Colombia Universidad Cooperativa de Colombia practice results in the development of isolated systems, frequently incompatible with the systems of other functional areas and inconsistent with the information use and exchange needs of business processes [24] [25] [26]. In turn, these systems give rise to information silos [13] [27], which occur when the functional areas of an organization do not share information or their communication is inefficient [28] [29][30] [31].
Considering the previous scenario, this article presents a model that describes the attributes that constitute interoperability at the business level, which are characteristics to consider during the elicitation and specification of an IR. The attributes were obtained from an analysis of e-business and e-government interoperability frameworks, business processes, and proposals presenting IR examples. As a result of the research, a total of 21 attributes were obtained, classified in the following views: emitters and receivers, focused on addressing the components of the emitters and receivers of the information; types of interaction, focused on establishing the number of emitters and receivers involved in the communication and whether the communication is within or outside the functional emitter area; data flow properties, focused on determining the characteristics of the data flow among emitters and receivers; and conditions to use the communicated data, focused on the aspects to be taken into account by the receivers when using the communicated information.
The model has been used as the basis for the development of a framework that guides, at the business level, the elicitation and specification of IR that can occur among the systems that make up the business processes of an organization. In this way, the attributes of the model allow us to establish what an analyst should consider when identifying and documenting interoperability requirements. On the other hand, the IR at the business level are considered as a starting point in determining and developing the aspects that must be addressed at the lower levels of interoperability corresponding to processes, services and data.
This article is organized as follows: section 2 presents the related works, section 3 explains the research method used to build the model, section 4 describes the views of the model and the attributes that make up each view, and section 5 shows the application of the model in 2 functional areas of an organization. Finally, the conclusions and future work are presented.

RELATED WORKS
In order to identify, categorize and analyze proposals that consider aspects that must be addressed in interoperability at the business level, a systematic review of the literature was carried out following the approach proposed by Kitchenham [32]. As a result, e-ISSN 2357-6014 / Vol. 16, no. 3 / 2020 / Bogotá D.C., Colombia Universidad Cooperativa de Colombia A model for the elicitation of organizational system interoperability requirements 3 types of work were obtained: (i) e-government and e-business frameworks that propose guidelines, classified at various levels, on how organizations should communicate, (ii) proposals that identify and describe aspects to consider in interoperability at the business level and (iii) proposals that establish how to capture IR.
In regard to the identified frameworks, they propose the concept of interoperability at the business level, establish guidelines that must be considered at this level and describe the relationship between levels. Some frameworks are the I 2 F developed by the US [33] which classifies interoperability into 6 levels: business, data, applications and systems, infrastructure, security and performance; the EIF developed by the European Union [34] which classifies interoperability at 4 levels: technical, semantic, legal and organizational, and FIE [35] which classifies interoperability at 4 levels: data, services, processes and business, and transversal, it states that the conceptual, technological and organizational perspectives must be addressed at these levels.
Regarding proposals that address particular aspects that are presented at the business level, in [14] are evaluated a set of aspects in order to establish the degree of interoperability among companies, in [36] are identified a set of characteristics that must be considered in collaboration planning and in [21] is presented a definition of IR and identified, described and classified in 7 categories a set of aspects to consider during the exchanges of information among companies, in [37] is proposed a method to establish the characteristics of organizational interoperability using business modeling according to the following points of view: functional (functions performed by the emitting and receiving systems), decisional (decisions of the systems), information (information to be exchanged and its structure) and the processes of business (links among actors in terms of products and information). From the review of this type of proposals we identify that they focus on proposing general aspects that must be addressed at the business level, but do not establish the attributes that make up the level, a definition of each of them and the possible values that could be assigned to them. This leads to the conclusion that there is currently no common definition of interoperability at the business level and a systematic analysis of the attributes involved at this level is lacking.
From the perspective of IR capture we find proposals such as [2], [38] and [39] that establish a series of steps to identify needs for information exchanges and subsequently convert them into IR. Mainly they propose: (i) to define a set of basic principles in order to avoid communication problems among stakeholders, (ii) to establish and understand business processes, (iii) to identify instances of business cases in which interoperability is necessary , (iv) to identify actors, applications and systems that are involved (v) to analyze each business case confronting the current situation and Ingeniería Solidaria e-ISSN 2357-6014 / Vol. 16, no. 3 / 2020 / Bogotá D.C., Colombia Universidad Cooperativa de Colombia a planned scenario. Other approaches used are the one proposed by [36] in which, from a set of questions it is determined whether an IR should be considered and the one from [17] where they propose a repository of IR derived from a bibliographic analysis on interoperability and a survey conducted in the industry, as a guide to early identification of other IR. The proposals analyzed converge in that the analysis of an IR must start from the business, however, the proposed approaches lack a clear, complete and systematic guide to identify IR analyzing the interactions and information exchanges that occur in business processes, involving stakeholders and considering the attributes of interoperability at the business level.
Due to the relevance of the results found, a framework has been developed to support the elicitation and specification of IR from the business perspective, which is made up of 3 components, as seen in Figure 1. The first component is the model described in this article, which presents in 4 views the attributes that from the business perspective should be considered in an IR; the second component is a process that establishes how to elicit IR; and the third component is a guide for the specification of IR made up of templates where the values of the attributes that make up an IR, syntax rules, conditions and considerations to verify compliance with quality characteristics such as completeness, correctness, consistency among others are registered. In this sense, the framework aims to guide analysts in the following activities: (i) recognition and understanding of the context of the problem, (ii) selection and modeling of the business process from which the IR are elicited, (iii) identification of the RIs, (iv) establishment of the attributes that make up each RI, (v) representation in a formal document the attributes that make up each RI and (vi) validation and verification of the RIs.

RESEARCH METHOD
The action research method was used to define, redefine and apply the proposed model. According to McKay and Marshall [44] and Chiasson et al. [45], action research involves a research cycle and a problem-solving cycle in which knowledge is applied and discovered interactively among activities with different objectives and results.
Each of these cycles includes at least the following phases: problem diagnosis, action, and reflective learning [46]. In our case, a research cycle was carried out with the aim of developing an initial version of the model, then a problem-solving cycle was carried out in which the model was applied in two functional areas of an organization in order to elicit a set of IR. The knowledge gained from the problem-solving cycle was used in the subsequent research cycles to refine and improve the model, thus creating a new version. Taking these aspects into account, Figure 2 shows a high-level view of the research method along with the interaction of the elements involved. Along these lines, the research cycle used to develop the model followed the activities shown next, classified according to the phase to which they belong:

Diagnostic phase
To select sources from the literature from which to identify the attributes: a set of proposals were selected that allowed the identification of the attributes that constitute interoperability at the business level. The proposals chosen were those that characterized interoperability from different levels. As a result, 5 E-business interoperability frameworks were obtained (*EBIF), IDEAS [40], ISO/IEC 11354 [12], ATHENA [38], FEI [35] and GridWise [41]; 3 E-government interoperability frameworks (*EGIF), I 2 F from U.S. [33], EIF from the European Union [34], and e-GIF from the United Kingdom [42], and proposals such as [14], [21] and [37] that address interoperability from a business and organizational perspective (*BOP).

To establish the aspects to consider in interoperability at the business level:
from a complete reading of the selected proposals, 17 aspects were established that must be addressed at the business level. The aspects found and the proposal that formulates them are shown in Table 1.

Action phase
To identify the attributes from the literature: each aspect was analyzed in order to identify if it is made up of several attributes or if the aspect itself is an attribute. As a complement, an analysis of various business processes and proposals that present- ed IR examples was carried out, such as [17], [36] and [43], seeking to identify new attributes from the perspective of a real environment..
To create the definition of the attributes: the attributes identified in the previous activity and the possible options in response were defined using the sources determined in the diagnostic phase and the following references in the literature: BPMN [44], distributed systems [45][46], organizational communication [47] and organizational structure [48].

Assessment phase
To classify the identified attributes: the attributes identified by their characteristics were grouped into 4 views: emitters and receivers, types of interaction, properties of the data flow, and conditions for using the communicated data.

MODEL FOR THE ELICITATION OF ORGANIZATIONAL SYSTEM INTEROPERABILITY REQUIREMENTS
The proposed model identifies, defines and classifies a set of attributes that constitute interoperability at the business level. Each attribute represents a characteristic of the information flow among the systems that make up the business processes of an organization, which can be organizational roles (people), groups of people (organizational organisms), functional areas, software or hardware.
In this sense, the proposed attributes can be used to establish what an analyst should consider when elicits and specifies an IR from the business perspective. To propose open attributes such as those that give the analyst the possibility to answer them freely and closed ones that provide a certain set of options as response. Figure   3 shows the views of the model and the number of attributes that each one has.

View of emitters and receivers
The view defines 6 attributes that represent the components of the emitters and receivers involved in an IR. The emitter is the one who sends a data object and the receiver is the one who receives a data object, having in mind that a data object rep-

resents communicated information. If the communication is between organizations
Ingeniería Solidaria e-ISSN 2357-6014 / Vol. 16, no. 3 / 2020 / Bogotá D.C., Colombia Universidad Cooperativa de Colombia or within an organization, the emitters and receivers are made up of 5 attributes, figure   4 shows the attributes and the relationship between them, each one is described next: A5-O-A. data repository: represents a repository that stores physical documents or digital information, from which the information to be sent will be consulted or where the received information will be stored.

A1-Ob-
On the other hand, communication can also occur between a functional area of an organization and an external person, whether the organization has the role of emitter and the person that of receiver or vice versa. In this case the attributes (A1 to A5) will make up for the organization and the attribute A6 will represent the external person.

A6-O-A. External individual:
corresponds to a person external to the organization who exchanges information with a functional area of an organization.  Recommendations: • The analyst must consider that communication can occur between organizations, between functional areas of an organization, within a functional area or between an organization and an external person.
• If communication occurs between organizations, the analyst must identify attributes A1 to A5 for each organization; if it is between functional areas of an organization, he must identify the organization and the attributes A2 to A5 for each area; if it is inside a functional area, he must identify the organization, the functional area and the attributes A3 to A5 for each area; and if it is between an organization and an external person, he must identify attributes A1 to A5 for the organization and attribute A6 for the external person.
• Attribute A1 is mandatory because if the details of the emitter or receiver are not known, at least the name of the organization must be identified.

View of interaction types
The view defines 2 attributes, the first one establishes the number of emitters and receivers involved in the communication and the second one if the communication is   The single transmission multilateral interaction type has the following subtypes: a) Send one to many: an emitter sends messages to several receivers. All messages have the same type, but the message information may be specific to the recipient.
b) Receive many to one: a receiver receives a number of logically related messages that arise from autonomous events that occur at different emitters.
The arrival of the messages must be timely so that they can be correlated Recommendations: • The analyst, when selecting a type of interaction, must consider whether the emitters or receivers are known during the design of the business process in which the IR exists or only get to know each other when the flow of activities of the business process is executed.
• If the emitters and receivers know each other, the attributes that compose them must be identified (attributes A1 to A6 from the emitters and receivers view).

View of data flow properties
The view defines 10 attributes that must be considered in the flow of data between the emitters and receivers present in an IR. Figure 6 shows a representative graph of the view, in which the data flows between an emitter and two receivers have a set of attributes that characterize them. Next each of the attributes and the possible options that they may have as an answer are described:  Figure 6. Representation of the attributes present in the data flows between an emitter and two receivers.
reference: the authors.

A1-Ob-A. data object:
A data object represents the information sent between emitters and receivers; it can be physical artifacts like an invoice or letter, or electronic artifacts like an email, a file to be opened by software, or a request in a format for data exchange such as JSON or XML. A data object is made up of 4 aspects: (i) a short and meaningful description of the information that the emitter is going to communicate (ii) whether the sender needs a response, (iii) languages used in the information that the sender will communicate, (iv) languages of the response.

A3-Ob-c. Types of communication to send information:
When transmitting a data object to a receiver, the following types of communication can be used: • Verbal communication, is the process in which data objects communicate through oral signs or spoken words, it requires that the receiver listens to the transmitted data object to understand its meaning.
• Written communication, is the process in which data objects communicate through written codes, it requires that the receiver reads the transmitted data object to understand its meaning.

A4-Ob-c. Types of communication channels to send information:
When transmitting a data object to a receiver, the following communication channels can be used: • Face to face, are channels in which the emitter is in the same physical location as the receiver. Some channels may be, project meetings, annual performance reviews, among others.
• Electronic bidirectional remotes, are channels in which the emitter and receiver are not in the same physical space, but can receive real-time information between them. Some channels can be videoconferences, group wares, phone calls, chats, among others.
• Electronic unidirectional remote, are channels in which the emitter and receiver are not in the same physical space, and the message can be heard or seen by the receiver at any time. Some channels can be voicemail, podcasts, videos, among others.
• Hand written documents, are channels that involve the data object being hand written such as a letter, reports, request forms, minutes.
• Electronic written documents, are channels that involve the data object being written electronically such as an email. does not require human assistance [21].

A8-O-c. Type of synchronization in the communication of a data object:
When transmitting a data object to a receiver, one of the following types of synchronization can be used [46]: • Synchronous emitter: it appears when the emitter is blocked while the result of a request arrives.
• Asynchronous emitter: occurs when the emitter is not blocked while the result of a request arrives or because it does not expect a result.
• Synchronous receiver: Occurs when the receiver is blocked while processing the data object and sends back the result of a request.
• Asynchronous receiver: Occurs when the receiver is not blocked while processing the data object or sends back the result of the request Blocking, is understood as when the emitter or receiver cannot execute another activity.

A9-O-A. Shared meaning of the data object: During communication, an un-
equivocal interpretation of all the shared information is required, assuming that the vocabulary and concepts used by the emitter and receiver are interpreted correctly and clearly, therefore it is necessary to define: (i) codes of the formats used to capture the data objects to be exchanged, (ii) codes of the formats used to capture the results, (iii) name of the organization's internal policies that regulate the data object to be exchanged or (iv ) national and international laws or regulations imposed by the authorities that govern the information to be exchanged..

A10-Ob-A. Business objective:
During communication, the following must be defined: (i) the business objective that supports the exchange of information and (ii) what is the type of business objective, these may be official, operational or specific.

Recommendations:
• Analysts should consider that a data object may be made up of other data objects.
• The purpose of a data object is leaned to communicate information or documents, request information or require access to a resource.

View of conditions to use the communicated data
The view defines 3 attributes, each one of them is associated to cases that emitters and receivers must consider when using the communicated information. Figure 7 shows a representation of the data flow that gets to the receiver, along with a series of cases to use the information. Each of the attributes is described below:

Receiver
Is it available?
Is it correct?

P2
Does it have the mandatory elements? Figure 7. Representation of the cases that the receiver must consider in order to use the information received.
reference: the authors.

A1-Ob-A. Procedure when the information received is not correct:
The measures to be followed by the receiver should be established when the information received: (i) has incomprehensible parts or (ii) has incomplete parts.

A2-O-A. Mandatory elements to accept the information received: the follow-
ing elements must be defined so that the receiver can use the information communicated: (i) approvals made by other functional areas or (ii) data generated by other functional areas.

A3-O-A. Procedure when the information is not available:
The measures to be followed by the emitter must be established when: (i) the requested information arrives after the moment it is needed or (ii) the receiver cannot provide the requested information.

EXPERIENCE REPORT
The description of the experience report regarding the application of the model has been organized taking into account the indications for structuring the experience reports recommended by [50]. In this regard, the following subsection describes this report in terms of: the context of the implementation, the description of the A model for the elicitation of organizational system interoperability requirements participating organization, the report and the analysis of the use of the model by the organization, lessons learned and limitations of the application.

Implementation context
The model has been implemented in the elicitation and specification of a set of IR corresponding to two functional areas of an organization, by executing the corresponding problem-solving cycle from action research. For each IR the proposed attributes have been discussed, analyzed and answered by the stakeholders that make up the areas.
IR elicitation was carried out from a set of business processes in each area, and was conducted by the framework components described in section 2.3. Elicitation was conducted by a business analyst who had previously been trained in the basic concepts of interoperability, model views, and the IR elicitation framework. Her profile describes her as a junior software systems analyst, with experience in interviewing for obtaining requirements, specifying requirements and creating business process models.

Characteristics of the organization and business processes
Here we will focus on an introduction to the characteristics of the organization and the areas involved in applying the proposed model. The organization corresponds to a public, autonomous, of the national order higher education institution, with 192 years of existence and with High Quality Institutional accreditation. The areas involved in the application of the model were document management and institutional planning and development called AF1 and AF2 respectively, their main characteristics are: • AF1: aims to receive, file and redirect files sent to the different academicadministrative units of the organization. The business process from which the IR were identified was "Filing of correspondence documents", which was not documented.
• AF2: aims to program, prepare and approve the general budget of the organization, complying with internal and external regulations and guaranteeing the sustainability of the institutional finances. The business process from which the IR were identified was "Preparation of the institutional budget", which was modeled using the BPMN notation. The two areas were selected because they exchange information with multiple areas of the organization. Furthermore, the members of the functional areas have a great interest in identifying, defining and improving the attributes associated with the exchange of information with other areas. The members' profile shows little experience in interacting with organizational analysts and in using business process models.

Planning for the implementation of the model
The implementation of the model aimed to determine if the information that makes

Report and analysis of the work carried out in the organization
In this subsection we present an overview of the implementation of the model in the two functional areas, based on the number of IR elicited, the number of attributes used to constitute the IR, the benefits and problems when responding, and the opportunities for improvement identified for the model.

Results
From the implementation of the model, 11 IR were elicited, 6 correspond to AF1 and 5 to AF2. In each IR all the attributes suggested by the model were discussed and their application justified by the members of the organization based on business A model for the elicitation of organizational system interoperability requirements processes, but some attributes were not considered due to the particular nature of the activities carried out by the areas. Table 1 shows some IR, the first two correspond to AF1 and the last 3 to AF2.
The level of difficulty in applying the model was considered average, since the researchers noted that the members of the emitting areas easily identified the type of interaction, the type of data flow, the components of the emitters and most of the attributes of the data flow, but they had difficulties defining the components of the receivers and interacting collaboratively with members from other areas in order to agree on the attributes of each IR. Based on the actions carried out by the members of the areas and the analysis of the specified IR, the following difficulties were established during the response to the information requested by each of the attributes that constitute the IR.

View of emitters and receivers
• In each IR, the members of the emitting area easily identified the components of the emitter because they knew in detail who sent the information; regarding the recipient, they only identified the name of the organization or receiving area. To solve this problem, it was necessary to link members of the receiving areas to the elicitation process in order for them to identify the components of the receivers and, together with the members of the emitting area, collaboratively agree on the other attributes of each IR.  • In some IR, such as number 5 of table 2, the receivers of the information were not predefined, that is, they only knew each other when executing the activities of the business process, therefore, the receiver was considered a black box . In this case, the members placed as components of the receiver a distinctive name to the organization and / or receiving area.

View of interaction types
• For the members of the areas, it was easy to select the type of interaction and the type of data flow due to the set of options proposed by the model.
• The bilateral single transmission interaction and data flow between functional areas were the most selected options, although this result is due to the nature of the business processes involved in capturing IR.

View of data flow properties
• The members of the organizations indicated that the defined attributes allowed establishing agreements between the emitters and receivers in order to generate a common understanding of the information communicated, establish communication rules, and justify the communication. They highlighted that some attributes associated with common understanding are A1, A3, A4, A7, A9, the attributes associated with establishing communication rules are A6 and A8, and the attributes associated with justifying the exchange are A2 and A10.
• During the specification of the IR it was noted that 80% of the mandatory attributes were responded correctly. Some difficulties of the members when answering the attributes were the following: in the attribute A1, sometimes in the description of the information to communicate, they added the purpose of the issuer when sending the information, which is incorrect because they must be separated in different descriptions , and in attribute A10 it was difficult for them to determine the business objective and the difference between the types of business objectives.
• During the specification of the IR it was noted that 20% of the optional attributes were correctly identified. The little use of these attributes by the members is due to the following reasons: in attribute A6, in some IR,

View of conditions to use the communicated data
The attributes proposed in this view allowed the members of the emitting and receiving areas to reflect on what actions to take when the information is not correct or lacks mandatory elements. Mainly the areas established the following actions: • They defined which area to request the incorrect information or which is missing mandatory elements.
• They identified the communication channel, type of communication and format to be used to report errors in the information received.
• They determined whether it was necessary to notify a specific area about anomalies in the information received in order to monitor the quality.
• They established what steps to follow when the requested information is not provided by the recipient.

Aspects to improve in the model
Along with the learning and reflection by the areas, the group of researchers in charge of creating the model obtained the following opportunities for improvement, classified according to the view to which they correspond:

View of emitters and receivers
• In cases where the emitters or receivers only get to know each other when the information is to be sent, add an observation to the model that establishes that the emitters or receivers must be identified by a distinctive name.

View of interaction types
• When types of interaction involving multiple senders or receivers are presented, it must be considered whether the data flow between each emitter-receiver pair has a set of unique attributes proposed by the view of Data Flow Properties.

View of data flow properties
• In the attribute A1 add an item that allows the members to add a short and meaningful description of the information that the receiver sends in response.
• In attribute A2 add an item that allows adding the receiver's purpose to the members when sending a response.
• In attributes A3 and A4 allow to use multiple channels and types of communication.
• In attribute A3 add a new type of channel associated with communication between machines through software services, for example, web services, remote methods, remote procedures, micro-services, among others.
• Change the A10 attribute as optional because the members do not consider it a priority and it also takes a long time to write the business objective.

View of conditions to use the communicated data
In attribute A1 add an item that allows establishing actions when the information received does not have the mandatory elements such as approvals made by other functional areas or data generated by other functional areas.

Discussion
The two areas that participated expressed the following about the attributes proposed by the model: (i) they were a complement to the message flows embodied in the business processes, (ii) they favor a common understanding between members of different organizations and (iii) support the analysis and planning of information exchanges. The researchers observed that the model is adequate to identify the message flows during the construction of the business processes, it allows establishing the guidelines that directs the message flow and helps to establish what aspects to consider when using the information communicated. From these experiences in real Later, we will highlight some aspects of the application of the model, first in terms of the lessons learned by the organization and the researchers, and then in terms of the limitations of the results and conclusions.

Lessons learned.
Some relevant lessons learned that can be extracted from the implementation of the model are: • Addressing interoperability at the business level from different points of view, helped the members of the organizations to identify the message flows during the construction of business processes, to establish the guidelines that directs the flow of messages and the aspects that they should consider when using the information communicated. write each attribute and the process to elicit the IR.
• The members of the functional areas know the information exchanges between the areas, they perceive that the exchanges are made up of a set of characteristics, but they do not know what characteristics to identify, how to identify them and how important they are to generate a common understanding • The identification of the attributes that make up an IR must be carried out collaboratively between the members of the areas that emit the information and the members of the areas that receive the information because a mutual agreement between them is required. In this sense, collaborative work should be guided by an analyst who knows the different levels and perspectives from which the interoperability and attributes of the proposed model can be addressed.
• In order to automate certain information exchanges and increase response times, the members of the areas perceive it as important that requests for information among areas of an organization are made through software systems that automatically notify when there is a response. In

Limitations of the evaluation and its management
When implementing the model, 3 limitations were identified: the lack of knowledge about the importance of interoperability and its characteristics by the members of the areas, the short time for the implementation of the model, and the few participating areas; In order to reduce its impact, the following strategies were implemented: • In order for all the members of the two areas to show an equitable knowledge of the concepts of the model, a presentation was carried out of the following topics: (i) the most relevant concepts on interoperability and the problems addressed, (iii) the attributes proposed in the present model along with an example of an IR where they were applied, and (iv) the process to elicit IR.
• Since the time for the implementation of the proposal was 4 hours, it was agreed with the participants to carry out two sessions of two hours each, in the first one the business process was modeled and the IR were identified, and in the second the attributes composing each IR were identified, additionally the templates for the specification of the IR were presented in a spreadsheet in order to minimize the time for completion.

CONCLUSIONS AND FUTURE WORK
This paper presents a model that describes the attributes that constitute interoperability at the business level, which were obtained from an analysis of electronic business and electronic government interoperability frameworks, business processes and proposals that present examples of IR. As a result of the research, a total of 21 attributes were obtained, which describe different aspects that must be considered when an IR is elicited and specified from the business perspective. The model has been used as the basis for the development of a framework that guides, at the business level, the identification and documentation of interoperability requirements that may arise among the systems that make up the business processes of an organization The construction of the model was carried out through a research cycle in which the following activities were conducted: selection of a set of proposals that characterized interoperability; establishment of the aspects to consider in interoper- processes with the interoperability and the use of energy resources in order to develop environmentally sustainable systems; and the attributes that constitute interoperability at the process, service and data level. As a result of the analysis, the creation of a model that describes the dependencies between the attributes of the different levels of interoperability and a methodology to elicit IR that considers all levels is proposed.
Finally, other problem-solving cycles solving are considered using the case study method, in order to increase the thoroughness of the application of the proposed model, to establish in greater depth the scope and limitations of the model, and to increase the reliability of the results obtained and conclusions drawn. In this way, from a representative set of case studies, the evaluation, adjustment, improvement and validation of the proposed model will continue.

ACKNOWLEDGMENTS
We appreciate the assistance of the following projects: "Framework to support the elicitation of interoperability requirements based on the needs of an organization's business processes" and "Current situation of software requirements engineering in the southwestern of Colombia" respectively identified with ID 5039 and ID 4828 of the vice-rectory of research of the Universidad del Cauca.