SciELO - Scientific Electronic Library Online

vol.26 número4Gestión de la sostenibilidad portuaria basada en un modelo de redes bayesianas. Aplicación al sistema portuario españolEstudio de rugosidad por análisis de Fourier de las toberas de inyectores en sistemas riel común (CRDI) índice de autoresíndice de materiabúsqueda de artículos
Home Pagelista alfabética de revistas  

Servicios Personalizados




Links relacionados

  • En proceso de indezaciónCitado por Google
  • No hay articulos similaresSimilares en SciELO
  • En proceso de indezaciónSimilares en Google


Ingeniare. Revista chilena de ingeniería

versión On-line ISSN 0718-3305

Ingeniare. Rev. chil. ing. vol.26 no.4 Arica dic. 2018 


Reference Model for the Integration of Business Modeling to Requirements Engineering: A Proposal from the Software Industry

Modelo de Referencia para la Integración del Modelado de Negocio a la Ingeniería de Requisitos: Una Propuesta desde la Industria del Software

María Claudia Bonfante1 

Luis Alfredo Blanquicett1  * 

Enrique Díaz Infante2 

Cesar Guerra García3 

1Facultad de Ingeniería, Corporación Universitaria Rafael Núñez, Cartagena, Colombia. E-mail:;

2Sysnet Ltda, Cartagena, Colombia. E-mail:

3Universidad Autónoma de San Luis Potosí, San Luis Potosí, México. E-mail:


The vast majority of existing techniques and methods used in Requirements Engineering are not concerned with understanding and representing business processes; Which means that these techniques are more oriented to the specifications of the systems and not to the business as such. This article proposes a reference model of integration between business modeling and requirements engineering, which is supported by data collection records, which allow documenting software development with a process approach. The main contribution of the work is that it can be considered as good practice in software development processes to meet the strategic objectives of the business and meet the needs of customers.

Keywords: Business modeling; product modeling; scheduling process; BPMN; IPS


La gran mayoría de las técnicas y métodos existentes utilizados en la Ingeniería de Requisitos no se preocupan por comprender y representar los procesos del negocio; lo que quiere decir que estas técnicas están más orientadas a las especificaciones de los sistemas y no al negocio como tal. Este artículo propone un modelo de referencia de integración entre el modelado del negocio y la ingeniería de requisitos, el cual esta soportado por registros de recolección de información, que permiten documentar el desarrollo software con el enfoque hacia procesos. La principal contribución del trabajo, es que puede ser considerado como una buena práctica en los procesos de desarrollo de software para cumplir con los objetivos estratégicos de los negocios y cubrir las necesidades de los clientes.

Palabras clave: Modelado del negocio; modelado del producto; proceso agendamiento; BPMN; IPS


Before starting the development of software, it is essential to identify and discover the domain of information and activities immersed as part of a business process, in order to understand the purpose and to make a correct specification of requirements. A process model captures relationships that are meaningful to the business between the different organizational concepts, such as activities, resources used by the activities, and human or automated actors who carry out the activities 1.

The modeling allows to clearly define the domain of the organization, elements, objects, and subsystems that integrate it, which will allow to creatinge systems based on entities that represent to the organization and not an arbitrary abstraction of information. Therefore, process modeling is used as a basis for specifying key system requirements, facilitating the identification of ideas to improve the current structure of the business and its operation; And the most important thing is that they allow the new work proposal to be presented to the process managers in a tangible and concrete way 2, In this way, business process modeling will help discover opportunities for design and automation of tasks or Eliminate the unnecessary ones before starting the development phase; guaranteeing the maintenance, consistency and flexibility of the applications, facilitating interoperability with the external customer and their complete satisfaction.

According to 3, incomplete requirements is the most common factor that influences on the failure or cancellation of software projects, and this is due to the fact that analysts do not identify properly the requirements focused on the business processes that takes a client organization. Therefore, there is no clarity in the specification of requirements that leads to the visibility of processes, handling exceptions and errors, saving time and reducing costs, and hence the increase in efficiency of business operations.

This article proposes a model that can be taken as a good practice to remedy the problem of specification of requirements, starting with good integration of the management of business processes toward the specification of software requirements, in such a way that the processes identified in the enterprise can be deployed in software applications.

The article is structured as follows, section 2 starts by explaining the way in which it has been using process modeling and the notation used to do this, section 3 presents the main phases of Requirements Engineering briefly. Section 4 shows the proposed model of integration between the two approaches. Section 5 explains the description of the different phases of the model. Through its application in a real business process of Scheduling for a group of IPS (Service Delivery Institutions) beneficiaries of the research project “Integration platform for the provision of services and follow-up plans for health in the job. “funded by Colciencias de Colombia in Call for 2015 and executed by the firm Sysnet. Finally, some conclusions of this work are shown in section 6.


Business Modeling is considered, in most methods of contemporary software development, as the first phase or technical process of software development 4 For this reason, it should be the first technical process that a work team should be followed during software development. Business modeling is composed of a set of related elements: objectives, processes, activities, objects, actors, organizational structure, rules and business events. The business objects, in particular, are all those concrete or abstract entities that characterize the system of business.

It is understood as Business Process the “set of activities that take one or more types of inputs and create an output that is of value to the customer”. (5 defines it as “a set of activities that are driven by events and executing them in a certain sequence, these activities create value for a client”. The interesting thing about the concept is that, due to the nature of organizations, most of the time they can deal with processes that include customers, who may be geographically distributed, and that on many occasions their systems have been designed in different platforms; In this way, it becomes more complex the form of integration of these processes to measure or evaluate them, and validate if they meet the strategic objectives, thus facilitating decision making.

The Business Process modeling is a network of graphic objects corresponding to activities and flow controls that define the order of execution of these. The main elements of the BPMN notation essentially present tasks, events and the doors of the process.

Previous studies have integrated modeling of the business to the first model of software; 6 present a proposal focused to a business context on demand based on MDA (Model Driven Architecture) and SOA (Services Oriented Architecture), its recommendations focus on the early stages related to the modeling of the business until the early model of software. The main part of these models focuses on the description of strategic business processes, using the basic principles of BPM (Business Process Modeling).

The authors 7 present a generic framework for organizations that develop software for oriented companies to the process; Its leading focus is using RUP (Rational Unified Process) and UML. Also, 8 in his book proposes to use RUP as a Software Development Methodology, which in its initial phases considers the business processes. The Business Modeling, which is carried out with greater emphasis on the conceptual phase of the methodology (RUP), It has as aims to understand the structure, the dynamic of the organization, current problems, identify possible improvements and understand the processes 9.

On the other hand, 10 carry out a comparative analysis of life cycle methodologies of software development that involving Business Processes and Web Services, the study considers the analysis of nine methodological proposals mainly on the part of the Scientific sector more than the Business Sector, all of them selected as they provided the necessary minimum information to be able to apply the analysis according to the development of systems considering Business Processes and Web Services through various stages.


The requirements engineering can be defined as the most important phase and greater care of software engineering, which defines the properties and functionalities of the software product 11.

The phase of Requirements engineering is without doubt fundamental, since if the team in charge for the development of the software does not know the requirements of the product. The percentage of success to obtain the expected and quality results are low, not to mention the high costs to repair defective products or of inferior quality products; In addition to assuminge the cost of canceled projects and the cost of having lost the opportunity to have the right product at the right time 12.

According to 11, the main activities carried out during the process of specification the requirements are: obtaining requirements, requirements definition, verification of requirements and validation of requirements specification. See Figure 1.

Figure 1 Requirements Development. 

Immediately, is defined briefly each of the main activities:

Obtaining requirements

[11] It defined it as the process of identifying the needs of the business, solving the possible disparities between the people involved in the same, with the purpose of defining and distilling the requirements to comply with the restrictions imposed by the different parties. A proper development process for obtaining requirements begins with the analyst who receives the request or requirements personally using techniques for collecting information such as interviews, meetings and questionnaires. Once the requirements are obtained and the analyst checks if the requirements are clear, complete, consistent and unambiguous.

Definition of requirements

To ensure that the requirements clearly defined can be a complex task. To do this, it is necessary to take into account the following considerations 13 a) Necessary: What is requested is required for the proper functioning of the system that is going to develop. B) Consistent: No requirement may conflict with another requirement. C) Complete: They contain in themselves the necessary information. D) Achievable: A realistic goal that can be achieved with the resources available. E) Verifiable: Their compliance can be measured. F) Documentation: The requirements must be described correctly and unambiguously.

Verification of requirements

In this activity, the end user adds acceptance criteria for each requirement. In addition, with the support of the analyst pair it is checked that the requirements must be correct before they are delivered to the designers and developers. For this phase the analyst uses a concept called “quality gate”, which is the point by which each of the requirements passes before being part of the specification 12.

The task of the “quality gate” is to ensure that each requirement meets the criteria assigned to it; wWhich is a measure of the requirement that makes it understandable and with the ability to be approved, also through the quality gate can prevent requirements leaks, ensuring the project team have a complete control in the specification of these.

During the review the requirements must be classified according to their Complexity (three levels high, medium and low), Priority (critical, relevant and useful), Class (New / Requirement, Change / Failure and Improvement) and Type O Non-functional); This classification must be indicated in the Requirements Matrix registry and the specification of the software requirement 11.

Validation of Requirements Specifications

When you make a door of quality- efficient requirements, you can have confidence in the correctness and feasibility of requirements. As soon as the validation of the specifications of the requirements is complete, you will have a precise knowledge of the scope and functionality of the product. In this validation, it is verified that there is no lack of requirement on the part of the client. Also, the analyst must ensure that the requirements have consistency, and otherwise, that any conflict between requirements has been solved. According to 14 two requirements are in conflict if they cannot be implemented together, that is, if the solution to one requirement prevents the implementation of another.


This section presents the Reference Model proposal. This model is integrated firstly by the Business Modeling phase, as business processes increase the level of automation, identifying in greater detail the needs of the applications And business users, as well as facilitates the work for software developers.

The other phase is the Product Modeling, where the requirements analysis and the application design are performed, both from business process diagrams generated in each phase and validated by software analysts and those interested in the product of Software in the organization. Figure 2 shows the integration of both phases and the activities that compose it.

Source: “The authors”.

Figure 2 Reference Model for the Integration of Business Modeling to Requirements Engineering. 


In order to explain each phase of Business Modeling, the processes of a Health Services Provider (IPS) will be taken as reference. These companies provide medical check-in and check-out services for hired or hired personnel, including audiometry, Spirometer, electrocardiogram, psychology, clinical laboratory, among others. The large volume of information generated is handled in very basic files and in many cases in physical, which generates inconveniences for monitoring and control. The absence of reliable and systematized data on the health status of workers is a major problem because of the significant economic and social loss caused by accidents and diseases of occupational origin. The lack of adequate and complete information prevents health authorities and employers from making decisions to reduce risks, prevent accidents and diseases, and foster a culture of self-care.

In order to achieve greater understanding, we will immediately describe each of the activities involved throughout the Reference Model.

Process Architecture

Through the Process Map, the processes and their classification, derived from the objectives and strategies previously defined by the client organization, are represented. Three main processes were identified in three IPSs involved in the project.


In this process appointments must be assigned so that the employees and candidates are served in the IPS. The information that is kept is related to the data of the employee or candidate, his/her professiograma, the exams that will be practiced to him, the type of examination, and the position of the patient.

Customer Service

In this process the IPS receives the employees or candidates, and applies the corresponding examinations according to the position and generates the reports to be presented to the contracting company.


Through this process, the IPS invoices the orders of service rendered to its clients during a specified period of time.

Survey of Business Processes

Once the business processes have been identified, it is proposed to use a template shown in Table 1 which allows the collection of relevant information from the Customer Management process identified in the process diagram of Figure 3.

Table 1 Template for Process Description Scheduling. 

Source: “The authors”.

Figure 3 Scheduling Process Diagram. 

The elements of the template are Mission Process: A name must be placed that identifies the important process for the provision of company services. Objective: To describe the object of the business process broadly. Scope: Explicitly describe how far the process is. Responsible. Company charges that are the owners of the process. Input and Output data of the process. Indicators: It is a reference that allows to measuringe the effectiveness and efficiency of the process, such as time, processed records, etc. Clients: They are interested in the process both internal and external. Rules: These are controls or validations that must be made on data during the execution of the process; And finally, Process Resources:

They are the elements as external databases, or computer services that the process requires.

In addition to the above, the activities of the process are described as shown in Table 2. Activity Name: A short name is related to the different activities of the process. Input Data and Output Data: Data that can be text, numbers, files, and images are related. Responsible: Name of the principal responsible for developing the activity. Time: minutes that the activity in charge of the activity invests in the activity. The frequency of activity: every time period is performed the activity, can be daily, weekly, monthly etc. Mechanisms of control: Mechanisms that account for the accomplishment of the activity.

Table 2 List of Activities of the Scheduling Process. 

Source: “The authors”.


Once the information is lifted, a BPMN (Business Model and Notation) diagram is performed. This notation allows non-developers to graphically represent the steps involved in business processes easily and understandably. In Figure 3 the current “Scheduling” process is modeled.

Process Validation

Once the process has been completed, it is validated with the client. In order to carry out this task, a questionnaire is proposed, which contains the following questions: Does the process model contain and involve all process participants? Does it indicate the beginning and end of the process? Does it indicate the process states? Does it validate all process rules? Does it clearly state the activities of the process? Does it relate the IT resources used by the process? All the activities of the process? Does it contain the relation of the activities with their respective responsible?. The assessments to be made by the group of analysts for each question are as follows: a) Completely agree, b) Partially agree, and, c) Do not agree.

Product Modeling

Once the business processes of Phase I are defined, the analyst continues with Phase II as shown in the reference model proposed in Figure 2. The first activity is the Obtainment of Requirements, which consists of identifying in the diagrams of Business processes, activities that can be supported and supported by an Information System, that is, that require storage, consultation or data processing. Tasks or activities should be labeled as follows:

Out of the system: An activity that will not be controlled, nor supported by the system, therefore, will be left out of the system.

Controlled by the user: Activity executed by the responsible user.

Controlled by the system: Activity executed automatically by the system without user participation.

The new diagram of the Scheduling process is observed in Figure 4. The appointments to the employees or candidates of the client companies, are assigned according to the availability, if it exists, it is added to the waiting list. Customer companies or system users can verify and record the data of their employees and candidates to schedule their appointment.

Figure 4 New Schedule Process Diagram. 

The system, on the other hand, performs the consultation of the exams to be performed according to the proficiency and the availability of tests. Before the process, the IPS had to configure its agenda, i.e., the hours, capacity and length of attention of the places or offices where the different exams are carried out. This way you can optimize times of attention and resources. The initial status of the appointments is Assigned, from this status can be changed to Canceled or Confirmed. When the patient attends the IPS to be checked, then can go to the Unattended state, which indicates that, although the patient attended the IPS For your attention, none of the exams and / or services for which you were cited were performed. When you change to the Partial Care state, it indicates that all the tests listed in the appointment have not been performed and finally go to the Full Attention status.

In the Requirements Specification the requirement must be described at a sufficient level of detail to allow designing a product that satisfies the SI element of the new NBPM. The analyst must divide into the functions or subprocesses that were reflected in the new diagrams describing for each one the following data: Name, class, priority, complexity, prerequisites, if it is a requirement change if it is an important requirement or is a medium level Or if it is a requirement for improvement, if it is useful or low-level. It is recommended to use templates that are shown in Tables 3; this is based on the IEEE 830 standard specification of Software requirements.

Table 3 Template for specification of requirements. 

Source: Sysnet Ltda

It is proposed for Specification of requirements of each field of the previous interface, the template of Table 4, where the fields of examples, order number and identification are described.

Table 4 Template for specifying requirements of each field of the previous interface. 

For the Verification and Validation of requirements, a template with the following criteria is used, which can be given ratings of: Strongly Agree, Agree, Undecided and Disagree:

Table 5 Template for verification and validation of requirements. 

Source: Sysnet Ltda.

Other requirements of the system are: 1) Service Orders: the service orders of your employees and / or candidates may be generated so that they are serviced at the IPS, contain the data of the person to be served, You will be practiced, the type of examination, and the patient’s charge; At the moment the company generates the order, it is immediately reflected in the IPS portal as a pending order to be carried out. 2) Reports: companies will be able to consult the certificate of aptitude of their employees, the health conditions report of their working population and the consolidated matrix of results with diagnoses. 3) Administration to enter information: parameters such as: employees, levels of risks, charges, types of exams, departments and the professiograma that is the matrix of the exams that the position is required are entered.


Proper use of business modeling prior to the modeling of software product enables more knowledge to be discovered and a more accurate specification of requirements, that is, requirements capture must be aligned with the characteristics and properties of the business processes organization. This reduces the time in the analysis and development of software projects. Obtaining requirements by the analyst must be methodical and systematic supported in phases, templates and verification criteria of the proposed model, in order to minimize the risk of failure of a software project.

It is convenient for future work and as a recommendation, to subject the model to validation by experts and applying it in several case studies, in such a way that it can be enriched and strengthened, later to be proposed as an alternative in projects involving process modeling business and engineering requirements.


[1] A. Caetano, A. R. Silva, and J. Tribolet, “Using roles and business objects to model and understand business processes”, presented in the Proceedings of the 2005 ACM symposium on Applied computing, 2005, pp. 1308-1313. [ Links ]

[2] O. M. L. Leon and J. A. A. Spain, “The Importance of the Business Process Modeling as a Tool for the Improvement and Innovation”, Rev. Raites, vol. 4, No. 7, pp. 61-72, 2009. [ Links ]

[3] J. J. M. Z. Ruiz, “Why Software Projects Fail?; An Organizational Approach”, presented at National Congress on Free Software, 2004. [ Links ]

[4] J. Montilva and M. Rojas, “Method for the conceptualization in the modeling of the business in software processes”, Av. Sys. And Informatics, vol. 7, No. 1, pp. 71-80, 2010. [ Links ]

[5] B. Hitpass, BPM - Business Process Management Fundamentals and concepts of Implementation: Fundamentals and concepts of implementation. Bernhard Hitpass, 2012. [ Links ]

[6] M. A. S. Vidales, A. H. García, and L. J. Aguilar, “a recommendation based on MDA, BPM and SOA for software development on the bases of business processes in a context of on-demand business”, Univ. Pontif. Salamanca, 2006. [ Links ]

[7] J. M. Fernandes and F. J. Duarte, “A reference framework for process-oriented software development organizations”, Software. Syst. Model., vol. 4, No. 1, pp. 94-105, 2005. [ Links ]

[8] P. Kroll and P. Kruchten, The rational unified process made easy: a practitioner’s guide to the RUP. Addison-Wesley Professional, 2003. [ Links ]

[9] A. Delgado, “Software Development with a focus on the business,” resources. Avail. In HTTP Alarcos Espnisarticulospnis Inf-Cr Uclm-07- Delgado-Dsen Pdf Visit. The Day, vol. 27, 2007. [ Links ]

[10] M. M. Arellano and J. M. M. Tavarez, “A comparative analysis about Software Development Life Cycle Methodologies involving Business Processes and Web Services,” presented in Information Systems and Technologies (CISTI), 2012 7th Iberian Conference, 2012, pp. 1-6. [ Links ]

[11] L. Rinaudo and G. Pantaleo, Software Engineering, 2.ed. Argentina: Alfa omega, 2015. [ Links ]

[12] S. INTECO”. zoo (2013). INTECO. [ Links ]

[13] S. Robertson and J. Robertson, Mastering the Requirements Process Second Edition. Addison Wesley Professional, 2006. [ Links ]

[14] R.S. Pressman, Software engineering: a practitioner’s approach. Palgrave Macmillan, 2005. [ Links ]

Received: March 23, 2017; Accepted: December 26, 2017

*Autor por Correspondencia Email:

Creative Commons License This is an open-access article distributed under the terms of the Creative Commons Attribution License