ISSN Electronico 2145-9371 ISSN Impreso 0122-3461 vol. 34 n.° 1, Enero-Junio de 2016 Fecha de recepción: 18 de diciembre de 2014 Fecha de aceptación: 22 de noviembre de 2015 DOI: http://dx.doi.org/10.14482/inde.34.1.7958

ARTÍCULO DE INVESTIGACIÓN / RESEARCH ARTICLE

Dante Carrizo^*

Cristian Ortiz^**

Universidad de Atacama, uda (Chile)

^*Departamento de Ingeniería Informática y Cs. de la Computación. Phd en ingeniería de software. dante.carrizo@uda.cl.

^** Departamento de Ingeniería Informática y Cs. de la Computación. Msc (c) en ingeniería de software. cristian.ortiz@alumnos.uda.cl

Correspondencia: Dante Carrizo, 56-52-2206903, Avda. Copayapu 485, Copiapó, Chile.

Resumen

La educción es una actividad dentro del proceso de la Ingeniería de Requisitos que recupera información relevante acerca del dominio del problema y de las necesidades de los stakeholders para la conformación de los requisitos del producto software. Para evaluar la efectividad de la educción, es necesario conocer y modelar la influencia del contexto en el cual se desarrolla este proceso. Este artículo presenta el estado del arte sobre la actividad de educción de requisitos, principalmente sobre la representación o modelamiento de sus factores contextúales y participantes. para ello, se llevó a cabo un mapeo sistemático de artículos de investigación y libros relacionados que tratan alguna metodología o modelo de educción. El estudio permitió identificar trece propuestas aunque con insuficiente validación empírica, y que, en general, no incluyen aspectos contextuales como características, necesidades y expectativas de los stakeholders, características del dominio del problema y de la solución, la cultura organizacional y la experiencia sobre los dominios de los analistas. Esta situación impulsa a los autores a desarrollar, como trabajo futuro, un modelo unificado que aborde estos temas en la educción y que sirva de guía a los ingenieros de requisitos.

Palabras clave: educción de requisitos, factores contextuales, ingeniería de software, mapeo sistemático, modelación de procesos.

Abstract

Elicitation is an activity of requirements engineering that retrieves relevant information about the problem domain and stakeholder's needs to form the software product requirements. To evaluate the elicitation effectiveness is necessary to know and model the influence of the context in which this process is carried out. This paper presents the state of art about the requirements elicitation process, especially on how contextual factors and participants are represented or modeled. To do this, we conducted a systematic mapping of research articles and related books on any methodology or elicitation process model. The study identified thirteen proposals presenting little empirical validation. In general, these works do not include contextual aspects such as characteristics, needs and expectations of stakeholders, characteristics of the problem and solution domain, organizational culture and domain experience of analysts. This situation prompts the authors to develop, as future work, a unified model to address these issues in the elicitation and guide to requirements engineers.

Keywords: Contextual factors, process modeling, requirements elici-tation, software engineering, systematic mapping.

INTRODUCCIÓN

En el desarrollo de software, la Educción de Requisitos (del inglés elicitation) es reconocida, desde hace mucho, como una de las actividades más críticas del proceso [1]. Enmarcada actualmente dentro de la Ingeniería de Requisitos (IR), la educción de requisitos pretende obtener toda la información necesaria para definir los requisitos del futuro sistema intensivo en software. Sin embargo, para cumplir este fin se debe enfrentar diversas dificultades. Por un lado, los stakeholders (clientes, administradores, usuarios y todo aquel que tiene algún interés en el futuro sistema) rara vez tienen cabalmente claro lo que esperan del producto final para resolver sus necesidades. Por otro lado, para los analistas y desarrolladores siempre es difícil conocer el dominio del problema al que se intenta dar solución, el entorno en el que funcionará el sistema intensivo en software y la información que deben obtener desde los stakeholders. Finalmente, los requisitos no son estáticos; van apareciendo y cambiando a medida que los analistas obtienen más conocimiento sobre las necesidades de los stakeholders y sobre el dominio del problema. Así, los requisitos pasan de ambiguos a concretos, sin embargo, en esta transición pueden cambiar completamente desde su declaración inicial hecha por los stakeholders.

En esta área de investigación, existen algunas descripciones y clasificaciones respecto a las técnicas de educción de requisitos y su posible prescripción de uso [2]. Además, para dotar a los analistas o ingenieros de requisitos de más herramientas en beneficio de su actividad, se han propuesto metodologías para la selección de estas técnicas que consideran una serie de factores en un momento dado de la educción [3]. Sin embargo, no hay suficiente investigación que se ocupe en proponer un modelo que visualice la educción como un proceso contextual que debe representar su dinamismo en el tiempo, las características de los stakeholders, el dominio del problema, el dominio de la solución, la cultura organizational, la experiencia de los analistas que realizan la educción y la naturaleza siempre cambiante de los requisitos, entre otros aspectos.

Un modelo de la actividad de educción no debería enfocarse solamente en mostrar los pasos secuenciales de aplicar una técnica en particular, sino que debería permitir visualizar contextualmente un proceso cuya dimensión no es lineal, y ofrecer una guía práctica suficientemente clara y detallada para sistematizarlo. Este último punto enfatiza en un problema importante de la IR: existe una gran diferencia entre lo que los investigadores proponen o recomiendan, y lo que realmente aplican los analistas que practican la educción en su trabajo, quienes generalmente utilizan la experiencia personal y las técnicas que les son más familiares o que les impone una metodología adoptada.

Esta brecha se debe, en parte, a la falta de investigación empírica suficiente que permita a la IR obtener retroalimentación positiva, desde la industria del desarrollo de software, de la transferencia de las propuestas metodológicas novedosas que surgen de la investigación [4].

Con este horizonte, este trabajo pretende llevar a cabo una revisión del estado del arte para responder, principalmente, a la pregunta ¿existen modelos de la actividad de educción que consideren las problemáticas antes mencionadas y que la representen con toda su complejidad? Para esto, se ha realizado un mapeo sistemático, cuya metodología, resultados y conclusiones se detallan en el resto de este trabajo. La estructura del artículo es la siguiente:

la sección 2 contempla una breve revisión de trabajos relacionados, la 3 entrega antecedentes sobre la metodología de investigación utilizada. Posteriormente, en la sección 4 se presentan los resultados y la discusión del mapeo sistemático. Finalmente, se entregan las conclusiones de este estudio y los trabajos futuros pretendidos.

TRABAJOS RELACIONADOS

Cabe notar que no existen, prácticamente, revisiones sobre el mismo tema que aborda este trabajo. No obstante, en uno de los trabajos primarios encontrados se realizó una pequeña revisión de literatura sobre modelos del proceso de educción de requisitos, como base y justificación para su propia propuesta metodológica [5]. También en [6] se revisan algunos modelos de procesos más conocidos pero no es un catastro exhaustivo de las propuestas existentes. Finalmente, en [7] los autores llevan a cabo una revisión sistemática de literatura para capturar el estado del arte de la educción de requisitos automática. No obstante, solo se focaliza en las herramientas de soporte para realizan educción de requisitos desde documentos en lenguaje natural. De esta forma, la contribución de esta investigación contempla el establecimiento de la línea base del estado del arte sobre modelamiento del proceso de educción de requisitos, a partir de la cual, la comunidad científica puede desarrollar propuestas de mejora.

METODOLOGÍA

Una revisión sistemática de literatura es una metodología de investigación que se desarrolla para obtener y evaluar la evidencia disponible que sea pertinente sobre un tema específico. Se usa en diversas disciplinas, pero ha resultado ser útil también para aplicarla en la ingeniería del software [8], [9]. En esta área, se ha utilizado para obtener la mayor cantidad posible de información en forma de evidencia empírica, con ciertos grados de confiabilidad, para generar un cuerpo de conocimiento que pueda validar o crear nuevas teorías [10].

Sin embargo, en este trabajo se consideró un mapeo sistemático, un método de revisión menos exhaustivo que una revisión sistemática completa, y cuyo objetivo es tener una visión amplia del campo científico e identificar las tendencias de investigación y focos de atención, en este caso sobre modelos del proceso de educción de requisitos, y así determinar el estado del arte en un área en particular [10].

Con esto, la metodología seguida en el estudio contempla: el mapeo sistemático, donde se obtienen los estudios primarios; la definición de los criterios de análisis, es decir, el esquema de caracterización; y el análisis de resultados. La figura 1

Pregunta de investigación

El mapeo sistemático comienza con la especificación de las preguntas de investigación que se desean responder en el estudio. En este caso, el objetivo de la investigación se declara con una pregunta principal y dos secundarias. La pregunta principal es:

RQ1: ¿Existen modelos o metodologías del proceso de educción de requisitos de software que consideren el dinamismo del proceso y de los requisitos, además de los aspectos contextuales que lo afectan?

Las otras preguntas a responder son:

RQ2: ¿Los modelos del proceso de educción identificados, presentan algún tipo de validación empírica?

RQ3: ¿Qué métodos de representación se utilizan para explicar el funcionamiento del modelo o metodología propuesto?

Selección de estudios

Una vez establecido lo que se desea averiguar con el estudio, se deben identificar los estudios primarios para el mapeo. Para esto, es necesario elegir las fuentes apropiadas e intentar encontrar la mayor cantidad de publicaciones relacionadas. En esta investigación se seleccionaron las bases de datos ieee xplore, acm dl, science direct que son las que pueden contener artículos referidos a ingeniería de software. También se realizaron búsquedas oportunistas en internet, entre los libros base de la disciplina, entre las referencias de los artículos seleccionados y otros artículos ya identificados. El período de las búsquedas comprendió desde el año 1984, inclusive, a febrero del 2014.

Para conformar la cadena de búsqueda en las bases de datos de publicaciones se tuvo en cuenta el foco central de la investigación que eran los modelos de procesos de educción de requisitos. En el caso de la palabra clave "educción" se seleccionaron, además de elicitation, conceptos normalmente utilizados en el área de investigación, tales como: gathering, capture o acquisition. Así, la cadena final fue la siguiente:

(process AND model AND requirements and (elicitation OR gathering OR capture OR acquisition))

Esta cadena se ajustó a los formatos propios de cada base de datos. Para la selección de estudios se consideraron los siguientes criterios de inclusión/ exclusión:

1. Son elegibles publicaciones científicas relacionadas con requisitos software donde fuera considerada como proceso y donde se propusieran, discutieran o evaluaran modelos o metodologías para el proceso de educción de requisitos. También, se consideraron libros relacionados con ingeniería de requisitos e ingeniería de software en general.

2. No hubo restricciones sobre el área de aplicación de las publicaciones, siempre y cuando, el enfoque fuera la educción de requisitos como un proceso y se describiera la metodología propuesta.

3. Se excluyeron los artículos que solo tratan el uso específico de técnicas de educción, sin especificar un proceso subyacente o donde estuvieran incluidas.

4. Si se encuentran varios artículos del mismo grupo de investigadores que tratan la misma propuesta desde diferentes perspectivas, se considerará el de mayor completitud.

Para llegar a identificar los estudios primarios se realizaron los siguientes filtros de revisión:

1. Primer Filtro (1F):

   1. Título: revisión de los títulos de las publicaciones arrojadas por cada base de datos, incluyendo la búsqueda oportunista.

   2. Resumen o Abstract: enseguida, aquellas publicaciones que son elegibles por su título se sometieron a la revisión de su resumen.

2. Segundo Filtro (2F):

   1. Texto completo: finalmente, las publicaciones que pasaron el filtro anterior fueron sometidas a una lectura y análisis completo de su contenido. Aquellos artículos en los que el revisor asignado presentó dudas fueron sometidos a revisión por el segundo investigador.

RESULTADOS Y DISCUSIÓN

Los resultados de la búsqueda en la literatura científica se resumen en la figura 2 en formato DCM (Documents Chevy Model). Después de aplicar los filtros anteriores se identificaron trece trabajos primarios. Curiosamente la búsqueda oportunista, ejecutada entre las referencias de los artículos primarios y libros sobre ingeniería de requisitos, arrojó muy pocos resultados. Esto confirma que proponer y discutir modelos del proceso de educción es un tema relativamente reciente y no muy consolidado aún en la literatura tradicional de la ingeniería de requisitos software.

Criterios de análisis

Para analizar las metodologías o modelos que presenta cada trabajo encontrado, se han definido varios criterios o facetas, los cuales sirven de guía para evaluar y comparar los trabajos entre sí. Estos criterios establecen un esquema de clasificación o caracterización que permite obtener una vista simplificada y focalizada de los estudios primarios.

Los criterios establecidos en este estudio son:

1. Aspectos generales: qué características tiene el modelo propuesto; cómo enfoca el proceso de educción; qué técnicas de educción considera y cómo las utiliza; qué objetivos tiene la propuesta.

2. Grado de validación: si el modelo o proceso propuesto ha sido validado de forma empírica, ya sea con estudio de casos, experimentos controlados, surveys u otros, o por el contrario, se trata solo de una propuesta teórica. Los valores de este criterio, por lo tanto, se establecen como "estudio de casos", "experimento" y "teórico".

3. Salida o Producto: qué tipo de salida entrega el modelo o proceso propuesto en la publicación, el resultado esperado de un proceso de educción sería una lista de requisitos o un modelo de requisitos, etc. Sin embargo, pueden ser otros como documentos de especifica-ción de requisitos, modelos preliminares del sistema. Por lo tanto, este criterio tomará los valores "lista de requisitos", "modelo de requisitos", y "otro", cuando el producto del proceso no sea alguno de los anteriores.

Un resumen de la identificación de los trabajos encontrados, con información sobre su origen, se muestra en la Tabla 1, donde también se puede ver el grado de validación que presenta cada estudio y qué método de representación utilizan para el modelo o metodología propuesta. Esto permite responder más adelante las preguntas de investigación secundarias que se han planteado.

El mapeo sistemático permite obtener una vista facetada de los estudios primarios. En nuestro caso, la Figura 3 entrega una vista completa del ma-peo realizado en la forma de un gráfico de burbuja, donde se clasifican los trabajos primarios según los criterios de análisis establecidos anteriormente.

Discusión por criterios

• Aspectos generales

  Entre los trabajos primarios encontrados se aprecia, en general, una divergencia de enfoques. Por ejemplo, varios de ellos coinciden en el uso de una sola técnica de educción para sobrellevar la actividad. Es el caso de las técnicas de educción con enfoque orientado a objetivos y escenarios como kaos o i*, donde por ejemplo en [19] se propone la metodología megore, definida a partir de kaos para mejorar el proceso de educción utilizando: un rasgo particular de la cultura organizacional de un país; la preferencia por la información visual como un factor contextual que afecta al proceso; e introduciendo clips de video en el desarrollo de escenarios. En [16], los autores proponen la metodología ared-ck, que utiliza modelos de grafos orientados al objetivo (goal-oriented) como representación básica de los requisitos. Los autores asumen que una base de conocimiento parcial sobre el dominio, compuesta por objetivos proveniente de los requisitos iniciales de los usuarios, ya está definida. Así, la educción de requisitos se vuelve un problema de toma de decisiones, el cual es automatizado utilizando técnicas de machine learning y definiendo el proceso según la estructura de objetivos de kaos.

  En otro caso [22], los autores proponen i*-prefer, una extensión de i*, definiendo la educción de requisitos como un proceso interactivo de aprendizaje, entre el ingeniero de requisitos y el cliente, que puede ser tratado como un proceso continuo de toma de decisiones del ingeniero de requisitos. La propuesta extiende el concepto de dependencia entre los actores del enfoque actor-based de i* al incluir las preferencias de cada actor, lo que constituye otro factor contextual que afecta a la educción. Estas preferencias se utilizan para crear modelos multi-actor, donde el comportamiento de los actores es ahora inter-relacionado. Las preferencias y objetivos de un actor deben considerar las de otros actores del escenario y negociarse si hay conflictos (dependencia).

  En [12] se propone mamie, una metodología que busca guiar a los analistas en la educción de un tipo específico de sistemas: los icis (Inter Company Information Systems). En estos sistemas, varias compañías intentan cooperar al mismo tiempo que imponen sus propias restricciones y metas de negocios. La metodología utiliza casos de uso, diagramas de secuencia y otros elementos de uml para crear Viewpoints, una encapsulación parcial de información sobre los requisitos de un sistema asociado a un stakeholder en particular [23] que al integrarse con las visiones particulares de otros stakeholders construyen el modelo de requisitos del sistema.

  El concepto del Viewpoint es central también en [20], donde se propone preview, un método flexible que no impone a los usuarios un tipo particular de formato o de notación específica, más bien porque los usuarios tienden a utilizar sus propias ideas y son reacios a adaptarlas a estructuras preconcebidas de un método. También se utiliza la idea del Concern, criterios de alto nivel del negocio o de misión crítica y se usan como guías del proceso de educción de requisitos, idea que se recoge también en [12].

  La visión de los stakeholders es tratada también en [14], donde los autores sostienen que la falta de comunicación entre stakeholders y analistas es el principal problema de la educción y proponen un interesante enfoque colaborativo para elaborar los requisitos a partir de historias narrativas que son refinadas hasta transformarlas en casos de uso formales, considerando variables del dominio del problema, el contexto de las actividades de los stakeholders y la cultura organizacional, entre otros aspectos.

  Otros enfoques para el proceso se encontró en trabajos como el de [18], en el que se propone un proceso mejorado de educción de once pasos, que busca responder tres problemáticas que según los autores son las más comunes sobre educción de requisitos: problemas de alcance, problemas de comprensión y problemas de volatilidad. El proceso sigue una filosofía de cascada muy estructurada y estática, pero proponen una idea interesante para reducir la ambigüedad de los requisitos: los keywords, definiciones operacionales basadas en la descripción de necesidades y expectativas de los stakeholders que los analistas deben extraer de las entrevistas iniciales. Luego, agrupan estos keywords con el objetivo de estructurar necesidades comunes y reducir la ambigüedad de distintas descripciones de una misma necesidad o expectativa creando así los requisitos.

  En [17], la propuesta sigue el enfoque de las métodos ágiles con una metodología de educción orientada al desarrollo de software en pequeños negocios que se basa en los requerimientos no funcionales, además de modelos de procesos de negocio en notación bmpn. Lo interesante de esta propuesta es que identifica los elementos básicos de cualquier proceso de requisitos (un desarrollador, un stakeholder) y pone mucho énfasis en la formalización de los procesos de negocio usando bpmn, entrenando al dueño del pequeño negocio en el uso de la notación para modelar los procesos de su empresa. También considera factores contextuales (tamaño de la organización, restricciones subyacentes) que se deben tener siempre presentes cuando el desarrollador y el dueño definen los requisitos no funcionales.

  Por otra parte, [21] propone una metodología basada en eap (Event Activity and Process) para la educción de requisitos. eap adopta un enfoque de dos modelos para educir requisitos: Jerárquico y de Procesos. El modelo Jerárquico captura la estructura organizacional que comprende 3 niveles: la organización, los subsistemas y los procesos de cada subsistema. El modelo de Procesos, utilizado a continuación del Jerárquico, representa el funcionamiento actual del sistema y se compone de tres conceptos esenciales: evento, actividad, y proceso. Cabe notar que esta propuesta solo se enfoca a la organización y sus procesos, sin considerar los stakeholders (nombrados objetos humanos), aunque se hace notar que es un método para encontrar los primeros requisitos de un futuro sistema.

  Una mirada distinta, la percepción de valor, es el enfoque de [15]. Se basa en el Value-based Software Engineering (vbse), que busca llevar el foco de la investigación y la práctica en la ingeniería del software hacia decisiones basadas en el valor. La idea es que luego de la puesta en marcha de un sistema, este satisface al usuario porque su valor (System Value) es más alto que la expectativa del usuario (User Value). Sin embargo, el valor del usuario gradualmente supera al valor del sistema a través del tiempo, porque los requisitos del usuario siempre están cambiando. Esto provoca el llamado Value Gap, una diferencia entre el valor que percibe el usuario sobre el sistema, y el valor del sistema mismo. La propuesta busca educir los nuevos requisitos del usuario para cerrar el Value Gap, aumentando la percepción de valor del usuario sobre el sistema. Los autores declaran que el método se aplica en sistemas ya en uso, donde además no se sabe ni la cantidad ni el tipo de stakeholders. Es el caso de muchas aplicaciones exitosas de la web 2.0.

  Otra propuesta con la perspectiva de la organización y su dominio se muestra en [13], usando como base el concepto de Actor-Goal-Dependency de la metodología Tropos. Los autores proponen un método que permite transformar el modelo organizacional, que se usa en Tropos, en un SS-BM (Software System-Bussines Model) para evaluar y educir requisitos desde la lista preliminar (denominada lista de requisitos), un documento entregado por el cliente escrito en lenguaje natural que describe las necesidades del negocio al inicio del proyecto. El método utiliza SS-BM para optimizar dicha lista de requisitos, haciendo que refleje de forma más precisa las intenciones de los stakeholders. Con esto, el riesgo que genera la falta de conocimiento del dominio por parte de los analistas se reduce considerablemente.

  Finalmente, una de las propuestas más interesantes se entrega en [5]. En él, los autores hacen una revisión de trabajos previos sobre modelos de educción y plantean que los modelos propuestos carecen de flexibilidad al definir etapas y técnicas de educción específicas, y que no consideran los elementos situacionales y contextuales durante el proceso de educción y la fase de selección de técnicas de educción. Para resolver esas incidencias, proponen un modelo de educción unificado de tipo iterativo con énfasis en el conocimiento que se va adquiriendo a través del proceso acerca del domino del problema, del dominio de la solución y del dominio del proyecto, como hilo conductor. Se basa en la aplicación de una formulación matemática que representa los estados del proceso en cada iteración i del modelo, tanto de la situación actual del proceso (S_i), de los requisitos ya encontrados (R) y de las técnicas que se pueden utilizar fr). Propone además, un método de selección de técnicas integrado en su formulación matemática, que ayuda a seleccionar en cada iteración i la técnica más adecuada según el estado de los elementos situacionales descritos. Según los autores, el modelo puede aplicarse por sí mismo, y también puede ser usado para aplicar e incluso evaluar otras metodologías de educción.

• Grado de validación

  En este aspecto, predomina el estudio de caso, sin embargo, hay varios trabajos que no presentan ningún tipo de validación. Estas publicaciones corresponden a propuestas netamente teóricas, dificultando la evaluación de su contribución. Por ejemplo, esta es una de las debilidades de [5], que no complementa su interesante modelo unificado de educción con algún tipo de validación.

  Finalmente, solo dos estudios presentan casos de experimentación. En primer lugar, en [16] se evalúa empíricamente el funcionamiento del grafo de toma de decisiones. Sin embargo, en esta área destaca [20], porque presenta; un completo apartado empírico que incluye un estudio de caso, la aplicación de la propuesta en el desarrollo real de un sistema en la industria, y las entrevistas con expertos y practicantes de la ingeniería de requisitos que la evalúan.

  Respondiendo a una de las preguntas de investigación (RQ2), se puede adelantar que, en su mayoría, las propuestas revisadas sí presentan algún tipo de validación empírica, pero que no son suficientes para transferir las propuestas directamente a la industria y lograr que las utilicen los practicantes de la ingeniería de software, a excepción del caso de [20].

• Salida o Producto

  Hay variedad respecto a cuál es el producto o resultado final de las propuestas para el proceso de educción. En el caso de [20] y [12], al utilizar ambas el concepto de Viewpoints, sus productos son naturalmente listas de Viewpoints estructurados, que se convierten en requisitos en etapas posteriores de la ir como el análisis de requisitos. En el caso de [22], al ser una extensión de i*, un método bastante formal, el resultado es un conjunto de grafos optimizados, donde se representa a cada actor con sus preferencias y su dependencia con otros actores. En [16] no queda muy claro cuál es la salida de la propuesta, además del árbol de descomposición de objetivos, ya que se centran en optimizar el proceso formal de toma de decisiones.

  Más familiares son los productos de las propuestas: [14], casos de uso formales de uml; [17], diagramas bpmn y una lista de requisitos funcionales y no funcionales; y [21], que además de una lista puntuada de requisitos, entrega tablas de objetos de proceso, sus atributos, responsabilidades y utilidad. Una lista de requisitos optimizada, es a su vez el producto de la propuesta de [13]. En [19], la metodología megore, produce un modelo de requisitos a partir de los objetivos de cada escenario. En el caso de ared-ck [16], el resultado del proceso de toma de decisiones es que los objetivos iniciales provenientes de la base de conocimientos se convierten en un modelo de requisitos ajustado a las expectativas del stakeholder.

  El modelo unificado de [5] entrega un grupo conceptual R de requisitos refinados. Por otro lado un conjunto de keywords, además de un prototipo para probar los requisitos educidos, es lo que arroja como resultado la metodología de [18].

  Finalmente, la propuesta basada en la apreciación de valor de los usuarios [15], produce un modelo de bloques flotante para identificar la diferencia de valor (value gap) que declaran los usuarios, y una lista de nuevos requisitos para que el sistema supere dicha diferencia y recupere valor para sus usuarios.

  La Tabla 1 ilustra también cuál método de representación gráfica utiliza cada trabajo para esquematizar su propuesta. Se clasifica esta característica en: "diagramas simple", cuando la propuesta utiliza un diagrama sencillo para esquematizar de forma general el proceso, por ejemplo un diagrama de flujo o conceptual, pero sin mayor detalle; "diagrama complejo", si la propuesta muestra un diagrama más completo para la representación, que entrega más detalles del proceso o incluye múltiples vistas de él, como un diagrama bpmn, uml o un grafo; y "ninguna", si la propuesta no incluye ningún tipo de representación. En este aspecto nuevamente hay variedad de esquemas, por ejemplo, se utilizan diagramas de flujo sencillos, o esquemas propios con propósitos meramente ilustrativos o conceptuales y no de representación completa de la propuesta, es decir, diagramas simples. También hay propuestas que no utilizan ninguna representación, limitándose a describirla. Por otro lado, hay estudios que representan de forma más completa sus propuestas como el caso de [17], donde hacen uso extensivo de la notación bpmn, utilizándola para representar toda la propuesta de educción. También en [20] incluyen primero un diagrama en espiral del proceso de requisitos y luego otro esquema más detallado para el proceso de extracción de los Viewpoints que está incluido en el anterior. En [22] presentan el esquema del grafo del modelo actor-dependencia que representa todo el proceso optimizado de toma de decisiones de la propuesta.

  Respondiendo la otra pregunta de investigación secundaria (RQ3), se puede decir que la mayoría de los trabajos primarios utilizan algún método de representación que puede ser meramente ilustrativo y que no muestran con detalle el funcionamiento de la metodología a través de sus etapas. Otros trabajos sí entregan propuestas de representación más completas, sin embargo, no llegan al nivel de poder utilizar estos diagramas como guías de aplicación práctica o de ilustración completa de las metodologías propuestas.

CONCLUSIONES

La educción de requisitos es una actividad clave para garantizar la calidad del producto software, por lo que su gestión adecuada parece ser imprescindible para todo analista o ingeniero de requisitos. Pero sobrellevar la captura de información por los desarrolladores desde los stakeholders no está exento de dificultades, principalmente por la diferencia de culturas de los participantes y la naturaleza cambiante de las variables condicionantes del contexto de la educción. Para facilitar esta actividad, se requiere un modelo cabal de las dimensiones y perspectivas que están involucradas. Este estudio tenía como objetivo conocer el estado del arte de la representación o modelamiento de esta actividad, para lo cual se llevó a cabo un mapeo sistemático de la literatura científica. El mapeo sistemático demostró que existen, en número, pocas propuestas para la actividad de educción de requisitos. No obstante, identificó formas diversas de ver el proceso, desde los métodos más formales y empíricos como i* hasta propuestas basadas en métodos narrativos. Sin embargo, una tendencia importante, es utilizar una técnica específica para crear una metodología a su alrededor, lo que puede facilitar su adopción, pero también puede limitar la efectividad de la educción al no considerar las ventajas y adecuación de otras técnicas.

En general, la actividad es vista más bien como un procedimiento conducido por la técnica seleccionada sin representar la influencia continua del contexto en el tiempo. Algunas propuestas mencionan su relevancia, pero solo una de ellas integra estos factores contextuales como parte de la metodología. Las vistas de la actividad siguen siendo más bien lineales sin considerarla como un proceso multidimensional y, sobre todo, que considere la naturaleza cambiante de los requisitos en el tiempo.

Por otro lado, el mapeo evidencia una falta de validación empírica de la mayoría de los trabajos previos, quedándose solo en propuestas teóricas e impidiendo su transferencia efectiva a la industria del desarrollo de software.

Como trabajo de futuro inmediato, los autores se plantean el desarrollo de un modelamiento del proceso de educción de requisitos que considere los factores contextuales y su condicionamiento mutuo. También se pretende que el modelo muestre la dinámica en el tiempo de la educción y la selección de las técnicas más adecuada según el contexto en el que se desarrolla.

REFERENCIAS

[1] F. P. Brooks, "No Silver Bullet Essence and Accidents of Software Engineering," Computer (Long. Beach. Calif)., vol. 20, no. 4, pp. 10-19, Apr. 1987. doi: 10.1109/MC.1987.1663532

[2] D. Zowghi, y C. Coulin, "Requirements elicitation: A survey of techniques, approaches, and tools," Eng. Manag. Softw. Requir. , 2005. doi: 10.1007/3-540-28244-0_2

[3] D. Carrizo, O. Dieste, y N. Juristo, "Systematizing requirements elicitation technique selection," Inf. Softw. Technol., vol. 56, no. 6, pp. 644-669, Jun. 2014. doi:10.1016/j.infsof.2014.01.009

[4] A. Davis, O. Dieste, A. Hickey, N. Juristo, y A. M. Moreno, "Effectiveness of Requirements Elicitation Techniques: Empirical Results Derived from a Systematic Review," in 14th IEEE International Requirements Engineering Conference (RE'06), 2006, pp. 179-188. doi: 10.1109/RE.2006.17

[5] A. M. Hickey, y A. M. Davis, "A Unified Model of Requirements Elicita-tion," Journal Management Information Systems, vol. 20, no. 4, pp. 65-84, 2004.

[6] D. Carrizo, "Contextual Dynamic of the Software Requirements Elicitation," Revista Facultad de Ingeniería de la Universidad de Antioquia, no. 69, pp. 34-52, diciembre 2013.

[7] H. Meth, M. Brhel, y A. Maedche, "The state of the art in automated requirements elicitation," Information and Software Technology, vol. 55, Issue 10, pp. 1695-1709, 2013. doi: 10.1016/j.infsof.2013.03.008

[8] B. A. Kitchenham, T. Dyba, y M. Jorgensen, "Evidence-based software engineering," in Proceedings. 26th International Conference on Software Engineering, 2004, pp. 273-281. doi: 10.1109/ICSE.2004.1317449

[9] F. Q. B. da Silva, A. L. M. Santos, S. Soares, A. C. C. Franca, C. V. F. Monteiro, y F. F. Maciel, "Six years of systematic literature reviews in software engineering: An updated tertiary study," Inf. Softw. Technol., vol. 53, no. 9, pp. 899-913, Sep. 2011. doi: 10.1016/j.infsof.2011.04.004

[10] J. Bailey, D. Budgen, M. Turner, B. Kitchenham, P. Brereton, y S. Linkman, "Evidence relating to Object-Oriented software design: A survey," in First International Symposium on Empirical Software Engineering and Measurement (ESEM 2007), 2007, pp. 482-484. doi: 10.1109/ESEM.2007.58

[11] K. Petersen, R. Feldt, S. Mujtaba, y M. Mattsson, "Systematic Mapping Studies in Software Engineering," in EASE'08 Proceedings of the 12th international conference on Evaluation and Assessment in Software Engineering, 2008, pp. 1-10.

[12] H. Bendjenna, N. E. Zarour, y P. J. Charrel, "MAMIE: A Methodology to Elicit Requirements in Inter-company Co-operative Information Systems," in 2008 International Conference on Computational Intelligence for Modelling Control & Automation, 2008, pp. 290-295. doi: 10.1109/CIMCA.2008.101

[13] A. Krishna, y H. Lu, "Requirements Elicitation Using Goal-Based Organizational Model," in 19th Australian Conference on Software Engineering (aswec 2008), 2008, pp. 543-551. doi: 10.1109/ASWEC.2008.4483244

[14] V. Laporti, M. R. S. Borges, y V. P. Braganholo, "A Collaborative Approach to Requirements Elicitation," in 2007 11th International Conference on Computer Supported Cooperative Work in Design, 2007, pp. 734-739. doi: 10.1109/ CSCWD.2007.4281527

[15] S. W. Lim, T. Lee, S. Kim, y H. P. In, "The Value Gap Model: Value-Based Requirements Elicitation," in 7th IEEE International Conference on Computer and Information Technology (CIT 2007), 2007, pp. 885-890. doi: 10.1109/ CIT.2007.34

[16] L. Liu, y L. Lin, "ARED-CK: an Automated Requirements Elicitation Approach Based on Decision-making with Complete Knowledge," in 2008 First International Workshop on Managing Requirements Knowledge, 2008, pp. 47-52. doi: 10.1109/MARK.2008.2

[17] R. Macasaet, L. Chung, J. L. Garrido, M. Noguera, y M. L. Rodríguez, "An agile requirements elicitation approach based on NFRs and business process models for micro-businesses," in Proceedings of the 12th International Conference on Product Focused Software Development and Process Improvement - Profes '11, 2011, p. 50. doi: 10.1145/2181101.2181114

[18] P. Rajagopal, R. Lee, T. Ahlswede, y D. Karolak, "A New Approach to Software Requirements Elicitation," in Sixth International Conference on Software Engineering, Artificial Intelligence, Networking and Parallel/Distributed Computing and First ACIS International Workshop on Self-Assembling Wireless Networks (SNPD/SAWN'05), 2005, pp. 32-42. doi: 10.1109/SNPD-SAWN.2005.5

[19] Y. Shan, L. Liu, y F. Peng, "MEGORE: Multimedia Enhanced Goal-Oriented Requirement Elicitation Experience in China," in 2008 Third International Workshop on Multimedia and Enjoyable Requirements Engineering - Beyond Mere Descriptions and with More Fun and Games, 2008, pp. 37-41. doi: 10.1109/ MERE.2008.4

[20] I. Sommerville, P. Sawyer, y S. Viller, "Viewpoints for requirements elici-tation: a practical approach," in Proceedings of IEEE International Symposium on Requirements Engineering: RE '98, 1998, pp. 74-81. doi: 10.1109/ ICRE.1998.667811

[21] U. V. Subramanian, "An event, activity and process based methodology for requirements elicitation and its application to an educational information system," in Proceedings Sixth Asia Pacific Software Engineering Conference (ASPEC'99) (Cat. No.PR00509), 1999, pp. 188-195. doi: 10.1109/AP-SEC.1999.809601

[22] H. Xie, L. Liu, y J. Yang, "i *-prefer: optimizing requirements elicitation process based on actor preferences," in Proceedings of the 2009 ACM symposium on Applied Computing - SAC '09, 2009, p. 347. doi: 10.1145/1529282.1529359

[23] I. Sommerville y P. Sawyer, "Viewpoints: principles, problems and a practical approach to requirements engineering," Ann. Softw. Eng., vol. 3, no. 1,pp. 101-130, 1997. doi: 10.1023/A:1018946223345