República Bolivariana de Venezuela

Instituto Universitario Politécnico

“Santiago Mariño”

INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS

Estudiante
Isidro González C.I. 25.547.661

Enero 2017
 Introducción

El diccionario de la Real Academia Española define requisito como una

“circunstancia o condición necesaria para algo.” Sin embargo, en el entorno de la
Ingeniería de Sistemas, esta circunstancia es una necesidad documentada sobre
el contenido o funcionalidad de algún servicio y generalmente se utilizan como dato
de entrada para la etapa del diseño.

Para Pythel, y otros (2011), “La especificación de requisitos del software es

una descripción completa del comportamiento del sistema software a desarrollar.
Incluye la descripción de todas las interacciones que se prevén que los usuarios
tendrán con el software.”.

Debido a los constantes avances en el desarrollo de sistemas, así como la

competitividad del mercado de cualquier industria en general, era necesario conocer
con gran detalle los fines o requerimientos específicos de un sistema para de esta
manera ser eficiente al momento de indicar los requisitos. Por esto, se empezó a
trabajar en Ingenierías que cubrieran las necesidades que este mercado
presentaba.

Este trabajo presenta un estudio comparativo entre la Ingeniería de

Requisitos y la Ingeniería de Requerimientos, así como las técnicas que son
aplicadas en los mismos. Para esto, se presenta una visión general de estas
ingenierías de manera Individual. Para finalizar, se presentan las conclusiones.
 Ingeniería de Requisitos

“En el proceso de desarrollo de un sistema, sea o no para la web, el equipo

de desarrollo se enfrenta al problema de la identificación de requisitos. La definición
de las necesidades del sistema es un proceso complejo, pues en él hay que
identificar los requisitos que el sistema debe cumplir para satisfacer las necesidades
de los usuarios finales y de los clientes.” (Koch & Escalona, 2002)

Ingeniería de Requisitos puede definirse como “El proceso sistemático de

desarrollar requisitos mediante un proceso iterativo y cooperativo de analizar el
problema, documentar las observaciones resultantes en varios formatos de
representación y comprobar la precisión del conocimiento obtenido”, así como
“Todas las actividades relacionadas con la identificación y documentación de las
necesidades de clientes y usuarios; creación de un documento que describe la
conducta externa y las restricciones asociadas de un sistema que satisfaga dichas
necesidades.” (como se cita en Durán, 2000).

Requerimientos

En el glosario de la IEEE existen distintas definiciones para lo que es un

requerimiento:

1. “Una condición o necesidad de un usuario para resolver un problema o

alcanzar un objetivo”. (Std 610.12-1900, IEEE: 62) 2.
2. “Una condición o capacidad que debe estar presente en un sistema o
componentes de sistema para satisfacer un contrato, estándar,
especificación u otro documento formal”. (Std 610.12-1900, IEEE: 62)

Los requerimientos se pueden considerar la pieza fundamental en un

proyecto de desarrollo de software, ya que “marcan el punto de partida para
actividades como la planeación, básicamente en lo que se refiere a las estimaciones
de tiempos y costos, así como la definición de recursos necesarios y la elaboración
de cronogramas que será uno de los principales mecanismos de control con los que
se contará durante la etapa de desarrollo.” (Chaves, 2006)

Características de los Requerimientos

Es importante no perder de vista que un requerimiento debe ser:

 Especificado por escrito: Como todo contrato o acuerdo entre dos partes.
 Posible de probar o verificar. Si un requerimiento no se puede comprobar,
entonces ¿cómo se sabe si se cumplió con él o no?
 Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su
redacción debe ser simple y clara para aquellos que vayan a consultarlo en
un futuro.
 Completo: Un requerimiento está completo si no necesita ampliar detalles
en su redacción, es decir, si se proporciona la información suficiente para su
comprensión.
 Consistente: Un requerimiento es consistente si no es contradictorio con
otro requerimiento.
 No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola
interpretación. El lenguaje usado en su definición, no debe causar
confusiones al lector.

Ingeniería de Requerimientos

“La Ingeniería de Requerimientos cumple un papel primordial en el proceso

de producción de software, ya que se enfoca un área fundamental: la definición de
lo que se desea producir. Su principal tarea consiste en la generación de
especificaciones correctas que describan con claridad, sin ambigüedades, en forma
consistente y compacta, las necesidades de los usuarios o clientes; de esta manera,
se pretende minimizar los problemas relacionados por la mala gestión de los
requerimientos en el desarrollo de sistemas.” (Chaves, 2006).
 Técnicas principales aplicadas en la Ingeniería de Requisitos

“La captura de requisitos es la actividad mediante la que el equipo de

desarrollo de un sistema de software extrae, de cualquier fuente de información
disponible, las necesidades que debe cubrir dicho sistema” (Díez, 2001). El proceso
de captura de requisitos puede resultar complejo, principalmente si el entorno de
trabajo es desconocido para el equipo de analistas, y depende mucho de las
personas que participen en él. Por la complejidad que todo esto puede implicar, la
ingeniería de requisitos ha trabajado desde hace años en desarrollar técnicas que
permitan hacer este proceso de una forma más eficiente y precisa.

A continuación se presentan un grupo de técnicas que de forma clásica han

sido utilizadas para esta actividad en el proceso de desarrollo de todo tipo de
software.

Captura de Requisitos

• Entrevistas: resultan una técnica muy aceptada dentro de la ingeniería de

requisitos y su uso está ampliamente extendido. Las entrevistas le permiten al
analista tomar conocimiento del problema y comprender los objetivos de la solución
buscada. A través de esta técnica el equipo de trabajo se acerca al problema de
una forma natural. Existen muchos tipos de entrevistas y son muchos los autores
que han trabajado en definir su estructura y dar guías para su correcta realización
(Durán, Bernáldez, Ruíz & Toro, 1999 y Pan, Zhu & Jonhson, 2001). Básicamente,
la estructura de la entrevista abarca tres pasos: identificación de los entrevistados,
preparación de la entrevista, realización de la entrevista y documentación de los
resultados (protocolo de la entrevista).

A pesar de que las entrevistas son esenciales en el proceso de la captura de

requisitos y con su aplicación el equipo de desarrollo puede obtener una amplia
visión del trabajo y las necesidades del usuario, es necesario destacar que no es
una técnica sencilla de aplicar (Pan, Zhu & Johnson, 2001). Requiere que el
entrevistador sea experimentado y tenga capacidad para elegir bien a los
entrevistados y obtener de ellos toda la información posible en un período de tiempo
siempre limitado.

• JAD (Joint Application Development/Desarrollo conjunto de

aplicaciones): esta técnica resulta una alternativa a las entrevistas. Es una práctica
de grupo que se desarrolla durante varios días y en la que participan analistas,
usuarios, administradores del sistema y clientes (IBM, 1997). Está basada en cuatro
principios fundamentales: dinámica de grupo, el uso de ayudas visuales para
mejorar la comunicación, mantener un proceso organizado y racional y una filosofía
de documentación WYSIWYG (What You See Is What You Get, lo que ve es lo que
obtiene), es decir, durante la aplicación de la técnica se trabajará sobre lo que se
generará. Tras una fase de preparación del JAD al caso concreto, el equipo de
trabajo se reúne en varias sesiones.

Esta técnica presenta una serie de ventajas frente a las entrevistas

tradicionales, ya que ahorra tiempo al evitar que las opiniones de los clientes se
tengan que contrastar por separado, pero requiere un grupo de participantes bien
integrados y organizados.

• Brainstorming (Tormenta de ideas): es también una técnica de reuniones

en grupo cuyo objetivo es que los participantes muestren sus ideas de forma libre
(Raghavan, Zelesnik & Ford, 1994). Consiste en la mera acumulación de ideas y/o
información sin evaluar las mismas. El grupo de personas que participa en estas
reuniones no debe ser muy numeroso (máximo 10 personas), una de ellas debe
asumir el rol de moderador de la sesión, pero sin carácter de controlador.

Como técnica de captura de requisitos es sencilla de usar y de aplicar,

contrariamente al JAD, puesto que no requiere tanto trabajo en grupo como éste.
Además suele ofrecer una visión general de las necesidades del sistema, pero
normalmente no sirve para obtener detalles concretos del mismo, por lo que suele
aplicarse en los primeros encuentros.
 • Concept Mapping: Los mapas conceptuales (Pan, Zhu & Johnson, 2001)
son grafos en los que los vértices representan conceptos y las aristas representan
posibles relaciones entre dichos conceptos. Estos grafos de relaciones se
desarrollan con el usuario y sirven para aclarar los conceptos relacionados con el
sistema a desarrollar. Son muy usados dentro de la ingeniería de requisitos, pues
son fáciles de entender por el usuario, más aún si el equipo de desarrollo hace el
esfuerzo de elaborarlo en el lenguaje de éste.

• Sketches y Storyboards: Está técnica es frecuentemente usada por los

diseñadores gráficos de aplicaciones en el entorno web. La misma consiste en
representar sobre papel en forma muy esquemática las diferentes interfaces al
usuario (sketches). Estos sketches pueden ser agrupados y unidos por enlaces
dando idea de la estructura de navegación (storyboard).

• Casos de Uso: Aunque inicialmente se desarrollaron como técnica para la

definición de requisitos (Jacobson, 1995), algunos autores proponen casos de uso
como técnica para la captura de requisitos (Pan, Zhu & Johnson, 2001 y Liu & Yu,
200). Los casos de uso permiten mostrar el contorno (actores) y el alcance 8
(requisitos funcionales expresados como casos de uso) de un sistema. Un caso de
uso describe la secuencia de interacciones que se producen entre el sistema y los
actores del mismo para realizar una determinada función. Los actores son
elementos externos (personas, otros sistemas, etc.) que interactúan con el sistema
como si de una caja negra se tratase. Un actor puede participar en varios casos de
uso y un caso de uso puede interactuar con varios actores.

La ventaja esencial de los casos de uso es que resultan muy fáciles de

entender para el usuario o cliente, sin embargo carecen de la precisión necesaria
(Vilain, Schwabe & Sieckenius, 2002 y Insfrán, Pastor & Wieringa, 2002) si no se
acompañan con una información textual o detallada con otra técnica como pueden
ser los diagramas de actividades (UML, 2001).

• Cuestionarios y Checklists: Esta técnica requiere que el analista conozca

el ámbito del problema en el que está trabajando. Consiste en redactar un
documento con preguntas cuyas respuestas sean cortas y concretas, o incluso
cerradas por unas cuantas opciones en el propio cuestionario (Checklist). Este
cuestionario será cumplimentado por el grupo de personas entrevistadas o
simplemente para recoger información en forma independiente de una entrevista.

• Comparación de terminología: Uno de los problemas que surge durante

la licitación de requisitos es que usuarios y expertos no llegan a entenderse debido
a problemas de terminología. Esta técnica es utilizada en forma complementaria a
otras técnicas para obtener consenso respecto de la terminología a ser usada en el
proyecto de desarrollo. Para ello es necesario identificar el uso de términos
diferentes para los mismos conceptos (correspondencia), misma terminología para
diferentes conceptos (conflictos) o cuando no hay concordancia exacta ni en el
vocabulario ni en los conceptos (contraste) (Pan, Zhu & Johnson, 2001).

Existen más técnicas para la captura de requisitos (análisis de otros sistemas,

estudio de la documentación, etc.), incluso también es común encontrar alternativas
que combinen varias de estas técnicas (Pan, Zhu & Johnson, 2001). Sin embargo,
las presentadas ofrecen un conjunto representativo de las más utilizadas y resultan
suficientes para el objetivo de este trabajo.

Definición de requisitos

También para la actividad de definición de requisitos en el proceso de

ingeniería de requisitos hay un gran número de técnicas propuestas. Describimos
brevemente las más relevantes para este trabajo.

• Lenguaje natural: Resulta una técnica muy ambigua para la definición de

los requisitos. Consiste en definir los requisitos en lenguaje natural sin usar reglas
para ello. A pesar de que son muchos los trabajos que critican su uso, es cierto que
a nivel práctico se sigue utilizando.

• Glosario y ontologías: La diversidad de personas que forman parte de un

proyecto software hace que sea necesario establecer un marco de terminología
común. Esta necesidad se vuelve más patente en los sistemas de información web
puesto que el equipo de desarrollo en ellas suele ser más interdisciplinario (Koch,
2001). Por esta razón son muchas las propuestas que abogan por desarrollar un
glosario de términos en el que se recogen y definen los conceptos más relevantes
y críticos para el sistema.

En esta línea se encuentra también el uso de ontologías, en las que no sólo

aparecen los términos, sino también las relaciones entre ellos.

• Plantillas o patrones: Esta técnica, recomendada por varios autores

(Durán, Bernáldez, Ruíz & Toro, 1999 y Escalona, Torres & Mejias, 2002), tiene por
objetivo el describir los requisitos mediante el lenguaje natural pero de una forma
estructurada. Una plantilla es una tabla con una serie de campos y una estructura
predefinida que el equipo de desarrollo va cumplimentando usando para ello el
lenguaje del usuario. Las plantillas eliminan parte de la ambigüedad del lenguaje
natural al estructurar la información; cuanto más estructurada sea ésta, menos
ambigüedad ofrece.

• Escenarios: La técnica de los escenarios consiste en describir las

características del sistema a desarrollar mediante una secuencia de pasos (Liu &
Yu, 2001). La representación del escenario puede variar dependiendo del autor.
Esta representación puede ser casi textual o ir encaminada hacia una
representación gráfica en forma de diagramas de flujo (Weidenhaupt, Pohl, Jarke &
Haumer, 1999). El análisis de los escenarios, hechos de una forma u otra, pueden
ofrecer información importante sobre las necesidades funcionales de sistema (Lowe
& Hall, 1999).

• Casos de uso: Como técnica de definición de requisitos es como más

ampliamente han sido aceptados los casos de uso. Actualmente se ha propuesto
como técnica básica del proceso RUP (Kruchten, 1998). Sin embargo, son varios
los autores que defienden que pueden resultar ambiguos a la hora de definir los
requisitos (Díez, 2001 y Vilain, Schwabe & Sieckenius, 2002 y Insfrán, Pastor &
Wieringa, 2002), por lo que hay propuestas que los acompañan de descripciones
basadas en plantillas o de diccionarios de datos que eliminen su ambigüedad.

• Lenguajes Formales: es la utilización de lenguajes formales para describir

los requisitos de un sistema. Las especificaciones algebraicas como ejemplo de
técnicas de descripción formal, han sido aplicadas en el mundo de la ingeniería de
requisitos desde hace años (Peña, 1998). Sin embargo, resultan muy complejas en
su utilización y para ser entendidas por el cliente. El mayor inconveniente es que no
favorecen la comunicación entre cliente y analista. Por el contrario, es la
representación menos ambigua de los requisitos y la que más se presta a técnicas
de verificación automatizadas.

Validación de Requisitos

Los requisitos una vez definidos necesitan ser validados. La validación de

requisitos tiene como misión demostrar que la definición de los requisitos define
realmente el sistema que el usuario necesita o el cliente desea (Lowe & Hall, 1999).
Es necesario asegurar que el análisis realizado y los resultados obtenidos de la
etapa de definición de 10 requisitos son correctos. Pocas son las propuestas
existentes que ofrecen técnicas para la realización de la validación y muchas de
ellas consisten en revisar los modelos obtenidos en la definición de requisitos con
el usuario para detectar errores o inconsistencias.

Aun así, existen algunas técnicas que pueden aplicarse para ello:

• Reviews o Walk-throughs: Está técnica consiste en la lectura y corrección

de la completa documentación o modelado de la definición de requisitos. Con ello
solamente se puede validar la correcta interpretación de la información transmitida.
Más difícil es verificar consistencia de la documentación o información faltante.

• Auditorías: La revisión de la documentación con esta técnica consiste en

un chequeo de los resultados contra una checklist predefinida o definida a
comienzos del proceso, es decir sólo una muestra es revisada.
 • Matrices de trazabilidad: Esta técnica consiste en marcar los objetivos del
sistema y chequearlos contra los requisitos del mismo (Durán, Bernáldez, Ruíz &
Toro, 1999). Es necesario ir viendo qué objetivos cubre cada requisito, de esta forma
se podrán detectar inconsistencias u objetivos no cubiertos.

• Prototipos: Algunas propuestas se basan en obtener de la definición de

requisitos prototipos que, sin tener la totalidad de la funcionalidad del sistema,
permitan al usuario hacerse una idea de la estructura de la interfaz del sistema con
el usuario (Olsina, 1999). Esta técnica tiene el problema de que el usuario debe
entender que lo que está viendo es un prototipo y no el sistema final.

Actividades de la Ingeniería de Requerimientos

En (Herrera, 2003: 6), se dice que dentro de la Ingeniería de Requerimientos

existen cuatro actividades básicas que se tienen que llevar a cabo para completar
el proceso. Estas actividades ayudan a reconocer la importancia que tiene para el
desarrollo de un proyecto de software realizar una especificación y administración
adecuada de los requerimientos de los clientes o usuarios. Las cuatro actividades
son: extracción, análisis, especificación y validación.

Extracción

Esta fase representa el comienzo de cada ciclo. Extracción es el nombre

comúnmente dado a las actividades involucradas en el descubrimiento de los
requerimientos del sistema. Aquí, los analistas de requerimientos deben trabajar
junto al cliente para descubrir el problema que el sistema debe resolver, los
diferentes servicios que el sistema debe prestar, las restricciones que se pueden
presentar, etc. Es importante, que la extracción sea efectiva, ya que la aceptación
del sistema dependerá de cuan bien éste satisfaga las necesidades del cliente.

Análisis

Sobre la base de la extracción realizada previamente, comienza esta fase en

la cual se enfoca en descubrir problemas con los requerimientos del sistema
identificados hasta el momento. Usualmente se hace un análisis luego de haber
producido un bosquejo inicial del documento de requerimientos; en esta etapa se
leen los requerimientos, se conceptúan, se investigan, se intercambian ideas con el
resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones, y
luego se van fijando reuniones con el cliente para discutir los requerimientos.

Especificación

En esta fase se documentan los requerimientos acordados con el cliente, en

un nivel apropiado de detalle. 6 En la práctica, esta etapa se va realizando
conjuntamente con el análisis, se puede decir que la especificación es el "pasar en
limpio" el análisis realizado previamente aplicando técnicas y/o estándares de
documentación, como la notación UML (Lenguaje de Modelado Unificado), que es
un estándar para el modelado orientado a objetos, por lo que los casos de uso y la
obtención de requerimientos basada en casos de uso se utiliza cada vez más para
la obtención de requerimientos.

Validación

La validación es la etapa final de la IR. Su objetivo es, ratificar los

requerimientos, es decir, verificar todos los requerimientos que aparecen en el
documento especificado para asegurarse que representan una descripción, por lo
menos, aceptable del sistema que se debe implementar. Esto implica verificar que
los requerimientos sean consistentes y que estén completos.

Dificultades para definir los Requerimientos

Para Chaves (2006), “Durante la etapa de especificación de requerimientos

se pueden presentar muchos inconvenientes los cuales son importantes de
identificar y prevenir.”. Estas dificultades son:

 Los requerimientos no son obvios y vienen de muchas fuentes.

 Son difíciles de expresar en palabras (el lenguaje es ambiguo).
  La cantidad de requerimientos en un proyecto puede ser difícil de manejar.
 Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
 El usuario no puede explicar lo que hace
 Tiende a recordar lo excepcional y olvidar lo rutinario
 Hablan de lo que no funciona Los usuarios tienen distinto vocabulario que los
desarrolladores.
 Usan el mismo término con distinto significado

Técnicas y herramientas utilizadas en la Ingeniería de Requerimientos

Chaves (2006), menciona diversas técnicas, citando también a Herrera

(2003) para mencionar cinco técnicas y herramientas utilizadas en la Ingeniería de
Requerimientos. Estas son:

Entrevistas y Cuestionarios

Las entrevistas y cuestionarios se emplean para reunir información

proveniente de personas o de grupos. Durante la entrevista, el analista conversa
con el encuestado; el cuestionario consiste en una serie de preguntas relacionadas
con varios aspectos de un sistema. Por lo común, los encuestados son usuarios de
los sistemas existentes o usuarios en potencia del sistema propuesto. En algunos
casos, son gerentes o empleados que proporcionan datos para el sistema propuesto
o que serán afectados por él. El éxito de esta técnica, depende de la habilidad del
entrevistador y de su preparación para la misma.

Sistemas existentes

Esta técnica consiste en analizar distintos sistemas ya desarrollados que

estén relacionados con el sistema a ser construido. Por un lado, podemos analizar
las interfaces de usuario, observando el tipo de información que se maneja y cómo
es manejada, por otro lado también es útil analizar las distintas salidas que los
sistemas producen (listados, consultas, etc.), porque siempre pueden surgir nuevas
ideas sobre la base de estas.
Lluvia de ideas (Brainstorm)

Este es un modelo que se usa para generar ideas. La intención en su

aplicación es la de generar la máxima cantidad posible de requerimientos para el
sistema. No hay que detenerse en pensar si la idea es o no del todo utilizable. La
intención de este ejercicio es generar, en una primera instancia, muchas ideas.
Luego, se irán eliminando en base a distintos criterios como, por ejemplo, "caro",
"impracticable", "imposible", etc. Las reglas básicas a seguir son: Los participantes
deben pertenecer a distintas disciplinas y, preferentemente, deben tener mucha
experiencia. Esto trae aparejado la obtención de una cantidad mayor de ideas
creativas. Conviene suspender el juicio crítico y se debe permitir la evolución de
cada una de las ideas, porque sino se crea un ambiente hostil que no alienta la
generación de ideas. Por más locas o salvajes que parezcan algunas ideas, no se
las debe descartar, porque luego de maduradas probablemente se tornen en un
requerimiento sumamente útil. A veces ocurre que una idea resulta en otra idea, y
otras veces podemos relacionar varias ideas para generar una nueva. Escribir las
ideas sin censura.

Prototipos

Durante la actividad de extracción de requerimientos, puede ocurrir que

algunos requerimientos no estén demasiado claros o que no se esté muy seguro de
haber entendido correctamente los requerimientos obtenidos hasta el momento,
todo lo cual puede llevar a un desarrollo no eficaz del sistema final. Entonces, para
validar los requerimientos hallados, se construyen prototipos. Los prototipos son
simulaciones del posible producto, que luego son utilizados por el usuario final,
permitiéndonos conseguir 8 una importante retroalimentación en cuanto a si el
sistema diseñado con base a los requerimientos recolectados le permite al usuario
realizar su trabajo de manera eficiente y efectiva. El desarrollo del prototipo
comienza con la captura de requerimientos. Desarrolladores y clientes se reúnen y
definen los objetivos globales del software, identifican todos los requerimientos que
son conocidos, y señalan áreas en las que será necesaria la profundización en las
definiciones. Luego de esto, tiene lugar un “diseño rápido”. El diseño rápido se
centra en una representación de aquellos aspectos del software que serán visibles
al usuario (por ejemplo, entradas y formatos de las salidas). El diseño rápido lleva
a la construcción de un prototipo.

Casos de Uso

Los casos de uso permiten describir la posible secuencia de interacciones

entre el sistema y uno o más actores, en respuesta a un estímulo inicial proveniente
de un actor, es una descripción de un conjunto de escenarios, cada uno de ellos
comenzado con un evento inicial desde un actor hacia el sistema. La mayoría de los
requerimientos funcionales, sino todos, se pueden expresar con casos de uso.
 Conclusiones

 Los requerimientos se pueden considerar la pieza fundamental en un

proyecto de desarrollo de software
 La Ingeniería de Requerimientos cumple un papel primordial en el proceso
de producción de software, ya que se enfoca un área fundamental: la
definición de lo que se desea producir.
 La especificación de requisitos del software es una descripción completa del
comportamiento del sistema software a desarrollar.
 Durante la etapa de especificación de requerimientos se pueden presentar
muchos inconvenientes los cuales son importantes de identificar y prevenir.
 Bibliografía

Chaves, M. A. (2006). La Ingeniería de Requerimientos y su Importancia en el

Desarrollo de Proyectos de Software. Costa Rica: Intersedes.

Diccionario de la Real Academia Española. (s.f.). Requisito. Recuperado el 21 de

Enero de 2017, de http://dle.rae.es/?id=W6xh4wt

Durán, A. (19 de Septiempre de 2000). Un Entorno Metodológico de Ingeniería de

Requerimientos para Sistemas de Información. Sevilla, España.

Infastrán, E., Molina, P. J., Martí, S., & Pelechano, V. (2001). Ingeniería de
Requisitos aplicada al modelado conceptual de interfaz de usuario.
Valencia, España.

Koch, N., & Escalona, M. J. (2002). Ingeniería de Requisitos en Aplicaciones para

la Web. Sevilla, España.

M. Griselda Báez, S. I. (2001). Metodología DoRCU para la Ingeniería de. La

Habana, Cuba.

Pressman, R. S. (2010). Ingeniería de Software, Un Enfoque Práctico. Conneticut.

Pythel, P., Uhalde, C., Ramón, H. D., Castello, H., Tomasello, M., Pollo, M. F., . . .
García, R. (2011). Ingeniería de requisitos basada en técnicas de ingeniería
del conocimiento. La Plata, Argentina.