See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/275581104

La Ingenieria de Requisitos de Software Direccionada al Negocio

Research · April 2015

DOI: 10.13140/RG.2.1.3314.3201

CITATIONS READS

0 2,720

3 authors:

Roberto Avila Paldês Angelica Calazans

Centro Universitário de Brasília Centro Universitário de Brasília
38 PUBLICATIONS   69 CITATIONS    66 PUBLICATIONS   147 CITATIONS   

SEE PROFILE SEE PROFILE

Ari Melo Mariano

University of Brasília
277 PUBLICATIONS   382 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Measurement model View project

Teoria do Enfoque Metaanalítico Consolidado View project

All content following this page was uploaded by Roberto Avila Paldês on 28 April 2015.

The user has requested enhancement of the downloaded file.

 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 sis-
tema 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 homo-
logadas. La investigación contribuye para mostrar cómo efectivamente integrar
las necesidades del negocio con los esfuerzos para la implementación de una so-
lució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 pri-
vadas y públicas despertaron para la necesidad de comprenderse, modelar y perfeccio-
nar 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 sis-
temas de información a la estrategia de negocios, procesos de negocios, la infra-estruc-
tura 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 mayo-
rí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 informa-
ción ha sido bastante discutido y valorizado [2] haciendo crecer el interés por experien-
cias prácticas bien fundamentadas. El desafío ha sido de integrar los modelos organi-
zacionales 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 Orien-
tados a Negocio [4]. Este tuvo como punto de partida una revisión crítica de la biblio-
grafí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 modu-
lació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-gra-
duació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 esfuer-
zos académicos con las particularidades de las empresas de desarrollo de software, evi-
tando 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 atendi-
miento 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 pro-
ducción y gerenciamiento de los requisitos del sistema?
El objetivo general del trabajo es analizar un proceso de producción y gerencia-
miento de requisitos de software con el propósito de identificar y evaluar las experien-
cias 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 ob-
jetivos 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 ras-
treabilidad 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. Final-
mente, 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-hos-
pitalario. 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 Inten-
siva) 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 opor-
tunidad 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 desarrolla-
dores 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 opera-
ción y un programador.

Metodología de la investigación
El tipo de investigación o estudio adoptado es el exploratorio. Este permite una ma-
yor familiaridad con el problema para mejor entenderlo, involucrando un censo y en-
trevistas 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, des-
cripció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 respon-
sables por la implantación, producción y manutención del sistema de control de fárma-
cos.
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 sis-
temá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 es-
pecí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 so-
porte 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 ayu-
dan 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 estra-
té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 Ges-
tión de Procesos de Negocio.
El estudio de [1] presenta un abordaje que utiliza una especificación del modelo me-
tas, construido por heurísticas basadas en modelos de proceso en la forma de una nota-
ció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-fun-
cionales.
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 con-
ceptos 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 madu-
reció 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 alinea-
miento de los requisitos del software con la visión de negocio [2]. Presenta una siste-
matizació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 Ne-
gocio (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 arte-
facto denominado de Documento de Definición de Requisitos (DDR) con la identifica-
ció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, conside-
rando 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 rea-
lizació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 minu-
tos 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 per-
cepciones 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 pro-
ducció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 rela-
ció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 cuestiona-
miento.
Fueron, entonces, realizadas entrevistas focalizadas con los dos analistas que parti-
ciparon 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 observa-
ción sistémica y en la entrevista focalizada.

Table 2. Percepciones sobre el método iRON

Aspecto Observación Sistemática Entrevista

Aprendizaje Carece de orientación en los pri- Fácil por integrar conocimientos
meros proyectos de diferentes áreas
Utilización No completamente adherente al Adherente a las mejores prácticas
método, pero manteniendo sus del mercado, aprovecha conoci-
principios mientos consagrados
Importancia Mayor estructura del desarrollo Parte del entendimiento del nego-
del raciocinio; retiró el foco en la cio para la práctica. Le da visibili-
solución, direccionando para el dad del proyecto del software al
problema gestor del área de negocio
Dificultades y Necesaria una disciplina para ge- Una documentación extensa no es
riesgos nerar y mantener una documenta- valorizada ni por los técnicos, ni
ción precisa por los propios clientes. Es traba-
joso mantener las matrices de ras-
treabilidad.
Impactos en la Beneficios no son percibidos en el Útil en la identificación del im-
rastreabilidad desarrollo, apenas en la produc- pacto de cambios. Difícil sin el au-
ción del software xilio 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 sufi-
cientes, 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 co-
rrecta 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 me-
dida 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 documen-
tació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 encon-
trada 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 funcionali-
dades 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 con-
siderable 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 visua-
lización de las dependencias y que genera automáticamente las matrices de rastreabili-
dad.

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 sis-
temas 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 pro-
yecto.
“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 man-
tenedores 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 eta-
pas 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 ana-
lista 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 referen-
cia 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 ex-
cesivamente 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 expe-
riencia positiva en la empresa en la medida que permitió la integración entre las nece-
sidades 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 entendi-
miento del método fue simple, pues dispensa el lenguaje técnico y explora la experien-
cia del usuario en la ejecución de sus tareas diarias, de acuerdo con las reglas del nego-
cio. El método fue considerado útil pues convirtió la producción de resultados más ad-
herentes 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 evalua-
ción de la experiencia de la aplicación del método en un sistema crítico en una organi-
zació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 inme-
diato. 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 funcionali-
dades 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. Me-
dellí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 Re-
quirements 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/tecnolo-
gí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 Ingenie-
ría de Requisitos en Manutención de Software. In: VII Workshop on Require-ments Engi-
neering. Tandil, Argentina (2004)
21. Anquetil, N, Oliveira, K.: Proceso de Redocumentación: una necesidad. In: I Simposio Bra-
sileñ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 Ja-
neiro (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)

View publication stats