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.