SciELO - Scientific Electronic Library Online

 
 número24Las redes sociales web como herramienta para gestionar información en procesos de co-creación índice de autoresíndice de assuntosPesquisa de artigos
Home Pagelista alfabética de periódicos  

Serviços Personalizados

Journal

Artigo

Indicadores

Links relacionados

  • Não possue artigos similaresSimilares em SciELO

Compartilhar


RISTI - Revista Ibérica de Sistemas e Tecnologias de Informação

versão impressa ISSN 1646-9895

RISTI  no.24 Porto out. 2017

https://doi.org/10.17013/risti.n.69–83 

ARTÍCULOS

Factores sociales y humanos que afectan el proceso de educción de requerimientos: una revisión sistemática

Social and human factors that affect the requirements elicitation process: a systematic review

Ítalo Donoso Barraza1, Vianca Vega Zepeda1

1Departamento de Ingeniería de Sistemas y Computación, Universidad Católica del Norte, Angamos 0610, 1270709, Antofagasta, Chile. italo.donoso@ucn.cl , vvega@ucn.cl


 

RESUMEN

La Ingeniería de Requerimientos (RE, por sus siglas en inglés) es uno de los procesos más importantes durante el desarrollo de software y su correcta ejecución afecta en gran medida el éxito del producto desarrollado. El objetivo general de este proceso es entender con precisión el problema que se pretende resolver. Las actividades de la RE requieren un alto grado de interacción y comunicación entre todos los involucrados. Múltiples factores afectan este proceso, destacando el aspecto social y emocional de la persona, que no son considerados comúnmente por técnicas de educción tradicionales. El objetivo de este trabajo es identificar factores sociales y humanos no cubiertos durante el proceso de educción y que puedan afectar negativamente el éxito del producto. Lo anterior, mediante un proceso de revisión sistemática sobre fuentes bibliográficas reconocidas por la comunidad científica siguiendo el enfoque de tres grandes actividades descritas por Barbara Kitchenham.

Palabras-clave: Ingeniería de Requerimientos, Factores Sociales, Educción.


 

ABSTRACT

Requirements engineering (RE) is one of the most important phases during the software development and its proper execution greatly affects the developed product success. The overall objective of the RE is to understand accurately the problem that it is intended to solve. RE activities require a high degree of interaction and communication between all stakeholders. Multiple factors affect this process, highlighting social and emotional aspects of people, which are not commonly considered by traditional elicitation techniques. The objective of this work is to identify social and human factors that are not covered during the elicitation process and they may negatively affect the product success. The review process was carried out on bibliographic sources recognized by scientific community following three major activities described by Barbara Kitchen approach.

Keywords: Engineering Requirements, Social Factors, Elicitation.


 

1. Introducción

La Ingeniería de Requerimientos (RE, por sus siglas en inglés) es un proceso que abarca un conjunto de actividades que se realizan comúnmente al inicio del ciclo de desarrollo de software. La educción de los requerimientos, que tiene por objetivo descubrir las necesidades de los usuarios y capturar los requerimientos del sistema, es la etapa más importante de este proceso y su correcta aplicación repercute en gran medida en el éxito del producto final (Hastie & Wojewoda, 2015). Por otra parte, una incorrecta aplicación de las tareas de educción afectará negativamente en aspectos tan importantes como: el alcance del proyecto, el presupuesto definido y los plazos de entrega acordados previamente (Kumari & Anitha, 2016; Okewu, 2015).

Los desafíos que enfrenta la RE son variados y una gran parte de estos se presentan al momento de educir las necesidades del producto debido a la falta de comunicación e interacción entre el equipo de desarrollo y los usuarios; individuos de distintas disciplinas con diferentes niveles de conocimiento técnico (Hadar, Soffer, & Kenzi, 2014). La Ingeniería de Requerimientos debe lidiar con la brecha de comunicación entre todos los involucrados. No solo debe enfocarse en el medio utilizado para producir la comunicación, o los artefactos dispuestos en las instancias en que se reúnen stakeholders y especialistas, es igual de importante considerar aspectos cognitivos, emocionales y motivacionales propios de la «naturaleza social» de la persona que contribuyan a la transferencia del conocimiento de manera exitosa (Apshvalka, Donina, & Kirikova, 2009). El conocimiento es la fuente para definir y estructurar los requerimientos de un producto software, este puede provenir del ambiente o dominio de la aplicación, estar alineado con las estrategias del negocio, encontrarse inmerso en las infraestructuras organizacionales, o suscitado en actividades financieras y operacionales del negocio (Burnay, 2016). Sin embargo, la fuente más importante es el individuo y su conocimiento reside en la mente humana.

Si bien existen diversas técnicas para elicitar los requerimientos de software en un contexto particular (Carrizo, Dieste, & Juristo, 2014), no existe un conjunto amplio de estudios que abarquen aspectos sociales y humanos en el proceso de educción. En este sentido, el objetivo del presente trabajo es identificar qué aspectos sociales propios de la naturaleza de la persona no son considerados comúnmente cuando se realizan tareas de educción de requerimientos que pueden afectar negativamente el éxito del producto final. La identificación de dichos aspectos se realizó mediante un proceso de revisión de la literatura siguiendo el enfoque de Bárbara Kitchenham (Kitchenham, 2004) sobre cuatro fuentes bibliográficas reconocidas por la comunidad científica. Los artículos seleccionados corresponden a trabajos ligados al ámbito de la Ingeniería de Software y, en específico, a la Ingeniería de Requerimientos enfocados en el proceso de educción de requerimientos sobre un producto software. El trabajo realizado y los resultados descritos en dichos artículos fueron analizados, agrupados y clasificados en seis categorías llamados “factores sociales y humanos”.

El presente documento se estructura como sigue: la sección 2 describe de manera general el método utilizado para ejecutar la revisión sistemática, la sección 3 describe el proceso de planificación previo a la búsqueda de los estudios, la sección 4 muestra el método empleado para la selección de los artículos a considerar dentro de la revisión, la sección 5 sintetiza los resultados extraídos de los veinticinco artículos analizados, la sección 6 enfatiza las conclusiones del trabajo realizado orientado a los resultados obtenidos, y finalmente la sección 7 describe la literatura consultada.

2. Proceso de investigación

Los objetivos que guían la ejecución de una revisión sistemática son variados y están conectados estrechamente con el tema de investigación abordado (Kitchenham, 2004). Sin embargo, el foco principal de una revisión sistemática es sintetizar el trabajo existente dentro de un área de interés en particular, mediante una estrategia de búsqueda definida que permita evaluar la completitud de la estudios analizados (Kitchenham, 2004).

La revisión sistemática se realizó siguiendo tres grandes actividades: planificación, ejecución y reporte de los resultados obtenidos según el enfoque de Barbara Kitchenham (Kitchenham, 2004). Cada una de estas actividades a su vez describen un conjunto de tareas relevantes que se realizan dependiendo del foco u objetivo del estudio. Para la presente revisión sistemática se han adaptado ciertas tareas descritas por dichas actividades. Las siguientes secciones describen las actividades realizadas en cada una de las actividades mencionadas anteriormente, es decir: planificación, ejecución y reporte.

3. Planificación

3.1. Pregunta de investigación

En cualquier revisión sistemática existe una o más preguntas de investigación que motivan el estudio de un tema particular en un área de investigación específica. Con la ejecución de la revisión sistemática se pretende dar respuesta a dicha pregunta mediante el análisis y síntesis de los datos obtenidos. De este modo, el área de investigación corresponde a la Ingeniería de Software y más en particular, al proceso de educción de requerimientos dentro de la RE.

La pregunta de investigación que centró la realización del presente artículo de revisión fue:

RQ1: ¿Qué problemas y/o factores sociales y humanos afectan el proceso de obtención de requerimientos de software?

3.2. Lenguaje del estudio

Dentro del universo de estudios analizados solo se consideraron aquellos artículos escritos en el idioma inglés o español.

3.3. Palabras claves y sinónimos

En la Tabla 1 se especifican las palabras claves que fueron consideradas en la revisión sistemática y que, a su vez, fueron utilizadas para formular la cadena de búsqueda.

 

 

Se ha utilizado la palabra «elicitación» en lugar de «educción» en la cadena de búsqueda en español. Lo anterior, debido a que, dentro de la Ingeniería de Software y dentro del contexto del idioma inglés, se utiliza para describir la transferencia de información de un individuo a otro mediante artefactos, técnicas o metodologías definidas con el objetivo de capturar requerimientos y descubrir necesidades de un cliente. Se entiende por individuo a uno o más grupos de personas, o entidades que conforman una organización.

3.4. Cadena de búsqueda

La cadena utilizada en los motores de búsqueda de las revistas científicas se puede observar en la Tabla 2. Al igual que las palabras clave, se ha utilizado la cadena de búsqueda tanto en inglés como en español. Es importante destacar que para algunos motores no está admitido el uso de caracteres especial como paréntesis, debiendo adaptar así la cadena a la sintaxis del buscador en cuestión.

 

 

3.5. Fuentes bibliográficas

Los artículos se han obtenido a partir de cuatro fuentes de investigación reconocidas por la comunidad científica. El acceso a los recursos ha sido posible mediante los privilegios otorgados a la cuenta de alumno de la Universidad Católica del Norte y su vínculo con la fuente.

A continuación, se indica el listado de fuentes consultadas:

·      ACM Digital Library

·      Science@Direct

·      SpringerLink

·      ISI Web of Knowledge

4. Ejecución

Una vez definida la cadena de búsqueda y las fuentes bibliográficas a consultar, se procedió a obtener los artículos desde las revistas científicas mediante la aplicación de la cadena en los motores disponibles en el sitio web de cada fuente.

Los trabajos recuperados fueron ordenados siguiendo los siguientes filtros:

·      Año de publicación comprendido entre 2011 y 2017

·      Orden descendente según la relevancia del artículo (de acuerdo al número de coincidencias de las palabras clave contenidas en la cadena de búsqueda y aquellas mencionadas en el cuerpo del artículo)

·      Área de interés relacionada con «Ciencias de la Computación» e «Ingeniería de Software»

·      Idioma de los artículos en inglés o español

La cantidad de artículos recuperados, luego de aplicar los filtros, se muestran en la Tabla 3. Como se puede observar, la gran mayoría de artículos recuperados comprenden las fuentes bibliográficas Science@Direct y SpringerLink alcanzando un 98% del total de estudios obtenidos entre ambas fuentes. La totalidad de los resultados arrojados por los motores de las fuentes comprendieron trabajos publicados en el idioma inglés, no así en español para el cual no se obtuvieron artículos.

 

 

4.1. Criterios de inclusión y exclusión

Los criterios de inclusión y exclusión deben estar alineados con el objetivo de la revisión sistemática. Estos criterios son aplicados con el fin de filtrar y seleccionar aquellos estudios primarios que proporcionen una evidencia directa y que permitan responder a la pregunta de investigación definida (Kitchenham, 2004).

La Tabla 4 resume los criterios de inclusión y exclusión considerados en la ejecución de esta revisión sistemática.

 

 

4.2. Procedimiento para la selección de artículos

El primer paso consistió en adaptar la cadena de búsqueda a la sintaxis definida de los cuatro motores virtuales de las fuentes bibliográficas. Luego, se aplicaron los filtros por año y área (ciencias de la computación e ingeniería de software) y se ordenaron de acuerdo al nivel de ocurrencia de las palabras claves tanto en el título, como en el resumen (abstract).

Posteriormente, fueron seleccionados los primeros 40 artículos de cada revista a los cuales se les aplicó los criterios de inclusión y exclusión definidos en la Tabla 4. En la fuente ISI Web of Knowledge el buscador arrojó solo 11 artículos los cuales fueron considerados en su totalidad para aplicar los criterios antes mencionados. En ningún motor de búsqueda se encontraron documentos en español.

Una vez aplicados los criterios de inclusión, se logró obtener un total de 25 artículos elegibles para someterlos al proceso de análisis de datos. La Tabla 5 muestra la cantidad de artículos seleccionados por fuente bibliográfica.

 

 

Los estudios se clasificaron con base en su objetivo principal agrupándolos en dos categorías generales:

1.     Estudios teóricos, empíricos y propuestas metodológicas enfocadas en el proceso de educción y,

2.    Aquellos que incorporan y sustentan la aplicación del punto 1 en uno o más casos de estudios.

La Tabla 6 dispone los veinticinco artículos seleccionados, entre los cuales un 36% de ellos se basan en la aplicación mediante casos de estudios referentes al proceso de Ingeniería de Requerimientos. Por un tema de legibilidad, se han suprimido los nombres de los artículos. Sin embargo, estos se encuentran debidamente referenciados en el apartado final de este documento.

 

 

Los artículos fueron analizados enfocándose en el proceso de educción considerando el factor humano como eje central, destacando los inconvenientes o problemas al momento de educir, validar y documentar los requerimientos según el desarrollo involucrado. Como resultado, se agruparon en seis categorías los atributos recurrentes y relacionados al ámbito social y humano del proceso: ambigüedad, conocimiento tácito, comunicación, entendimiento, ámbito cognitivo, emocional y motivacional, resistencia y valores humanos.

5. Resultados y discusión

La Ingeniería de Requerimientos es un proceso complejo y a la vez crítico durante el desarrollo de software. La información capturada por los Ingenieros o Especialistas en Requerimientos debe ser interpretada, analizada, modelada y fuertemente validada (Hadar et al., 2014) antes de comenzar las etapas propias del ciclo de desarrollo, independiente del modelo tradicional o ágil que se utilice (Würfel et al., 2016).

La etapa de educción de los requerimientos es una de las actividades de comunicación más intensas de este proceso la cual demanda una compleja interacción entre los individuos que se extiende desde el entendimiento de las necesidades del negocio, la toma de decisiones, la gestión de los cambios y la resolución de conflictos entre los stakeholders (Calefato et al., 2012). Si bien la comunicación es el núcleo para producir especificaciones sólidas que se sustenten en los datos capturados, se requiere adicionalmente un canal o medio que permita que esta fluya a través de los distintos stakeholders dentro de la organización que estén interesados en el producto a desarrollar (Liebel et al., 2016).

La entrevista es el método empleado mayoritariamente en el área y el entrevistador debe poseer la capacidad de hacer frente a las «emociones» de los stakeholders para poder manejarlos, promover la motivación en la participación, procurar que la comunicación se realice «cara a cara» transmitiendo confianza, seguridad y describiendo ventajas para el usuario sobre el nuevo producto desarrollado o adquirido (Apshvalka et al., 2009). Lo anterior, es una tarea compleja ya que, en este escenario, el especialista necesita desempeñarse como motivador y «psicólogo» a la vez para poder capturar las necesidades de los individuos de la manera correcta. Esto conlleva la comprensión de procesos cognitivos, emocionales y motivacionales de quienes están inmersos en el proceso desde la perspectiva del cliente y del equipo de desarrollo; tarea compleja especialmente para un ingeniero de software cuya formación profesional excluye este ámbito. Estas múltiples técnicas de educción no contemplan ampliamente estos aspectos sociales a priori considerando que pueden afectar negativamente el éxito del proyecto si no se controlan de la manera adecuada.

Como se ha mencionado anteriormente, la RE es un proceso intensivo de transferencia de información entre quienes son «poseedores del conocimiento» desde el lado del cliente-usuario y el equipo de desarrollo. Este conocimiento está incrustado casi en su mayoría en los stakeholders y es labor del especialista en requerimientos poder abstraer este conocimiento apoyado por procesos cognitivos, emocionales y motivacionales (Apshvalka et al., 2009). En este sentido, producto de la ejecución de la presente revisión sistemática, se identificaron aquellos factores sociales y humanos provenientes desde analistas y clientes que pueden afectar el proceso de educción y, en contra parte, otorgar una base para su consideración al momento de efectuar actividades de RE. La ocurrencia de los problemas y/o inconvenientes que exponen los artículos al momento de educir requerimientos fueron agrupados en una categoría de más alto nivel que responde a factores sociales y humanos descritos en la Tabla 7.

 

 

A continuación, se destacan los aspectos más relevantes que definen a cada factor descrito en la Tabla 7.

Ambigüedad

Se traduce comúnmente en malentendidos durante las entrevistas provocando especificaciones poco claras e incompletas producto del uso del lenguaje natural. Desde el lado del cliente se manifiesta en el sentido de que este último se expresa utilizando un lenguaje lleno de jergas asociadas a su dominio provocando la interpretación múltiple de los analistas (Burnay et al., 2014a), o entrega muy poca o demasiada información que se aleja de los límites de procesamiento del analista durante una entrevista.

Conocimiento tácito

El conocimiento tácito dentro de la RE se refiere al «conocimiento» que no es transmitido desde el cliente al analista (Ferrari et al., 2016). Este conocimiento tácito es difícil de adquirir si el analista no se encuentra inmerso dentro del dominio de los usuarios y/o del cliente. En general, la psicología indica que tener conocimiento previo del dominio puede causar tendencia a trabajar de la misma forma y abordar los problemas bajo esa perspectiva sin proceder a un análisis previo; es un inhibidor de la creatividad (Hadar et al., 2014).

Comunicación

La comunicación es sin duda el elemento intrínseco del proceso de educción, sin un adecuado entendimiento de las partes existe un alto índice de rechazo del producto final dados los vacíos y malentendidos durante el proceso de análisis. Los principales factores que afectan la comunicación se producen desde el lado del cliente y abarcan distintos ámbitos:

·       Comunicación infrecuente producto de las barreras organizacionales (Sethia & Pillai, 2014).

·       Falta de habilidades de presentación, habilidades de escritura, falta en la organización de ideas y organización general de la información.

·       Respuesta tardía con base en el canal de comunicación utilizado aumentando los tiempos que tomará el desarrollo del producto.

Las habilidades de comunicación de los stakeholders determinarán la calidad de los requerimientos (Shuhud et al., 2013).

Entendimiento

El entendimiento mutuo está estrechamente ligado con los tres factores descritos anteriormente, es decir, ambigüedad, conocimiento tácito y comunicación que producen generalmente malentendidos. Esto se debe a que la RE es un proceso en donde participan individuos de distintas disciplinas abarcando un amplio conjunto de conceptos propios a cada una de ellas. El foco central del entendimiento es la negociación la cual es fundamental para definir los límites del sistema, establecer prioridades en los requerimientos, identificar aquellas personas relevantes con la autoridad y poder en la toma de decisiones, y finalmente discutir los cambios que se producen sobre los requerimientos (Anwar et al., 2011; Shuhud et al., 2013). El especialista en requerimientos debe poseer un alto grado de comunicación interpersonal que le permita negociar en situaciones críticas y, a su vez, tratar con las diversas personalidades de los stakeholders enfocado en la resolución de conflictos.

Ámbito cognitivo, emocional y motivacional

La dimensión social es un área muy poco explorada dentro de la Ingeniería de Software, esto se debe a que los ingenieros se enfocan más bien en aspectos técnicos por sobre los sociales (Ramachandran et al., 2011). En esta área destacan tres aspectos importantes (Apshvalka et al., 2009):

1.     Cognitivo: los individuos hacen uso de sus facultades mentales para producir la interacción analistas y stakeholders, esto les permite percibir la información de su entorno, interpretarla, representarla para el uso correcto en la toma de decisiones.

2.    Emocional: permite reconocer las «emociones» de los stakeholders derivadas de lo que supone representará el sistema para su entorno o trabajo. En este ámbito es importante que el analista disponga de las cualidades que le permitan responder ante situaciones en donde los stakeholders, por ejemplo, asuman que el nuevo producto supone una carga adicional en su forma de trabajar, o en un caso extremo, que dicho producto reemplazará las actividades que desempeña mediante procesos automatizados de software. En ambos casos el especialista en requerimientos debe elegir cuidadosamente el método y forma en que expone sus inquietudes con todos los involucrados.

3.    Motivacional: es fundamental para predecir, detectar y evitar emociones reacias durante el proceso de educción; el ingeniero debe actuar como un pseudo-sicólogo promoviendo la participación del proceso en un ambiente agradable, de confianza, franqueza y empatía.

Resistencia

La resistencia al cambio es un reto conocido dentro la Ingeniería de Software y en particular en la RE se traduce en la falta de participación de los stakeholders en las actividades de educción (Anwar et al., 2011). Este desinterés está directamente conectado con el ámbito emocional y motivacional de la persona, ya que si el analista no expone de manera directa los beneficios del nuevo producto para los stakeholders, estos últimos no se verán atraídos por el proceso, provocando finalmente que el analista seleccione o consulte a otros individuos con un rango menor en la jerarquía organizacional lo cual conllevará a un inminente cambio en la especificación que puede suscitarse en fases de implementación y despliegue (Apshvalka et al., 2009).

Valores humanos

Un aspecto que no se considera prácticamente en los proyectos de desarrollo es la valoración que los usuarios poseen del sistema. Esta valoración abarca la confianza, autonomía y seguridad que el sistema le brinda al usuario ya sea en su trabajo o en su vida cotidiana (Harbers et al., 2015). Estos no siempre son previsibles durante el desarrollo del producto ya que un producto muy seguro restaría facilidad de uso y, en el otro extremo, un producto eficiente no necesariamente sería confiable. Actualmente es un campo que posee muy poca evidencia teórica y empírica que abarque la importancia que supone la existencia de un producto software dentro del entorno de trabajo de los usuarios alineado con lo que estos últimos creen importante y valioso dentro de su entorno, vida e interacción con sus pares.

6. Conclusiones

El proceso de educción de requerimientos varía entre una técnica y otra, y en algunos casos está alineado con el enfoque tradicional o ágil que se emplee para educir las necesidades de los stakeholders. Independientemente de la técnica utilizada, los retos que enfrenta la RE son variados y existe un porcentaje de estos asociados a la naturaleza social de la persona que no son tratados a priori por técnicas de educción existentes. Lo anterior, se debe a que el Ingeniero de Software no recibe una formación profesional enfocada en el aspecto social y humano dentro de su disciplina, lo que provoca que sea un área difícil de abordar, más no imposible, desde la perspectiva de las ciencias de la ingeniería.

La comunicación es, sin lugar a dudas, el núcleo de las actividades definidas por la Ingeniería de Requerimientos considerando que en el proceso participan individuos con preferencias, prioridades, objetivos y metas distintas del dominio que hacen que los especialistas en requerimientos necesiten de enfoques más amplios que les entreguen las herramientas necesarias para cubrir, en parte, las brechas sociales que se producen en las etapas tempranas de desarrollo.

La identificación de estos factores entrega una base conceptual respecto a lo que se debería considerar al momento de establecer actividades de comunicación con los stakeholders con el objetivo de utilizar, por ejemplo, herramientas que promuevan una comunicación fluida eliminado espacios de ambigüedad y resistencia, favoreciendo el entendimiento entre ambas partes y la transmisión del conocimiento que no se entrega explícitamente (conocimiento tácito). Estos factores sirven como base inicial para investigar otros temas respecto a cómo capturar de manera simple y óptima el conocimiento tácito durante las entrevistas u otras instancias de reunión, la preparación o entrenamiento en el aspecto emocional y motivacional que debería desarrollar el especialista en requerimientos y que le permita tratar con los distintos caracteres que podrían manifestar los stakeholders. De este último párrafo se desprende que un especialista en requisitos debería poseer las aptitudes, adicionales a su disciplina, que sean necesarias para realizar actividades de educción relacionadas al factor humano.

Estas aptitudes deberían incluir:

·       Habilidades en la adquisición del conocimiento tácito relevante dentro del dominio del producto ya sea de manera cognitiva o apoyada por un artefacto concreto.

·       Habilidades propias de la interacción social mediante la comunicación verbal y escrita.

·       Grandes capacidades de negociación, priorización y toma de decisiones respecto a los stakeholders.

·       La generación de especificaciones simples, estructuradas, objetivas y sin ambigüedades.

·       Uso y manejo de herramientas que favorezcan la participación y motivación de los distintos involucrados en el proceso disminuyendo la resistencia de estos.

·       Describir y extender en todo momento la creación del software como un producto que entregará seguridad y confianza a los stakeholders en las tareas que realizan dentro de su área.

 

REFERENCIAS

Anwar, F., Razali, R., & Ahmad, K. (2011). Achieving effective communication during requirements elicitation - A conceptual framework. Communications in Computer and Information Science, 181, 600-610. https://doi.org/10.1007/978-3-642-22203-0_51        [ Links ]

Apshvalka, D., Donina, D., & Kirikova, M. (2009). Understanding the Problems of Requirements Elicitation Process: A Human Perspective. In W. Wojtkowski, G. Wojtkowski, M. Lang, K. Conboy, & C. Barry (Eds.), Information Systems Development (pp. 211-223). Boston, MA: Springer US. https://doi.org/10.1007/978-0-387-68772-8_17

Azadegan, A., Papamichail, K. N., & Sampaio, P. (2013). Applying collaborative process design to user requirements elicitation: A case study. Computers in Industry, 64(7), 798-812. https://doi.org/10.1016/j.compind.2013.05.001        [ Links ]

Bjarnason, E., Runeson, P., Borg, M., Unterkalmsteiner, M., Engström, E., Regnell, B., Feldt, R. (2014). Challenges and practices in aligning requirements with verification and validation: a case study of six companies. Empirical Software Engineering, 19(6), 1809-1855. https://doi.org/10.1007/s10664-013-9263-y        [ Links ]

Burnay, C. (2016). Are Stakeholders the Only Source of Information for Requirements Engineers? Toward a Taxonomy of Elicitation Information Sources. ACM Trans. Manage. Inf. Syst., 7(3), 8:1-8:29. https://doi.org/10.1145/2965085

Burnay, C., Jureta, I. J., & Faulkner, S. (2014a). An Exploratory Study of Topic Importance in Requirements Elicitation Interviews. In M. Jarke, J. Mylopoulos, C. Quix, C. Rolland, Y. Manolopoulos, H. Mouratidis, & J. Horkoff (Eds.), Lecture Notes in Computer Science: Vol. 8484. Advanced Information Systems Engineering (pp. 180-195). https://doi.org/10.1007/978-3-319-07881-6_13

Burnay, C., Jureta, I. J., & Faulkner, S. (2014b). What stakeholders will or will not say: A theoretical and empirical study of topic importance in Requirements Engineering elicitation interviews. Information Systems, 46, 61-81. https://doi.org/https://doi.org/10.1016/j.is.2014.05.006

Calefato, F., Damian, D., & Lanubile, F. (2012). Computer-mediated communication to support distributed requirements elicitations and negotiations tasks. Empirical Software Engineering, 17(6), 640-674. https://doi.org/10.1007/s10664-011-9179-3        [ Links ]

Carrizo, D., Dieste, O., & Juristo, N. (2014). Systematizing requirements elicitation technique selection. Information and Software Technology, 56(6), 644-669. https://doi.org/10.1016/j.infsof.2014.01.009        [ Links ]

Dey, S., & Lee, S.-W. (2017). REASSURE: Requirements elicitation for adaptive socio-technical systems using repertory grid. Information and Software Technology, 87, 160-179. https://doi.org/10.1016/j.infsof.2017.03.004        [ Links ]

Ferrari, A., Spoletini, P., & Gnesi, S. (2016). Ambiguity and tacit knowledge in requirements elicitation interviews. Requirements Engineering, 21(3), 333-355. https://doi.org/10.1007/s00766-016-0249-3        [ Links ]

Fuentes-Fernández, R., Gómez-Sanz, J. J., & Pavón, J. (2010). Understanding the human context in requirements elicitation. Requirements Engineering, 15(3), 267-283. https://doi.org/10.1007/s00766-009-0087-7        [ Links ]

Gervasi, V., Gacitua, R., Rouncefield, M., Sawyer, P., Kof, L., Ma, L., … Nuseibeh, B. (2013). Unpacking Tacit Knowledge for Requirements Engineering. In W. Maalej & A. Thurimella (Eds.), Managing Requirements Knowledge (pp. 23-47). Berlin, Heidelberg: Springer Berlin Heidelberg. https://doi.org/10.1007/978-3-642-34419-0_2        [ Links ]

Hadar, I., Soffer, P., & Kenzi, K. (2014). The role of domain knowledge in requirements elicitation via interviews: an exploratory study. Requirements Engineering, 19(2), 143-159. https://doi.org/10.1007/s00766-012-0163-2        [ Links ]

Harbers, M., Detweiler, C., & Neerincx, M. A. (2015). Embedding Stakeholder Values in the Requirements Engineering Process. In S. Fricker & K. Schneider (Eds.), Lecture Notes in Computer Science: Vol. 9013. Requirements Engineering: Foundation for Software Quality (pp. 318-332). https://doi.org/10.1007/978-3-319-16101-3_23        [ Links ]

Hastie, S., & Wojewoda, S. (2015). Standish Group 2015 Chaos Report - Q&A with Jennifer Lynch. Retrieved from https://www.infoq.com/articles/standish-chaos-2015        [ Links ]

Katina, P. F., Keating, C. B., & Jaradat, R. M. (2014). System requirements engineering in complex situations. Requirements Engineering, 19(1), 45-62. https://doi.org/10.1007/s00766-012-0157-0        [ Links ]

Kitchenham, B. (2004). Procedures for performing systematic reviews. (Report TR/SE-0401). Keele, UK: Keele University.         [ Links ]

Kumari, S. N., & Anitha, S. P. (2016). An Extended Study on the Association Between Elicitation Issues and Software Project Performance: A Theoretical Model. In V. Snášel, A. Abraham, P. Krömer, M. Pant, & A. Muda (Eds.), Innovations in Bio-Inspired Computing and Applications: Vol. 424. Advances in Intelligent Systems and Computing (pp. 523-533). https://doi.org/10.1007/978-3-319-28031-8_46        [ Links ]

Liebel, G., Tichy, M., Knauss, E., Ljungkrantz, O., & Stieglbauer, G. (2016). Organisation and communication problems in automotive requirements engineering. Requirements Engineering. https://doi.org/10.1007/s00766-016-0261-7        [ Links ]

Lopes, M. E. R. F., & Forster, C. H. Q. (2013). Application of human error theories for the process improvement of Requirements Engineering. Information Sciences, 250, 142-161. https://doi.org/10.1016/j.ins.2013.07.010        [ Links ]

McLeod, L., & MacDonell, S. G. (2011). Factors that affect software systems development project outcomes. ACM Computing Surveys, 43(4), 1-56. https://doi.org/10.1145/1978802.1978803        [ Links ]

Okewu, E. (2015). Requirements Engineering in an Emerging Market. In O. Gervasi, B. Murgante, S. Misra, M. L. Gavrilova, A. M. A. C. Rocha, C. Torre, … B. O. Apduhan (Eds.), Lecture Notes in Computer Science: Vol. 9158 Computational Science and Its Applications - ICCSA 2015 (pp. 476-491). https://doi.org/10.1007/978-3-319-21410-8_37        [ Links ]

Pa, N. C., & Zin, A. M. (2011). Managing Communications Challenges in Requirement Elicitation. In J. M. Zain, W. M. bt Wan Mohd, & E. El-Qawasmeh (Eds.), Software Engineering and Computer Systems (pp. 803-811). Berlin, Heidelberg: Springer Berlin Heidelberg. https://doi.org/10.1007/978-3-642-22203-0_67

Ramachandran, S., Dodda, S., & Santapoor, L. (2011). Overcoming Social Issues in Requirements Engineering. In N. Meghanathan, B. K. Kaushik, & D. Nagamalai (Eds.), Advanced Computing (pp. 310-324). Berlin, Heidelberg: Springer Berlin Heidelberg. https://doi.org/10.1007/978-3-642-17881-8_30        [ Links ]

Sethia, N. K., & Pillai, A. S. (2014). The Effects of Requirements Elicitation Issues on Software Project Performance: An Empirical Analysis. In C. Salinesi & I. van de Weerd (Eds.), Lecture Notes in Computer Science: Vol. 8396. Requirements Engineering: Foundation for Software Quality. REFSQ 2014 (pp. 285-300). https://doi.org/10.1007/978-3-319-05843-6_21        [ Links ]

Shuhud, M. I. M., Richter, A., & Ahmad, A. (2013). Supporting Requirements Elicitation Practices. In P. Antunes, M. A. Gerosa, A. Sylvester, J. Vassileva, & G.-J. de Vreede (Eds.), Lecture Notes in Computer Science Vol. 8224. Collaboration and Technology. CRIWG 2013 (pp. 306-321). https://doi.org/10.1007/978-3-642-41347-6_22        [ Links ]

Würfel, D., Lutz, R., & Diehl, S. (2016). Grounded requirements engineering: An approach to use case driven requirements engineering. Journal of Systems and Software, 117, 645-657. https://doi.org/10.1016/j.jss.2015.10.024        [ Links ]

 

Recebido/Submission: 20/06/2016

Aceitação/Acceptance: 01/09/2016

Creative Commons License Todo o conteúdo deste periódico, exceto onde está identificado, está licenciado sob uma Licença Creative Commons