ISSN 0718-3291 Versión Impresa

ISSN 0718-3305 Versión en línea

Volumen 24 N° 4, Octubre - Diciembre 2016

pdf Índice

Documentar la elicitación de requisitos: Una revisión sistemática

 

 

 

Edgar Serna M.1* Jorge Hernán Suaza J.2

1 Facultad de Ciencias Básicas e Ingeniería. Corporación Universitaria Remington. Cra. 51 51-27. Medellín, Colombia. E-mail: edgar.serna@uniremington.edu.co
2 Facultad de Ingenierías. Instituto Tecnológico Metropolitano. Calle 54A 30-1. Medellín, Colombia. E-mail: jorgesuaza@itm.edu.co
* Autor de correspondencia


RESUMEN

Diferentes investigadores han propuesto técnicas y modelos para elicitar requisitos y la mayoría describe procesos y recomendaciones para capturarlos, pero muy pocos detallan cómo documentarlos en esta etapa. Aunque en la comunidad se reconoce ampliamente la importancia de la ingeniería de requisitos y de la elicitación como una etapa importante de esta fase de la ingeniería del software, se han presentado pocos trabajos que orienten a los ingenieros a documentar esa elicitación. La importancia de una adecuada documentación de esta etapa radica en que permite una mayor comprensión de las necesidades del cliente y el usuario, y les ayuda a los ingenieros a percibir de mejor forma el problema y a modelar una solución que se refleje adecuadamente en la especificación. En este trabajo se presentan los resultados de una revisión sistemática de la literatura, orientada a conocer, analizar y comparar las propuestas para documentar la elicitación de requisitos. Se consultaron 73 trabajos en las bases de datos, de los cuales 18 conforman la muestra final. La conclusión es que falta más trabajo en lo que tiene que ver con esta documentación, porque ninguno de los trabajos analizados describe una propuesta directa y completa para hacerlo.

Palabras clave: Requisitos, documentación de requisitos, ingeniería de requisitos, elicitación de requisitos, ingeniería de software.


ABSTRACT

Different researchers have proposed techniques and models for eliciting requirements, and most described process and recommendations to capture them, but there are few details on how to document with this step. Although the community has widely recognized the importance of engineering requirements, and elicitation of an important stage of this phase of software engineering, there have been few studies to guide engineers to document this elicitation. The importance of proper documentation of this step is that it allows a better understanding of customer and the user needs, and helps engineers to best perceive the problem, and model a solution that adequately reflected in the Specification. In this work are presented the results of a literature review, aimed at discovering, analyzing and comparing the proposals to document the elicitation of requirements. 73 works were consulted in the databases, of which 18 formed the final sample. The conclusion is that more work is missing on what to do with this documentation, because none of the studies analyzed directly and completely describes a proposal to do so.

Keywords: Requirements, requirements documentation, requirements engineering, requirements elicitation, software engineering.


INTRODUCCIÓN

Debido al tipo de problemas que atienden los ingenieros de software el proceso para solucionarlos es complicado y requiere dedicación y tiempo. El procedimiento, generalmente aceptado, es el ciclo de vida de la ingeniería de software, que consiste en aplicar principios científicos de ingeniería en cada una de las fases para generar una solución elaborada de software y para proyectar su subsecuente mantenimiento [1]. Este ciclo está conformado por las fases: ingeniería de requisitos, diseño, desarrollo, implementación y mantenimiento, pero es conveniente tener en cuenta que las Pruebas y la gestión de la calidad deben ser paralelas a todo el proceso [2]. Por su parte, la ingeniería de requisitos se estructura en etapas cuyo objetivo es comprender, estructurar y documentar las necesidades que los usuarios desean satisfacer con el producto, y que posteriormente se traducirán en un conjunto de sentencias precisas, no ambiguas, que se utilizarán para desarrollar el sistema [3-4], conocidas como requisitos. El profesor Edgar Serna propone Model to Develop and Manage Requirements Engineering (MoDeMaRE) [5] para desarrollar y gestionar la ingeniería de requisitos, el que está conformado por las etapas: 0. Temprana, 1. Elicitación, 2. Desarrollo, 3. Gestión y 4. Especificación, como se observa en la Figura 1.



Figura 1. MoDeMaRE [5].

De acuerdo con este investigador, en la etapa temprana se reconoce y comprende el contexto del problema; en la elicitación se identifican, modelan y documentan las necesidades del cliente; en el desarrollo se analizan y definen esas necesidades; en la gestión se validan y verifican; y en la especificación se estructuran en un documento formal que constituye la base de la siguiente fase del ciclo de vida. En la elicitación se aplican diferentes técnicas para identificar las necesidades, generalmente descritas en lenguaje natural y, por tanto, con ambigüedades lo que dificulta el proceso para las siguientes etapas. Las actividades se orientan a identificar las discrepancias entre las partes interesadas, con el propósito de definir claramente los requisitos [6]; pero esa identificación se convierte en un problema, porque no siempre están disponibles ni son claros para el analista, además, porque la fuente es el conocimiento de seres humanos, que no es fácil de representar o traducir a un lenguaje de comprensión generalizado.

Para identificar y modelar el problema que se va a resolver el analista debe comprenderlo en contexto y ubicarlo en un dominio. Para lograrlo, utiliza desde la primera etapa las reglas generales del negocio y de los actores involucrados, directa o indirectamente. Pero el alcance del sistema, la falta de comprensión del problema por las partes interesadas, y la volatilidad de los requisitos complican su interpretación y modelamiento. Es por esto que las diferentes etapas de la ingeniería de requisitos son complicadas y exigentes, e implican procesos sistemáticos e iterativos en los que el analista debe recurrir a la lógica, la abstracción, y a sus capacidades de modelamiento con el objetivo de hacer una representación mental del problema e iniciar el proceso de solución [5]. Por lo tanto, en la etapa temprana es importante saber observar, saber preguntar, saber escuchar y saber representar de diferentes formas y aplicando modelos lógicos y abstractos, porque de esta manera es posible eliminar la ambigüedad y las dificultades que se presentan cuando el cliente describe sus necesidades, lo que requiere un proceso juicioso y estructurado de documentación.

Documentar adecuadamente la elicitación brinda un mejor nivel de seguridad y comprensión del problema para abordar las demás fases del ciclo de vida, porque, debido a la volatilidad de los requisitos, se puede consultar cada vez que no se comprenda alguno en la especificación. Esto es necesario para que los proyectos software no excedan los tiempos ni los costos inicialmente establecidos, y para satisfacer de mejor forma la fiabilidad y seguridad esperada del producto. Pero, de acuerdo con la revisión a los modelos y metodologías propuestos para elicitar requisitos, estos principios no se tienen en cuenta, y la mayoría pretende pasar a la especificación directamente sin tener un documento adecuado de la elicitación. Esto se evidencia en los diferentes procesos de reingeniería que ejecutan los ingenieros en el diseño del producto, luego que se ha ejecutado la ingeniería de requisitos [7].

Con el objetivo de conocer y analizar las propuestas de la comunidad para documentar la elicitación de requisitos, se hizo una revisión sistemática de la literatura para consultarlas. Este artículo muestra los resultados, en los que se describen los enfoques y procedimientos relacionados. En el procedimiento se consultaron diferentes bases de datos y bibliotecas digitales para encontrar trabajos representativos que aportaran a la investigación. El procedimiento y los resultados se describen y analizan en las siguientes secciones. En la primera se detalla la metodología aplicada, en la segunda se detallan los resultados, en la tercera se analizan esos resultados y al final se presentan las conclusiones del proceso.

METODOLOGÍA

Según [8] y [9] una revisión sistemática a la literatura implica la realización de tres pasos básicos: 1) planificación, 2) realización, y 3) documentación, los cuales involucran seis procesos adicionales:

• Definir las preguntas de investigación.
• Definir el proceso de búsqueda.
• Definir los criterios de inclusión y exclusión.
• Definir la valoración de la calidad.
• Definir la recopilación de datos.
• Definir el análisis de resultados.

Preguntas de investigación
Para esta investigación, las preguntas están orientadas a determinar qué tan importante es la documentación en la etapa de elicitación y cuál es su nivel de éxito en los proyectos. Se plantearon las siguientes:

P1. ¿Cuál es el nivel de difusión acerca de cómo documentar la elicitación de requisitos?
P2. ¿Qué tipo de trabajos se difunde?
P3. ¿Cómo se difunden los trabajos?
P4. ¿Cuál es nivel de éxito y el grado de aceptación y seguimiento en la comunidad?

Proceso de búsqueda
El objetivo de la búsqueda de información fue identificar los estudios que se han publicado acerca de cómo documentar la elicitación de requisitos, para reconocer y resaltar fuentes específicas, estudios y opiniones candidatos a ser incluidos en la muestra final de trabajos. Para lograr este objetivo, en los parámetros de búsqueda se incluyeron las siguientes palabras clave: elicitation documentation, elicitation models, elicitation approaches, elicitation methods, elicitation methodology, elicitation standard, elicitation techniques. Estos términos debían aparecer en el título, el resumen o en el contenido del documento. La búsqueda se hizo en las bases de datos y bibliotecas digitales de IEEE Digital library, ACM Digital Library, Springer Link y Science Direct, entre enero y marzo de 2014. Luego de aplicar el proceso se encontraron 73 trabajos; la mayoría se identificó al buscar la palabra clave en el título o en el resumen. Para lograr un mayor cubrimiento no se excluyó ninguna fuente inicial.

Criterios de inclusión y exclusión
Para incluir los trabajos seleccionados como fuente primaria el contenido tenía que hacer un aporte importante al proceso de la documentación de la elicitación de requisitos, y, de acuerdo con Dyba y Dingsoyr [10], existen cuatro fases para filtrar un documento desde una serie de trabajos al conjunto de datos primarios:

• Identificar los estudios relevantes: la búsqueda arrojó 73 trabajos.
• Excluir estudios con base en el título: se excluyeron 10 trabajos.
• Excluir estudios con base en los resúmenes: se excluyeron 45 trabajos.
• Seleccionar los más importantes para la temática en cuestión: 18 trabajos como muestra final. El criterio científico aplicado para esta selección consistió en valorar el aporte real que hace el trabajo a la documentación de la elicitación. En este caso se tuvo en cuenta si es teórico, experimental o de un estudio de caso en la industria.

Durante la exploración se encontró poca información acerca de la temática por lo que se decidió incluir investigaciones que en su contenido hicieran referencia a cómo documentar la elicitación de requisitos. Los criterios de inclusión y exclusión más importantes fueron: autoridad del autor, calidad y aporte del documento a la temática investigada, y claridad de la descripción de la propuesta.

Valoración de la calidad
Los trabajos seleccionados debían estar estrechamente relacionados con la documentación de la elicitación. Los estudios seleccionados fueron sólidos en cuanto a la calidad, lo que garantiza la integridad de la información debido a que se soportan en la fuente de información primaria, una biblioteca digital o una base de datos con amplio reconocimiento en la comunidad, o en sitios web respaldados por una adecuada referenciación.

Recopilación de los datos
Luego de realizar el proceso de inclusión y exclusión se estructuró el conjunto de final de trabajos y se determinaron los atributos para los estudios primarios:

• Tipo de publicación.
• Publicado en.
• Editorial que respalda.
• Año de publicación.
• Clasificación de los enfoques de investigación.
• Clasificación de los métodos de investigación.

Análisis de resultados

Los resultados demuestran que la mayoría de fuentes hace referencia a la documentación de la especificación de requisitos pero poco a la de la elicitación. En este proceso el objetivo era determinar:

1. El nivel de difusión acerca de cómo documentar la elicitación de requisitos: cantidad de trabajos encontrados.
2. El tipo de trabajo que se publica: opinión, descripción o investigación.
3. Cómo se difunden: libros, artículos, trabajos en eventos, reportes técnicos.
4. El nivel de éxito y el grado de aceptación y utilización por parte de la comunidad relacionada: número de referencias que se realizan a los trabajos analizados, aceptación en la industria.

RESULTADOS

En la Tabla 1 se detallan los 18 trabajos de la muestra final de la revisión.

Tabla 1. Documentos incluidos en la muestra final.

Estado del arte
D1 Decision Tables in Software Engineering. Las tablas propuestas proporcionan una notación que se traduce en acciones y condiciones en un formato tabular, y se pueden utilizar como una entrada legible por la máquina a un algoritmo basado en tablas. Según el autor, la técnica es útil cuando se tiene un complejo conjunto de condiciones, y cuando las acciones se encuentran dentro de un componente, por ejemplo en una elicitación. Lo que no tiene en cuenta es que generalmente las partes interesadas expresan sus necesidades en lenguaje natural, y estas tablas no permiten evaluar las ambigüedades resultantes antes de reconocer esas acciones como requisitos. Esta propuesta está más orientada a crear un listado de candidatos a requisitos, por lo que no recibió una acogida aceptable en la ingeniería de software.

D2 Object-Oriented Software Engineering. La representación gráfica compacta es útil para representar los requisitos, por lo que es recomendable utilizar el diagrama de casos de uso para el modelado de los funcionales. Esta representación actúa como un puente entre los actores técnicos y el cliente, pero presenta desventajas y problemas porque se aplica principalmente para modelar requisitos funcionales, y no es muy útil para otro tipo, como los no funcionales. Además, carece de una semántica bien definida para realizar una adecuada documentación, lo que puede dar lugar a diferencias en la interpretación por las partes interesadas. A pesar de que la representación gráfica se utiliza como modelo de entendimiento entre las partes acerca del significado y descripción de las necesidades, como documento descriptivo de la elicitación todavía no logra brindar la información suficiente para las demás etapas de la ingeniería de requisitos, por lo que esta propuesta se orienta más a brindar datos específicamente para la especificación y no para la documentación de la elicitación.

D3 Functional Documents for Computer Systems. Un paso crítico al documentar los requisitos de un sistema informático es la identificación de los elementos ambientales, como las propiedades físicas -temperatura, presión-, los que, ya sea para medir o controlar, deben ser representados por variables matemáticas, y, como es usual en ingeniería, la asociación se debe definir con cuidado e indicarse sin ambigüedades. Para aclarar la asociación se pueden utilizar diagramas entre los elementos y las variables matemáticas, como los presentados en esta propuesta. La cuestión es que para la mayoría de ingenieros el nivel matemático que exige es complejo, y no están preparados para utilizarla adecuadamente al momento de documentar la elicitación. Este problema se acrecienta cuando se trata de clientes y usuarios, quienes tienen menos capacidades de entendimiento acerca del contenido matemático de esta propuesta, por lo que no ha recibido buena aceptación en la comunidad en lo que tiene que ver con la documentación de la elicitación.

D4 Viewpoints for Requirements Elicitation: A Practical Approach. Esta técnica soporta la agrupación, la gestión de requisitos, la verificación de inconsistencias, y la trazabilidad de los requisitos mediante puntos de vista. Parte de que, debido a los diferentes enfoques con los cuales las partes interesadas observan un requisito, es necesario recogerlos y organizarlos desde diferentes acercamientos. Esta técnica soporta la agrupación, la gestión de requisitos, la verificación de inconsistencias, y la trazabilidad de los requisitos. Pero esos puntos de vista reconocen múltiples perspectivas, lo que no proporcionan un marco para el descubrimiento de conflictos en los requisitos propuestos; además, no permiten la gestión de las inconsistencias. Otra dificultad es que en un alto número de puntos de vista es difícil definir la prioridad de los requisitos, por lo que la documentación generada no es suficiente para solucionarlo.

D5 Extreme Programming Explained. De acuerdo con el autor, las historias de usuario se han utilizado como parte de la programación extrema y en las metodologías ágiles, y los clientes las pueden escribir utilizando una terminología no técnica en el formato de frases y en lenguaje natural. Esta propuesta describe un proceso para la ingeniería de requisitos en el que el usuario tiene poca participación y los formatos para documentarlos no tienen una estructura definida. Por otro lado, se deben expresar de forma no gráfica y respetando una metodología específica, la que no está en línea con paradigmas como el UML y la POO. Por todo esto la propuesta no ofrece una alternativa eficiente para documentar la elicitación, además, no tiene en cuenta a los requisitos no funcionales, por lo que se deben recolectar y documentar separadamente.

D6 Writing a Software Requirements document. Cada documento de requisitos consiste por lo menos de dos partes: una visión general y una descripción de la funcionalidad del sistema. A menudo, debe incluir apéndices, de acuerdo a sí se necesita más información de la que contiene el resto del documento, o de material que no encaja en otra parte, pero que debe ser incluido. La dificultad radica en que el documento de la elicitación generado es muy extenso, y no ofrece una adecuada claridad acerca de la descripción de las necesidades de las partes interesadas. Por otro lado, se acoge más al estándar IEEE STD- 830-1998 que se orienta a la especificación, por lo que no es muy adecuada para documentar la elicitación.

D7 Capturing the Requirements. Los requisitos son inciertos, lo que hace difícil emplearlos en procesos donde se deben actualizar los modelos cada vez que cambian. Como una alternativa a este problema, los métodos ágiles reúnen y aplican los requisitos en incrementos. El proceso consiste en partir de una versión inicial, en la que, de acuerdo con la definición de los objetivos del negocio de las partes interesadas, se obtiene la mayoría de requisitos esenciales; o con el uso del sistema o con una mejor comprensión del problema, cuando surgen nuevos requisitos. Este desarrollo incremental permite una entrega temprana y continua, y tiene la capacidad emergente de obtener requisitos de última hora. La cuestión es que los procesos ágiles para requisitos, en los que el sistema se construye de acuerdo con los que se van definiendo en el momento, no tienen en cuenta la planificación o el diseño para posibles requisitos futuros, y la documentación se queda corta en todo paso.

D8 Formalizing a Structured Natural Language Requirements Specification Notation. El autor propone una serie de estructuras con el objetivo de dar mayor organización a los documentos de la ingeniería de requisitos; sin embargo, asume que los lenguajes naturales no tienen una notación formal ni gráfica específica, por lo que esas estructuras se pueden orientar tanto a algoritmos como a lenguajes de programación; lo que limita la libertad en la codificación posterior. El problema con esta propuesta radica en que las estructuras no son viables para documentar las descripciones de las necesidades formuladas en lenguaje natural en la elicitación, por lo que las partes interesadas no pueden llegar a acuerdos de las descripciones finales.

D9 A Theory of Requirements Documentation Situated in Practice. Se trata de un marco teórico que intenta explicar la variedad de estilos para documentar los requisitos elicitados, en relación con la variedad de situaciones en las que el software se desarrolla. Este marco contrasta gran parte de la literatura sobre requisitos, porque tiende a acercarse a la documentación pero abandona la situación de uso. La propuesta se divide en tres partes: 1) análisis de documentos de requisitos, como textos, para categorizar los diferentes elementos constitutivos que podrían ser utilizados para especificarlos; 2) esquema para clasificar el desarrollo del sistema con respecto al proceso de la documentación de requisitos, y 3) toma cada uno de estos tipos de situaciones y define un estilo apropiado para el documento de requisitos. Aunque puede ser útil y su objetivo es explicar las diversas formas en que en la práctica se documentan los requisitos, hasta la fecha, y de acuerdo con los resultados al seguimiento de la propuesta, esa diversidad no ha sido examinada por otro estudio, marco teórico o caso de estudio, lo que no permite conocer su eficiencia y efectividad en la práctica industrial.

D10 Market Research for Requirements Analysis Using Linguistic Tools. En la propuesta se describe que cuando la elicitación no presenta un modelo semánticamente transparente del dominio del problema, el analista debe utilizar objetos subyacentes como archivos, líneas y caracteres. Con estos procedimientos se pueden conseguir buenos requisitos, pero el proceso de desarrollo suele ser lento. Para resolver este problema el autor propone que en la elicitación se tengan en cuenta diferentes características de los datos, como que son multilingües, se desarrollan de forma secuencial, se estructuran jerárquicamente, son multidimensionales, y tienen alta integración, por lo que se deben almacenar y seguir los vínculos asociativos entre las piezas de datos conexos. Pero si se tienen en cuenta estas características, se incrementa la dificultad para documentar la elicitación, porque muchas de ellas todavía no se conocen en esta etapa. Aunque es una propuesta amplia, el documento que genera no pasa de ser una visión personal de cada ingeniero, en la que no se hace una adecuada discusión con las partes interesadas.

D11 Requirements Analysis for Engineering Computation - A Systematic Approachfor Improving Reliability. Mediante un sistema de trazabilidad esta propuesta utiliza tablas para representar los requisitos, las que incluyen las propiedades y las relaciones de los mismos, lo que ayuda para su organización y para mostrar explícitamente los diversos tipos de relaciones entre ellos. El diagrama es útil para estandarizar la forma de especificar los requisitos por medio de una semántica definida, y permite su representación y de los elementos del modelo, lo que significa que los visiona como parte de la arquitectura del sistema. El problema surge cuando se realizan modificaciones reiterativas por parte del cliente, porque la estructura de las tablas no es flexible y no permite reprocesos para realizar los cambios necesarios. Esta falta de dinamismo no le brinda maniobrabilidad al ingeniero como para mantener actualizado el documento de la elicitación, por lo que la propuesta no ha tenido un seguimiento adecuado.

D12 From Requirements to Architecture. La propuesta consiste de un modelo de dos variables, común en la ingeniería mecánica y en la eléctrica, que el autor utiliza para documentar los requisitos de esos sistemas. Aunque en teoría es útil para sistemas software, debido a la volatilidad de los mismos no es práctico para documentar la mayoría de requisitos. Además, el modelo no es fácilmente adaptable a contextos en los que la volatilidad de las necesidades del cliente es alta, y donde se requieren mayor dinamismo para mantener actualizado el documento de la elicitación.

D13 A Template for Requirement Elicitation Document of Software Product Lines. Este trabajo proporciona plantillas para describir informalmente las líneas de productos software, y para documentar su uso. El objetivo es que en la descripción se utilice un lenguaje natural comprensible por todos interesados. La primera plantilla se compone de un diccionario de datos en forma de tabla, y en la segunda se elicitan los potenciales requisitos funcionales y no funcionales. Cada caso de uso involucrado proporciona uno o más escenarios, que describen cómo debe interactuar el sistema con el usuario final, o con otro sistema, para lograr los objetivos específicos del negocio, pero esa interacción no se refleja en las tablas, por lo que cualquier modificación en los requisitos genera una nueva tabla de datos.

D14 Athena: A Collaborative Approach to Requirements Elicitation Link. La elicitación de requisitos es una fase que requiere de mucha interacción entre las partes interesadas, porque se necesita un alto intercambio de información, y muchas veces las técnicas no son usadas de forma correcta; además, los clientes no están completamente seguros de sus necesidades reales, lo que lleva a que los requisitos sean incompletos e inconsistentes. Esos problemas de comunicación entre las partes suceden porque los clientes utilizan el lenguaje natural para expresarse, mientras que los analistas prefieren uno más formal. Athenea es una herramienta para que los usuarios plasmen sus experiencias y puntos de vista, para luego negociar los requisitos de forma colaborativa. A partir de descripciones de alto nivel adopta un enfoque basado en un perfeccionamiento gradual de requisitos y termina con casos de uso concretos, lo que se logra de forma cooperativa en el equipo, y se traduce en requisitos negociados. La cuestión es que es una herramienta experimental, y luego de cinco años de divulgada todavía no ha sido probada en entornos reales de desarrollo de software, por lo que no es posible verificar su eficiencia y efectividad para generar el documento de la elicitación.

D15 Exploring Language in Software Process Elicitation: A Grounded Theory Approach. La elicitación es un paso importante para la creación del documento que describe los requisitos. En este proceso se requieren actividades de comunicación, de extracción de conocimiento y de comprensión de los objetivos, con la intención de elaborar un documento que demuestre el cumplimiento de políticas de auditoria y la aplicación de buenas prácticas, para identificar cambios potenciales en el flujo de trabajo existente. La experimentación descrita en este trabajo se divide en dos momentos: 1) escuchar a los usuarios expresar sus necesidades mediante el lenguaje natural y 2) utilizar plantillas para documentar el proceso. Los resultados incluyen representaciones del proceso, notas del campo de observación, y transcripciones de entrevistas; pero al momento de analizarlas se encuentra con que se sugieren diferentes formas para que los usuarios del proceso describan sus necesidades, lo que dificulta la documentación esperada.

D16 A Framework for Eliciting Value Proposition from Stakeholders. Teniendo en cuenta la importancia de las partes interesadas en el proceso, el objetivo de esta propuesta es simplificar y estructurar el proceso de elicitación de requisitos, y generar un documento que exponga una serie de criterios para su selección, como la influencia, la importancia dentro del proyecto, la legitimidad, la urgencia y el interés en el proyecto. Aunque tiene relevancia, solo se encontraron trabajos en los que se aplica para documentar requisitos en proyectos a pequeña escala, por lo que todavía no se puede considerar su éxito en proyectos de mayor tamaño. La desventaja de esto es que los problemas que actualmente soluciona la ingeniería de software son grandes, complejos y complicados, y con una propuesta de este tipo no se podría generar un documento de elicitación que brinde agilidad para pasar al diseño rápidamente.

D17 Using Audio and Collaboration Technologies for Distributed Requirements Elicitation and Documentation. En este trabajo se presenta un método para elicitar y documentar requisitos, que utiliza tecnologías de colaboración y grabaciones de audio para permitirles a las partes interesadas la elicitación y la documentación conjunta. Esta documentación se puede realizar mediante colaboración entre todas las partes, y el control de cambios en la trazabilidad se realiza mediante el control de versiones integradas. Para estructurar la documentación de una plantilla previamente desarrollada se pueden utilizar términos clave capturados y definidos en un glosario, pero, aunque estos términos son útiles para establecer un lenguaje común y para evitar posibles ambigüedades, la relación posterior con los términos utilizados en la documentación no es clara y se dificulta darle la trazabilidad esperada.

D18 Modern Trends Towards Requirement Elicitation. De acuerdo con el autor, la ingeniería de requisitos es un grupo de actividades que ayudan a encontrar y comunicar las necesidades, el propósito y el contexto de un sistema. Este proceso se inicia con la elicitación de los requisitos, a lo que considera como el principal factor en el fracaso de la mayoría de los proyectos software. En esta propuesta presenta una forma para analizar los datos elicitados, que se obtienen a partir de la información y la documentación de los requisitos del sistema, y desde el que se extraen las directrices modeladas mediante la aplicación de diferentes técnicas. También propone un plan para elicitar requisitos, que pretende superar las limitaciones que enfrentan los ingenieros al momento de documentar lo elicitado. Aunque el objetivo de la documentación es claro, deja a las demás partes interesadas sin un rol claro, por lo que la versión final es una visión solo para y de los ingenieros, sin tener en cuenta el diálogo que se necesita con los clientes y usuarios.

ANÁLISIS DE RESULTADOS

Aunque en los documentos que conforman la muestra los autores aceptan y asumen a la ingeniería de requisitos como la fase más importante del ciclo de vida de la ingeniería de software, y a que brindan especial cuidado a la elicitación, llama la atención el hecho de que trabajen, propongan y difundan muy poco acerca de cómo documentar esta etapa. La mayoría se limita a expresar que se debe documentar con seriedad, claridad y formato, para lo que proponen algunas estructuras, pero, de la muestra, prácticamente ninguno describe la forma para lograr un documento con estas características. Documentar la elicitación de requisitos es importante porque este documento es la guía sobre la que se desarrollan las demás etapas de la ingeniería de requisitos, que a su vez es la base para realizar las demás fases del ciclo de vida del producto.

Las estructuras sugeridas pasan por tablas, gráficas, casos de uso, puntos de vista, escenarios, y hasta pistas de audio, que se proponen como base para el documento de esta etapa. Pero, debido a la complejidad de los problemas actuales que se deben resolver con productos software, esto no es suficiente, porque se requiere un modelo matemáticamente estructurado para crear un documento formal, o semiformal, cuya información permita resolver las ambigüedades de los requisitos, pero con la flexibilidad suficiente para incorporar las modificaciones y actualizaciones que se presentan en la elicitación. Esto no se plantea, ni se describe en los trabajos analizados en esta revisión, y se debe a que la mayoría apunta a la documentación de la especificación, la etapa final de la ingeniería de requisitos. Por otro lado, los estudios que conforman la muestra final se orientan a estudios exploratorios y de trabajo en grupos interdisciplinarios, cuyos resultados hacen evidente la necesidad de un estándar para orientar la documentación de la elicitación. En parte porque los investigadores se han dado cuenta que sus formatos no funcionan en todos los contextos, por lo que cada vez se deben reestructurar.

Asimismo, llama la atención que pocos trabajos de la muestra final tienen en cuenta a los métodos formales [D3, D6, D8, D18], mientras que la mayoría se basa en un proceso de elicitación teniendo como referente al lenguaje natural [D1, D2, D4, D5, D7, D9-D17]. Esta práctica genera uno de los problemas de mayor impacto en la ingeniería de requisitos: la ambigüedad de la descripción, que hace que las partes interesadas no puedan clarificar y unificar sus propias necesidades. Lo que sí queda demostrado es que la mayoría de propuestas pretende pasar directamente a la especificación sin tener un adecuado documento de la elicitación.

Respuestas a las preguntas de investigación

P1 ¿Cuál es el nivel de difusión acerca de cómo documentar la elicitación?
Luego de aplicar el proceso de búsqueda en las diferentes bases de datos se encontraron 73 trabajos que contenían por lo menos una de las palabras clave seleccionadas. Un número que puede considerarse reducido dada la cantidad de publicaciones que año tras año se suman a los contenidos de estas bases de datos. Esto que valida la hipótesis del proyecto de investigación en el que se suscribe esta revisión, en el sentido de que la comunidad está trabajando poco acerca de cómo documentar la elicitación de requisitos. Cerca del 75% contiene solo alguna de las palabras clave y en el cuerpo del documento no trasciende como aporte significativo, ni siquiera como campo para futuros trabajos. Solo alrededor del 25% de los trabajos (18 en total) contiene alguna descripción o sugerencia al proceso de la documentación de la elicitación.

P2 ¿Qué tipo de trabajos se difunde? En la muestra se proponen framework como conjunto estandarizado de prácticas para enfocar este tipo de problemática; también se habla de herramientas software que pueden ayudar a mejorar el proceso, como ATLAS [D16], que permite analizar los datos empíricos obtenidos de las entrevistas, y ArHJENEA [D14], que les permite a los usuarios registrar sus experiencias y puntos de vista y negociar los requisitos en forma colaborativa. En cuanto al tipo de trabajos, para esta revisión se determinaron las variables de opinión, reflexión, e investigación, y los resultados se muestran en la Tabla 2. De acuerdo con estos datos se puede concluir que la mayoría de investigadores se orientan por la opinión y la reflexión, y en menor proporción por la investigación en este tema. Esta baja participación en investigación se puede deber a que este tema es una cuestión que apenas comienza a preocupar a la comunidad, y a que los investigadores la perciben como un hito importante para el mejoramiento de la calidad del desarrollo de software. Algunos autores de la muestra argumentan que este tema es un problema en la mayoría de los proyectos actuales, en parte porque las empresas estructuran sus propios formatos y metodologías para documentar su proceso de elicitación en cada proyecto. Pero, debido a que hoy es posible afirmar que esta forma de trabajar no es la más recomendada, porque las necesidades son diferentes y los contextos también, toma importancia la necesidad de un estándar para documentar la etapa de elicitación.

Tabla 2. Tipo de trabajos publicados.

P3 ¿Cómo se difunden los trabajos? Para responder a esta pregunta solo se analizaron los trabajos que hacen énfasis en investigación, porque el objetivo era encontrar de qué forma se están difundiendo propuestas que busquen solucionar el problema de la documentación de la elicitación. La mayoría son artículos publicados en revistas que se encuentran en las bases de datos utilizadas, pero también se hallaron trabajos en congresos, libros, y reportes técnicos de organismos internacionales. Se esperaba que los artículos fueran el medio más utilizado para difundir las investigaciones pero son los eventos los que tienen mayor acogida por los investigadores, como se observa en la Tabla 3. Estos resultados se pueden explicar desde el punto de vista que un congreso es un encuentro en el que se puede discutir directamente con la comunidad, y se retroalimenta más rápidamente. De esta forma los investigadores pueden complementar rápidamente su trabajo o darle un nuevo giro para luego experimentar nuevamente.

Tabla 3. Cómo se difunden los trabajos.

P4 ¿Cuál es nivel de éxito y el grado aceptación y seguimiento en la comunidad?
Para verificar el grado de aceptación que la comunidad hace de estas propuestas se realizó una búsqueda de trabajos que citan los documentos de la muestra final. En el proceso se incluyeron las mismas bases de datos que se utilizaron para esta revisión. Teniendo en cuenta que luego de ser difundida una propuesta necesita por lo menos cuatro años para lograr un adecuado nivel de aceptación y de difusión en la comunidad, y que se acepta que un nivel es aceptable si el trabajo ha obtenido en ese lapso de tiempo por lo menos cuatro referencias en medios de igual o mayor impacto que el original [11], en la Tabla 4 se muestran los resultados que arrojó la búsqueda para responder a esta pregunta.

Tabla 4. Nivel de aceptación.

Estos resultados ratifican lo expresado acerca del tiempo que la comunidad se toma para comprender, utilizar, aceptar y referenciar una propuesta. D5, D2, D3 y D4, que poseen el mayor nivel de aceptación, son trabajos de los años 90, por lo que han permanecido el tiempo suficiente para lograr impactar a los demás investigadores; mientras que D16 y D18 apenas están llegando al tiempo necesario de comprensión y posiblemente de referenciación. En términos generales, se puede concluir que el nivel de aceptación y seguimiento a estos trabajos es bueno, debido a que 10 de los 18 (55,6%) documentos de la muestra tienen un nivel entre aceptable y alto.

En cuanto al nivel de éxito en la aplicación en la industria se encontró que D2 y D4 son las propuestas que más se han experimentado, y que tienen un reporte de aceptación bueno. El hecho de que sean las más aplicadas se puede aplicar por el alto reconocimiento que tienen sus autores. Este nivel en el reporte no significa que sean las de mayor éxito, porque también se encontraron reportes en las que se describen problemas de acoplamiento y de comprensión al momento de aplicarlas. En cuanto a ATLAS y ATHENA, aunque son framerworks que no requieren demasiado esfuerzo para aplicar y experimentar, no se encontraron reportes que permitiera evaluar su nivel de éxito.

CONCLUSIONES

Este artículo es el resultado de una revisión sistemática de la literatura acerca de las propuestas para documentar la elicitación de requisitos, y pretende ser un compendio del estado actual en la investigación relacionada. Para lograrlo, se realizó una búsqueda en las bases de datos para recopilar los artículos que relacionaran esta temática. Aunque la muestra inicial fue amplia (73 trabajos), en el proceso de inclusión y exclusión aplicado se conformó una muestra final de 18. Esto se debe a que la mayoría de los no incluidos apunta a la documentación de la especificación, la etapa final de la ingeniería de requisitos. Por otro lado, los estudios que conforman la muestra final se orientan a estudios exploratorios y de trabajo en grupos interdisciplinarios, cuyos resultados hacen evidente la necesidad de un estándar para orientar la documentación de la elicitación. En parte, porque los investigadores se han dado cuenta que sus formatos funcionan en un contexto pero para otro no, por lo que deben reestructurarlo en cada uno.

Asimismo, llama la atención en los resultados que pocos trabajos de la muestra final tienen en cuenta a los métodos formales, mientras que la mayoría menciona o se basa en un proceso de elicitación en lenguaje natural. Este ejercicio genera uno de los problemas de mayor impacto en la ingeniería de requisitos: la ambigüedad de la descripción que hacen las partes interesadas acerca de sus necesidades.

Aunque en la mayoría de estudios analizados se describe a la documentación de la elicitación como un proceso importante y de valor para las demás actividades de la ingeniería de requisitos, estos principios no se tienen en cuenta, porque la mayoría pretende pasar directamente a la especificación sin tener un documento adecuado de la elicitación. Esto se evidencia en los diferentes reprocesos que deben realizar los ingenieros en el diseño del producto.

La investigación de la que se origina este artículo tiene como propósito estructurar un modelo semi-formal para documentar la elicitación de requisitos, y, de acuerdo con los resultados encontrados en esta revisión, se necesita de forma acelerada. Porque mientras no se tenga una propuesta estructurada y genérica esta documentación se seguirá pasando por alto, ocasionando que la especificación no sea la adecuada para continuar con las demás fases del ciclo de vida del producto.

REFERENCIAS

[1] A.M. Davis. "Software Requirements: Objects, functions, and states". Prentice Hall, USA. 1993. ISBN-10: 013805763X.

[2] E. Serna M., C.A. Castro and R. Botero. "SEDLO: Software Engineering for developing learning objects". In N.R.P. Chagas (Ed.). Proceedings of the 6th Euro American Conference on Telematics and Information Systems (EATIS), pp. 347-353. 2012. ISBN: 978-1-4503-1012-3.

[3] P. Loucopoulos and V. Karakostas. "System Requirements Engineering". McGraw-Hill International. USA. 1995. ISBN: 0077078438.

[4] D. Mustelier and Y. Viera. "Variables that define the complexity of the software functional requirements". Revista Antioqueña de las Ciencias Computacionales y la Ingeniería de Software (RACCIS). Vol. 3 N° 2, pp. 38-42. 2013. ISSN: 2248-7441.

[5] E. Serna M. and A. Serna A. "MoDeMaRE: Model to Develop and Management the Requirements Engineering". Advances in Engineering Software. In press. 2015.

[6] M. Christel and K. Kang. "Issues in Requirements Elicitation". Technical Report CMU/SEI-92-TR-012. Software Engineering Institute. Carnegie Mellon University. 1992.

[7] E. Serna M. "Formal methods and Software Engineering". Revista Virtual Universidad Católica del Norte. N° 30, pp. 158-184. 2010. ISSN: 0124-5821.

[8] B. Kitchenham. "Procedures for undertaking systematic literature reviews." Technical Report. Computer Science Department. Keele University. 2004.

[9] B. Kitchenham, O. Brereton, D. Budgen, M. Turner, J. Bailey and S. Linkman. "Systematic literature reviews in Software Engineering: A systematic literature review". Information and Software Technology. Vol. 51 N° 1, pp. 7-15. 2009. ISSN: 0950-5849.

[10] T. Dyba and T. Dingsoyr. "Empirical studies of agile software development: A systematic review". Information and Software Technology. Vol. 50 N° 9-10, pp. 833-859. 2008. ISSN: 0950-5849.

[11] E. Serna M. "Current State of Research on Non-Functional Requirements. Revista Ingeniería y Universidad. Vol. 16 N° 1, pp. 225-246. 2012. ISSN: 0123-2126.


Recibido el 14 de noviembre de 2014, aceptado el 31 de diciembre de 2015


Artículos Relacionados

# Título Ver
1
Proceso y herramienta para la rastreabilidad de requisitos (2013)
Marco Toranzo, Gilberto Cysneiros, Felipe Tirado
HTML | PDF
2
Una propuesta de metaontología para la educción de requisitos (2010)
Carlos M. Zapata, Gloria L. Giraldo, Jhon E. Mesa
HTML | PDF
3
Comparación de efectividad de las técnicas de educción de requisitos software: visión novel y experta (2012)
Dante Carrizo Moreno
HTML | PDF
4
Transformación de requisitos representados en esquemas preconceptuales a modelos de interacción de sistemas holónicos (2014)
Carlos M. Zapata, Gloria L. Giraldo, Germán Zapata, Adrián S. Arboleda
HTML | PDF
5
Extracción de objetivos y su clasificación en el modelo de KAOS a partir del procesamiento del lenguaje natural (2015)
Luis Alfonso Lezcano R., Jaime Alberto Guzmán L., Sebastián Alonso Gómez A.
HTML | PDF
6
Atributos contextúales influyentes en el proceso de educción de requisitos: una exhaustiva revisión de literatura (2015)
Dante Carrizo Moreno
HTML | PDF
7
¿Qué significa para los investigadores la "técnica de educción correcta"? (2016)
Dante Carrizo, Cristián Ortiz, Luis Aguirre
HTML | PDF
8
Clasificación de prácticas de educción de requisitos en desarrollos ágiles: un mapeo sistemático (2016)
Dante Carrizo, Jorge Rojas
HTML | PDF
9
Requisitos de un Dashboard orientado a metas con i*: un caso de estudio (2016)
Alain Pérez Acosta, Mailyn Moreno Espino, Reinier Bandón Casamayor
HTML | PDF
10
Perfil de adecuación de las técnicas de educción de requisitos software (2016)
Dante Carrizo, Iván Quintanilla
HTML | PDF
11
Elicitación de requisitos no funcionales basada en la gestión de conocimiento de los stakeholders (2018)
Sandra L. Buitrón, Brenda L. Flores-Rios, Francisco J. Pino
PDF
12
Metodologías, técnicas y herramientas en ingeniería de requisitos: un mapeo sistemático (2018)
Dante Carrizo, Jorge Rojas
PDF
13
Proceso y progreso de la formalización de requisitos en Ingeniería del Software (2020)
Edgar Serna M., Alexei Serna A.
PDF
14
Método para la representación semi-automática de modelos conceptuales desde documentos de negocio escritos en lenguaje natural en español (2020)
Diego Alejandro Marín-Alvarez, Bell Manrique-Losada, Juan Bernardo Quintero
PDF
15
Mantenibilidad del Software. Consideraciones para su especificación y validación (2020)
Jenny Adones Farfán, Vianca Vega-Zepeda
PDF


Otros Artículos

# Título Ver
1
Aplicaciones de inteligencia artificial en procesos de cadenas de suministros: una revisión sistemática (2016)
Gabriel A. Icarte Ahumada
HTML | PDF
2
Teoría de Bill Mundy y el ángulo efectivo de ataque de herramientas de corte en aleaciones de cobre (2007)
Juan Miguel Godoy R., Jorge Vergara D., Percy Oviedo O., Martín Quispe Y., Edward Gallardo M., Leandro Ramírez H.
HTML | PDF
3
Comportamiento de planchas onduladas de fibrocemento sometidas a cargas de succión (2018)
Julio Cesar Molina, Daniel Villas Bôas, Murilo Negreli, Alexandre Jorge Duarte de Souza
PDF

Desarrollado por: Cristian Díaz Fonseca - cfonseca@matiasluke.cl