La Ingeniería de Requisitos de Software Direccionada al Negocio: la Aplicación de un Método en una Empresa de Atención Médico de Emergencia Roberto Ávila Paldes1, Angélica Toffano Seidel Calazans1, Ari Melo Mariano1 1Centro Universitario de Brasilia – UniCEUB, Brasilia, Brasil {roberto.paldes, angelica.calazans, ari.mariano} @uniceub.br

Abstract. El objetivo general del trabajo fue de evaluar las experiencias en la aplicación de un método de ingeniería de requisitos direccionada al negocio bajo el punto de vista del equipo de desarrollo de software. La investigación fue exploratoria y cualitativa, con un estudio de caso linear e iterativo de un proyecto de un sistema de información para mejorar el control de los fármacos utilizados en una empresa de atención médico de emergencia médica. Los resultados señalan que el uso del método se unió al marco teórico y a las buenas prácticas de mercado, convirtió la producción de resultados más adherentes a las necesidades de los clientes y evitó el re-trabajo en la re-elaboración de implementaciones no homologadas. La investigación contribuye para mostrar cómo efectivamente integrar las necesidades del negocio con los esfuerzos para la implementación de una solución de automatización de procesos. Keywords: Ingeniería de requisitos, método y herramienta, metas de negocio, alineamiento con negocio, documentación de requisitos.

1

Introducción

Un software realiza la automoción de los procesos del negocio. Así, las empresas privadas y públicas despertaron para la necesidad de comprenderse, modelar y perfeccionar los procesos organizacionales como exigencia básica para la comprensión de las necesidades que serán atendidas por los sistemas de información. Las necesidades de las empresas pueden ser descritas por el alineamiento de los sistemas de información a la estrategia de negocios, procesos de negocios, la infra-estructura y a los objetivos organizacionales [1]. Aunque reconociendo que la Ingeniería de requisitos es el enlace que conecta la organización al sistema de información, la mayoría de las investigaciones en Ingeniería de requisitos desconsidera los problemas del mundo organizacional. De esta manera, el abordaje de procesos de negocio versus los sistemas de información ha sido bastante discutido y valorizado [2] haciendo crecer el interés por experiencias prácticas bien fundamentadas. El desafío ha sido de integrar los modelos organizacionales a las demás etapas del proceso de ingeniería de requisitos [3]. adfa, p. 1, 2011. © Springer-Verlag Berlin Heidelberg 2011

Un método que adopta ese abordaje es el iRON – integración de Requisitos Orientados a Negocio [4]. Este tuvo como punto de partida una revisión crítica de la bibliografía sobre todo el ciclo de la ingeniería de requisitos de un software, con base en el modelaje de los procesos de negocio que serán automatizados. El método propone la rastreabilidad bidireccional desde la producción a la gerencia de los requisitos, pues “un proceso de desarrollo de software integrado que permita la rastreabilidad y modulación es de importancia vital para la manutención y evolución del producto” [5]. El método ha sido llevado al ambiente empresarial por alumnos de graduación y pos-graduación que regresan con críticas para su perfeccionamiento. Los resultados alcanzados en la forma de un método y de una herramienta [6], contribuyen para alinear los esfuerzos académicos con las particularidades de las empresas de desarrollo de software, evitando tratar el tema únicamente de forma académica o, de forma aislada, apenas con la visión del mercado [3]. Para evaluar los resultados de la aplicación del iRON, es evaluada en el presente trabajo la aplicación del método en una empresa de prestación de servicios de atendimiento a emergencias médicas. Se dio por lo tanto, el inicio al estudio para responder el siguiente problema: ¿cuál es la percepción del equipo de desarrollo en la utilización de un método de ingeniería de requisitos orientados a negocios en el proceso de producción y gerenciamiento de los requisitos del sistema? El objetivo general del trabajo es analizar un proceso de producción y gerenciamiento de requisitos de software con el propósito de identificar y evaluar las experiencias en la aplicación del método, bajo el punto de vista de los equipos de desarrollo en el contexto de la empresa considerada. Para tal, fueron establecidos los siguientes objetivos específicos: entender las percepciones con relación a su aprendizaje, utilización e importancia en la aplicación del método; colectar y evaluar las dificultades y riesgos involucrados en la aplicación del método, y; evaluar los impactos de la matriz de rastreabilidad bidireccional propuesta por el método. El resto del artículo es organizado de la siguiente manera: la Sección 1 presenta la propuesta del trabajo, el ambiente de desarrollo estudiado y la metodología adoptada en el estudio. La Sección 2 realiza la revisión conceptual del abordaje de requisitos orientados al negocio, del método iRON, incluyendo sus propuestas y expectativas. La Sección 3 realiza la presentación y la evaluación de los resultados obtenidos. Finalmente, la Sección 4 señala algunas conclusiones e indica trabajos futuros. El ambiente estudiado La empresa considerada en el presente estudio necesitaba perfeccionar el control de los fármacos utilizados en atendimientos pre-hospitalarios de urgencia y emergencia médica. Esta empresa está sedeada en Brasil hace más de 20 años, antes aún de haber legislación oficial que adecuadamente organizara y legalizara el atendimiento pre-hospitalario. Hoy cuenta con más de 900 mil filiados, contando con un cuerpo clínico de aproximadamente 300 médicos de emergencia y 60 CTI’s (Centros de Terapia Intensiva) móviles [7].

Para tanto, se inició el desarrollo de un sistema informatizado [8] para controlar el consumo de productos de salud empleado en los atendimientos, identificando con oportunidad los productos con necesidad de reposición y apoyando las adquisiciones con base en los mejores precios y en los plazos de caducidad previstos para el consumo. En la producción y en la gerencia de los requisitos del nuevo sistema, los desarrolladores utilizaron el abordaje orientado a negocios [4]. El sistema entró en producción en enero de 2013 y las consecuencias de la aplicación del método ya pueden ser evaluadas. Los analistas que participaron del proyecto, están a más de 15 años en desarrollo de sistemas informatizados. Uno de los analistas mantiene el sistema en producción hasta la presente fecha, contando para tanto apenas con dos auxiliares: un auxiliar de operación y un programador. Metodología de la investigación El tipo de investigación o estudio adoptado es el exploratorio. Este permite una mayor familiaridad con el problema para mejor entenderlo, involucrando un censo y entrevistas con personas que tuvieron experiencias prácticas con el problema investigado, además del análisis de ejemplos que mejor estimulen la comprensión del fenómeno [9]. El delineamiento de la investigación es cualitativo, valiéndose de un estudio del caso, donde el ambiente de desarrollo del software es la fuente natural para la colecta, descripción y análisis de los datos obtenidos. El universo considerado en la investigación es el departamento de tecnología de la información de la matriz de la empresa de atendimiento pre-hospitalario de emergencia. La muestra está compuesta por los analistas de los sistemas y por los técnicos responsables por la implantación, producción y manutención del sistema de control de fármacos. La estructura adoptada para el estudio del caso es linear e interactiva que se inicia con un plan de estudio, siguiéndose las etapas de plan, proyecto, preparación, colecta, análisis y compartimiento [10]. En la colecta de datos es empleada la observación sistemática, entrevista focalizada [11] y el análisis documental sobre informaciones del proceso actual. Son observados el uso de múltiples fuentes de evidencia, creando una base de datos del estudio de caso y manteniendo el encadenamiento de las evidencias. El contenido es analizado a partir de los registros de las entrevistas con los participantes del proceso. Este encadenamiento genera un informe que comparte los resultados con base en el banco de datos del estudio del caso y en las cuestiones de estudio, valiéndose del protocolo del estudio del caso y de las citaciones a las fuentes comprobatorias específicas [10].

2

Fundamentación teórica

2.1

Requisitos orientados al negocio

Las organizaciones se encuentran insatisfechas con la cualidad de sus sistemas [12]. Los problemas más comunes son: “la incapacidad de estos sistemas de ofrecer un soporte eficiente y efectivo a las operaciones del negocio, la dificultad de manutención

de los sistemas, la deficiencia en la integración con los otros sistemas de la organización y la falta de confianza de las personas de la organización en estos sistemas” [12]. Buscando resolver estos problemas, el modelaje de los procesos de negocio puede ser considerado una herramienta importante de la ingeniería de requisitos [2] una vez que los sistemas de información dan soporte a los procesos de negocio. Diferentemente de los abordajes tradicionales, los modelos detallados de los procesos de negocio ayudan la ingeniería de requisitos a perfeccionar el funcionamiento de la organización. Entre los beneficios percibidos con la utilización de modelos organizacionales en el proceso de ingeniería de requisitos están: lo mejor del entendimiento del ambiente organizacional que el sistema apoya; la posibilidad de atendimiento de las metas estratégicas de la organización; y, la mejor comprensión de los flujos de negocio y de las relaciones existentes entre los actores de la organización [3]. Se encuentran varias propuestas y estudios abarcando el tema modelaje de proceso de negocios e Ingeniería de Requisitos. [12] presenta un abordaje para el mapeo de procesos en casos de uso y para el mapeo de términos en clases de dominio. Esta técnica es acompañada de una herramienta que implementa este mapeo. Ya [13] presentan un abordaje donde el proceso de ingeniería de requisitos es visto bajo la Óptica de la Gestión de Procesos de Negocio. El estudio de [1] presenta un abordaje que utiliza una especificación del modelo metas, construido por heurísticas basadas en modelos de proceso en la forma de una notación para modelaje de procesos de negocio (BPMN). A partir del modelo de metas, y por medio de un proceso de refino y etiquetaje son obtenidos los requisitos del modelo en la forma de casos de uso. El estudio de [14] propone la extensión de la BPMN, que es de fácil comprensión por los stakeholders, insiriendo la noción de requisitos no-funcionales. Según [15], es posible observar un aumento de las publicaciones en el Workshop en Ingeniería de Requisitos [16] en los últimos años de la década de algunos temas, entre ellos, el tema del modelaje de negocios. Eso demuestra el crecimiento de interés de ese aspecto con relación a la Ingeniería de requisitos. A seguir presentamos algunos conceptos del método iRON [17] utilizado para el estudio. 2.2

El método iRON

El método ha sido utilizado hace más de seis años como referencia para la enseñanza de la ingeniería de requisitos en un curso de graduación de tecnología en análisis y desarrollo de sistemas. Los alumnos llevaron el abordaje para el ambiente profesional, siendo los resultados debatidos con la comunidad académica [17]. Este proceso madureció el método y embasó el lanzamiento en 2010 de un curso de pos-graduación en Ingeniería de Requisitos de Software [18]. El iRON está estructurado con el alineamiento de los requisitos del software con la visión de negocio [2]. Presenta una sistematización de todo el ciclo de la ingeniería de requisitos, de la producción hasta la gerencia, conforme la Figura 1. Propone artefactos para la documentación detallada de todas las etapas, pudiendo ser costeado de acuerdo con las características del proyecto y de la empresa que será atendida.

Fig. 1. Visión general del abordaje orientado a negocios del método (Fuente: Autores)

Tenemos así, como punto de partida la elaboración del Documento de Análisis de Negocio (DAN), donde es realizado el análisis institucional y donde son mapeados los procesos organizacionales. Este análisis tiene el foco en la identificación del problema del cliente, pues él otorga la elaboración de objetivos para la solución [19]. De pose de las metas, se identifican las funcionalidades necesarias para alcanzar cada objetivo específico. Un ejemplo considerando los datos tratados por la organización foco del estudio es presentado en la Tabla 1. Table 1. Análisis del negocio.

(Adaptado de Pereira y Campos, 2012)

Habiendo comprendido las necesidades del negocio (Figura 2), se pasa para el artefacto denominado de Documento de Definición de Requisitos (DDR) con la identificación de los requisitos de cada una de las funcionalidades: requisitos funcionales, no funcionales, requisitos de datos (atributos) y las reglas para su ejecución. El modelaje orientado a objetos representa con casos de uso las funcionalidades listadas, considerando sus características. El modelaje de los datos se basa en los requisitos de datos, que por su vez apoyan las métricas y estimativas. Así, el encadenamiento lógico, de la producción a la gerencia de los requisitos, adoptado por el método iRON apoya la realización de una rastreabilidad bidireccional.

Fig. 2. La colaboración en la producción de requisitos de software (Fuente: Autores)

3

Resultados obtenidos

Con la realización del estudio del caso fueron identificados los resultados prácticos de la aplicación del método en una organización del mundo real. La observación sistemática ocurrió en dos períodos: el primero, en los dos meses iniciales del desarrollo del proyecto, marzo y abril de 2012. Fueron utilizados 30 minutos semanales en esta etapa, con un total de cuatro horas en este ejercicio. Con base en los objetivos generales y específicos, fueron definidas las siguientes categorías de percepciones que deben ser evaluadas: con relación al aprendizaje del método; con relación a la utilización del método; con relación a la importancia del método; con relación a las dificultades y riesgos involucrados en la aplicación del método y de los impactos matriz de rastreabilidad bidireccional propuesta por el método. El segundo período de observación sistemática se dio después de la entrada en producción del sistema, realizada después de los dos primeros años de uso del sistema. Las observaciones se dieron en los meses de septiembre y octubre de 2014, con aproxima-

damente ocho horas de acompañamiento. Se buscó evaluar las percepciones con relación: a los riesgos involucrados en la aplicación del método, al aprendizaje del método, la utilización del método y al impacto de la matriz de rastreabilidad bidireccional de los requisitos inicialmente citados. Por medio de la observación sistemática, fueron identificados los diferentes tipos de reacciones de las personas a los hechos: positivas, negativas, tentativas e/o cuestionamiento. Fueron, entonces, realizadas entrevistas focalizadas con los dos analistas que participaron del desarrollo del proyecto, siendo que uno de ellos continúa como jefe del sector de producción del sistema. La Tabla 2 presenta el comparativo entre las percepciones obtenidas en la observación sistémica y en la entrevista focalizada. Table 2. Percepciones sobre el método iRON Aspecto Aprendizaje Utilización

Importancia

Dificultades y riesgos

Impactos en la rastreabilidad

Observación Sistemática Carece de orientación en los primeros proyectos No completamente adherente al método, pero manteniendo sus principios Mayor estructura del desarrollo del raciocinio; retiró el foco en la solución, direccionando para el problema Necesaria una disciplina para generar y mantener una documentación precisa

Beneficios no son percibidos en el desarrollo, apenas en la producción del software

Entrevista Fácil por integrar conocimientos de diferentes áreas Adherente a las mejores prácticas del mercado, aprovecha conocimientos consagrados Parte del entendimiento del negocio para la práctica. Le da visibilidad del proyecto del software al gestor del área de negocio Una documentación extensa no es valorizada ni por los técnicos, ni por los propios clientes. Es trabajoso mantener las matrices de rastreabilidad. Útil en la identificación del impacto de cambios. Difícil sin el auxilio de una herramienta (Fuente: Autores)

Además de eso, fueron obtenidas las siguientes percepciones: 3.1

Con relación al aprendizaje del método

Fue percibido que los recursos necesarios para aprender sobre el método [3] son suficientes, generando el entendimiento conceptual sobre el método. La aplicación práctica, mientras tanto, carece de la orientación de un profesional con mayor experiencia del método. Como el iRON cubre toda la Ingeniería de Requisitos, existe una dificultad natural en aplicar la integración de todas las etapas.

“Creo que el enfoque orientado al negocio consigue colocar varios conocimientos técnicos sobre el mismo foco, direccionándolos a las necesidades del cliente” 3.2

Con relación a la utilización del método

Es natural que el aprendizaje sobre el proceso influencie la utilización efectiva y correcta de este, pues el reconocimiento de aspectos positivos facilita la utilización de un método. Los analistas del proyecto relataron que no hubo re-trabajo o pérdida de tiempo en el desarrollo del sistema, pues había una documentación consistente de los requisitos del software que sería construido. Además de eso, consideran el método útil en la medida que él facilita la integración con las buenas prácticas del mercado. “Personas laicas van a pensar que todo es creación del método, cuando en la realidad él es la incorporación de mejores prácticas” El método adoptado facilitó el modelaje de los datos empleados, ya que la documentación de los requisitos identificó los atributos y las reglas de negocio necesarios. El estudio y la producción de los requisitos produjeron un modelo conceptual ya validado por el usuario final. 3.3

Con relación a la importancia de la aplicación del método

Los documentos producidos fueron validados prontamente por los usuarios, una vez que ellos correspondían exactamente a sus expectativas con relación al software. Hubo una percepción de los usuarios y del equipo de desarrollo que la aplicación agregaba un valor al negocio, pues se tenía una visión clara de la necesidad a atender antes de ser iniciada cualquier implementación. “Algunas veces, los analistas de sistema resuelven un problema y la solución encontrada acaba generando muchos otros problemas.” Las constataciones sobre la importancia de la documentación refuerzan la visión de que esa es una actividad crítica de la ingeniería de requisitos, sea en el desarrollo, sea en la manutención del software. Eso ratifica el entendimiento de autores que citan que una documentación adecuada comunica de forma objetiva y consistente las funcionalidades del sistema que deberá ser implementado. Es necesario para garantizar que el proyecto sea correctamente dimensionado y que las dependencias entre los requisitos queden claramente contextualizadas [20]. 3.4

Con relación a las dificultades y riesgos en la aplicación del método

La generación de la documentación exigida por el método se constituye en desafío considerable para un equipo pequeño y con múltiples tareas. Las matrices de rastreabilidad fueron útiles e identificadas por los técnicos como muy importantes para la evaluación de los impactos de los cambios en el ciclo de vida del producto. La generación y la manutención de estas matrices, sin embargo, fue particularmente onerosa. “A pesar de la importancia, yo no adoptaría una matriz de rastreabilidad sin una herramienta específica. Felizmente existen buenas opciones en el mercado”.

Hoy, para dar soporte a los procesos de producción y de gerencia de requisitos ya fue desarrollada una herramienta de software aliada al método [6] que permite la visualización de las dependencias y que genera automáticamente las matrices de rastreabilidad. 3.5

Con relación a los impactos de la matriz de rastreabilidad bidireccional

La manutención del software fue considerablemente más simples y ágil que otros sistemas en producción en la empresa, con base en la identificación necesita de requisito a atender y en la rastreabilidad obtenida por el proceso. Con el pasar del tiempo, sin embargo, la actualización de la documentación fue perdiendo prioridad y hoy existe una considerable diferencia entre el sistema en producción y la documentación del proyecto. “Damos importancia a la manutención actualizada de la documentación de módulos críticos de los sistemas. En aplicaciones de pequeño impacto, la manutención se limita a ajustes directamente en el código.” Este resultado confirma una realidad tan indeseable cuanto antigua, donde los mantenedores de software todavía prefieren alterar directamente el código, priorizando las actividades de codificación en detrimento de la manutención de la documentación [21]. La rastreabilidad de los requisitos y la evaluación de los impactos de cambios también fueron percibidos como beneficios de la utilización del método en la empresa. Existen herramientas en el mercado que generan matrices de rastreabilidad, pero los programas anteriormente utilizados por la empresa tenían como punto de partida el diseño de los casos de uso. De hecho, se constata el modelo de caso de usos que han recibido destaque en la captura de los requisitos del sistema al modelar el comportamiento y la interacción entre él y sus actores [22]. El método iRON se alinea, mientras tanto, con la representación más precisa de los procesos de negocio, lo que no es bien representado por casos de uso, pues son más adecuados para dominios cerrados [23]. El modelo de casos de uso es utilizado en etapas más avanzadas de la producción de requisitos, para representar el atendimiento de los requisitos del negocio en la perspectiva del usuario [24]. 3.6

Otras percepciones obtenidas:

Aún así, la Dirección de la empresa se interesó por la documentación producida, en la medida que esta convierte el sistema independiente del equipo que lo produjo. El analista responsable por el sistema recibió una demanda de los directores de la empresa para adoptar el padrón de documentación detallada de los requisitos como una referencia para todos los sistemas existentes. Muchos de esos sistemas tienen la manutención realizada directamente en el código, lo que hace las actualizaciones o correcciones excesivamente lentas. Nuevos sistemas están siendo desarrollados en la empresa investigada utilizándose métodos ágiles. Aunque con una menor prioridad para la documentación, el equipo técnico mantiene la elaboración del Documento de Análisis del Negocio propuesto en el iRON para la mejor comprensión de los procesos de negocio actuales y futuros.

4

Conclusión

El estudio de caso desarrollado señala que la utilización del método fue una experiencia positiva en la empresa en la medida que permitió la integración entre las necesidades del negocio con los esfuerzos para la implementación de la solución. Como respuesta al asunto de investigación formulado, se identificó que el entendimiento del método fue simple, pues dispensa el lenguaje técnico y explora la experiencia del usuario en la ejecución de sus tareas diarias, de acuerdo con las reglas del negocio. El método fue considerado útil pues convirtió la producción de resultados más adherentes a las necesidades de los clientes, evitando el re-trabajo en la re-elaboración de implementaciones no homologadas. La importancia identificada está relacionada con la producción de artefactos relacionados lógicamente, lo que permite una rastreabilidad bidireccional de los requisitos producidos en la ingeniería de los requisitos de software. Estos resultados señalan que el método orientado a negocio propuesto alcanzó una madurez que va más allá de una propuesta conceptual. La aplicación práctica del método es una realidad y atiende a una exigencia de que el software realmente automatice los procesos de negocio, correspondiendo con más eficiencia a las expectativas de sus usuarios. Los objetivos de la investigación fueron alcanzados, con la identificación y evaluación de la experiencia de la aplicación del método en un sistema crítico en una organización de alcance nacional. El estudio identificó la importancia de la producción de una documentación de requisitos consistente y adherente a los procesos de la empresa. Como principal dificultad, evidenció que manutención actualizada de la documentación producida es un desafío para pequeños grupos, muchas veces presionadas por realizar inmediatas actualizaciones directamente en el código para que este funcione de inmediato. Los riesgos de la falta de adherencia de la documentación de los requisitos con el código están en la dificultad en evaluar los impactos de la evolución del sistema, sea en la actualización de las funciones actuales, sea en la creación de nuevas funcionalidades en el sistema. La presión por inmediatismo puede generar un mayor esfuerzo del grupo en la manutención del software, además de convertir ese trabajo muy dependiente de los desarrolladores. La limitación de la investigación está relacionada con el abordaje del problema a partir de la percepción del equipo de desarrollo del sistema. Con la ampliación de la utilización del método por otras empresas, trabajos futuros podrán basarse en datos cuantitativos para rectificar o ratificar los resultados aquí alcanzados.

Referencias 1. De la Vara, J.L., Alcolea, D. A., Diaz, J.S.: Decomposición de árboles de metas a partir de modelos de procesos. Anais do WER07 - Workshop en Ingeniería de Requisitos, pp. 35 – 46, Toronto, Canadá (2007) 2. . De la Vara, J.L., Fortuna, M.H., Sánchez, J., Werner, C.M.L., Borges, M.R.S.: Modelado de Requisitos de Datos para Sistemas de Información basados en Procesos de Negocio. In: XII Conferencia Iberoamericana de Ingeniería de Requisitos y Ambientes de Software. Medellín, Colombia (2009)

3. Santander, V., Da Silva, I. F., Schemberger, E. E.: Integrando Mode-laje Organizacional al Proceso de Ingeniería de Requisitos. Rio de Janeiro: Requirements Engineering@Brazil, 16 jul. (2013) 4. Castro, Eduardo J. R.; Calazans, Angélica T.S.; Guimarães, Fernando de A.; Paldês, Roberto A. Ingeniería de Requisitos: un enfoque práctico en la construcción de software orientado al negocio. Florianópolis: Bookess. (2014). 5. Brito, I.: Crosscutting Quality Attributes for Requirements Engineering. SEKE - Software Engineering and Knowledge Engineering Conference. Ischia, Itália (2002) 6. Castro, E. J. R., Calazans, A. T.S., Paldês, R. A., Pontes, J. R., Neiva, G.: Integración de requisitos orientados al negocio: presentación de método y herramienta. Anais de las 43 JAIIO Jornadas Argentinas de Informática: Simposio Argentino de Ingeniería de Software. Universidad de Palermo: Buenos Aires, Argentina (2014) 7. UTIVIDA. Emergencias Médicas. http://www.utivida.com.br/. (2014). 8. Pereira, C. A.; Campos, R. C. SGFUM: Sistema Gerenciador de Fármacos en UTI Móvel. Proyecto de Conclusión de Curso (Graduación en Análisis y Desarrollo de Sistemas), Centro Universitário de Brasilia, Brasilia (2012) 9. Vergara, S. C.: Proyectos e informes de investigación en administración. Atlas. São Paulo (2005) 10. Yin R. K. Estudio de caso: planificación y métodos. Porto Alegre: Bookman (2010) 11. Gil, A. C. :Como elaborar proyectos de investigación. 4.ed. Atlas. São Paulo (2002) 12. Dias, F., Morgado,G., Oscar, P., Silveira, D., Juarez, A., Lima, P., Schmitz, E.: Un Abordaje para la Transformación Automática del Modelo de Negocio en Modelo de Requisitos Anais del WER06 - Workshop en Ingeniería de Requisitos, Julio 13-14, 2006, pp 51-60 Rio de Janeiro, RJ, Brasil (2006) 13. Cardoso, J.H.de M., Oliveira, A.A. de, Alencar, F.:O Proceso de Ingeniería de Requisitos bajo la Óptica de la Gestión de Procesos de Negocio Fernanda Alencar. Anais del WER12 Workshop en Ingeniería de Requisitos, April 24-27 pp, Buenos Aires, Argentina (2012) 14. Xavier, L., Alencar, F., Castro, J., Pimentel, J.: Integración de Requisitos No-Funcionales a Procesos de Negocio: Integrando BPMN e NFR. In: Proceedings of the 13th Workshop on Requirements Engineering (WER10), 12-13 pp. 29-40. Cuenca, Ecuador (2010) 15. Valaski, J., Stancke, W., Seinehr, S, Malucelli, Andreia.: Retrospective and Trends in Requirements Engineering through the WER.Anais do WER13 - Workshop en Ingeniería de Requisitos, April 8-10, Montevideo, Uruguay (2013) 16. WER. Workshop en Ingeniería de Requisitos. http://wer.inf.puc-rio.br/WERpapers/ (2014) 17. iRON. Innovación de Requisitos Orientado a Negocios. Anais XI Congreso de Enseñanza, Investigación y Extensión, 01-03 out. 2013. Centro Universitário de Brasilia, UniCEUB, p. 26. Brasilia (2013) 18. UNICEUB. Ingeniería de Requisitos de Software. http://www.uniceub.br/cursos/tecnología/pos-graduación/ingeniería-de-requisitos-de-software/sobre-el-curso.aspx. (2014). 19. Bolay, F. W.: Planificación de proyectos orientado por objetivos: Método ZOPP. Matilde J. de Freitas, Recife (1993) 20. Espíndola, R.; Majdenbaum, A.; Audy, J. :Un Análisis Crítico de los Desafíos para Ingeniería de Requisitos en Manutención de Software. In: VII Workshop on Require-ments Engineering. Tandil, Argentina (2004) 21. Anquetil, N, Oliveira, K.: Proceso de Redocumentación: una necesidad. In: I Simposio Brasileño de Cualidad de Software. Universidad Católica de Brasilia. Brasilia (2002). 22. Fortuna, M. H.: Info Cases: Un Modelo Integrado de Requisitos con Casos de Uso. Tesis (doctorado). Programa de Ingeniería de Sistemas y Computación. UFRJ/COPPE, Rio de Janeiro (2008).

23. Erikson, H.; Penker, M.: Business modeling with UML: business patterns at work.: John Wiley, New York (2000) 24. Azevedo J., Delmir P.; Campos, R. de.: Definición de requisitos de software basada en una arquitectura de modelaje de negocios. Prod., v. 18, n. 1. São Paulo (2008)