SlideShare una empresa de Scribd logo
1 de 17
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.

Más contenido relacionado

La actualidad más candente

Unidad 3 Modelo De Negocio
Unidad 3 Modelo De NegocioUnidad 3 Modelo De Negocio
Unidad 3 Modelo De NegocioSergio Sanchez
 
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOSINGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOSLenin Acosta Mata
 
Arquitectura de software orientada a patrones
Arquitectura de software orientada a patronesArquitectura de software orientada a patrones
Arquitectura de software orientada a patronesGustavo De la Cruz Tovar
 
Requerimientos en Ingenieria de Software
Requerimientos en Ingenieria de SoftwareRequerimientos en Ingenieria de Software
Requerimientos en Ingenieria de SoftwareKelvin Abdiel Alvarado
 
7.modelado de los requerimientos escenarios y clases
7.modelado de los requerimientos  escenarios y clases7.modelado de los requerimientos  escenarios y clases
7.modelado de los requerimientos escenarios y clasesRamiro Estigarribia Canese
 
Unidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De RequerimientosUnidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De RequerimientosSergio Sanchez
 
Normas y Estándares de calidad para el desarrollo de Software
Normas y Estándares de calidad para el desarrollo de SoftwareNormas y Estándares de calidad para el desarrollo de Software
Normas y Estándares de calidad para el desarrollo de SoftwareEvelinBermeo
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitosZuleima
 
Proceso, modelos y metodos de ingenieria de software
Proceso, modelos y metodos de ingenieria de softwareProceso, modelos y metodos de ingenieria de software
Proceso, modelos y metodos de ingenieria de softwaresergio
 
Técnicas para la Obtención de Requerimientos
Técnicas para la Obtención de RequerimientosTécnicas para la Obtención de Requerimientos
Técnicas para la Obtención de RequerimientosJuan Carlos Olivares Rojas
 
Modelo de desarrollo de software
Modelo de desarrollo de softwareModelo de desarrollo de software
Modelo de desarrollo de softwareYaskelly Yedra
 
Tecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto softwareTecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto softwareJennifer Andrea Cano Guevara
 
Documentación de sistemas
Documentación de sistemasDocumentación de sistemas
Documentación de sistemasGladys Rodriguez
 
Arquitectura flujo de datos(filtros y tuberías)
Arquitectura flujo de datos(filtros y tuberías)Arquitectura flujo de datos(filtros y tuberías)
Arquitectura flujo de datos(filtros y tuberías)katherine revelo gomez
 
Requerimientos Funcionales y No Funcionales
Requerimientos Funcionales y No FuncionalesRequerimientos Funcionales y No Funcionales
Requerimientos Funcionales y No FuncionalesCarlos Macallums
 

La actualidad más candente (20)

Unidad 3 Modelo De Negocio
Unidad 3 Modelo De NegocioUnidad 3 Modelo De Negocio
Unidad 3 Modelo De Negocio
 
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOSINGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
 
Arquitectura de software orientada a patrones
Arquitectura de software orientada a patronesArquitectura de software orientada a patrones
Arquitectura de software orientada a patrones
 
Requerimientos en Ingenieria de Software
Requerimientos en Ingenieria de SoftwareRequerimientos en Ingenieria de Software
Requerimientos en Ingenieria de Software
 
7.modelado de los requerimientos escenarios y clases
7.modelado de los requerimientos  escenarios y clases7.modelado de los requerimientos  escenarios y clases
7.modelado de los requerimientos escenarios y clases
 
Unidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De RequerimientosUnidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De Requerimientos
 
Normas y Estándares de calidad para el desarrollo de Software
Normas y Estándares de calidad para el desarrollo de SoftwareNormas y Estándares de calidad para el desarrollo de Software
Normas y Estándares de calidad para el desarrollo de Software
 
UML: CASOS DE USO
UML: CASOS DE USOUML: CASOS DE USO
UML: CASOS DE USO
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitos
 
Proceso, modelos y metodos de ingenieria de software
Proceso, modelos y metodos de ingenieria de softwareProceso, modelos y metodos de ingenieria de software
Proceso, modelos y metodos de ingenieria de software
 
Técnicas para la Obtención de Requerimientos
Técnicas para la Obtención de RequerimientosTécnicas para la Obtención de Requerimientos
Técnicas para la Obtención de Requerimientos
 
Modelo de desarrollo de software
Modelo de desarrollo de softwareModelo de desarrollo de software
Modelo de desarrollo de software
 
Tecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto softwareTecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto software
 
Modelo 4+1
Modelo 4+1Modelo 4+1
Modelo 4+1
 
Documentación de sistemas
Documentación de sistemasDocumentación de sistemas
Documentación de sistemas
 
Transparencia
TransparenciaTransparencia
Transparencia
 
Documento vision
Documento visionDocumento vision
Documento vision
 
Arquitectura flujo de datos(filtros y tuberías)
Arquitectura flujo de datos(filtros y tuberías)Arquitectura flujo de datos(filtros y tuberías)
Arquitectura flujo de datos(filtros y tuberías)
 
Requerimientos Funcionales y No Funcionales
Requerimientos Funcionales y No FuncionalesRequerimientos Funcionales y No Funcionales
Requerimientos Funcionales y No Funcionales
 
Diagrama de clases - Ejemplo monográfico 02
Diagrama de clases - Ejemplo monográfico 02Diagrama de clases - Ejemplo monográfico 02
Diagrama de clases - Ejemplo monográfico 02
 

Similar a Ingeniería de Requisitos vs Requerimientos

Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitoskelyquinayas
 
Presentación de Sistemas II
Presentación de Sistemas IIPresentación de Sistemas II
Presentación de Sistemas IIAnthoni Cedeno
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitosCarlos Chaves
 
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOSINGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOSJesus F Rosas
 
Ingenieria de requisitos
Ingenieria de requisitosIngenieria de requisitos
Ingenieria de requisitosJoamarbet
 
Ingenieria de Requerimientos
Ingenieria de RequerimientosIngenieria de Requerimientos
Ingenieria de Requerimientoskaresha3
 
Ingenieria de Requerimientos
Ingenieria de RequerimientosIngenieria de Requerimientos
Ingenieria de Requerimientoskaresha3
 
Requerimientos
RequerimientosRequerimientos
Requerimientoskaresha3
 
Ingeniería de requisitos y la ingeniería de requerimientos
Ingeniería de requisitos y la ingeniería de requerimientos Ingeniería de requisitos y la ingeniería de requerimientos
Ingeniería de requisitos y la ingeniería de requerimientos unrated999
 
Centro biotecnologo del sena
Centro biotecnologo del senaCentro biotecnologo del sena
Centro biotecnologo del senaleydismartinez1
 
Carlos figuera-ci-19897276
Carlos figuera-ci-19897276Carlos figuera-ci-19897276
Carlos figuera-ci-19897276marlev boadas
 
Unidad 1 requerimientos del software
Unidad 1 requerimientos del softwareUnidad 1 requerimientos del software
Unidad 1 requerimientos del softwareoemavarez
 
Taller requisitos
Taller requisitosTaller requisitos
Taller requisitosNando Lopez
 
Taller requisitos
Taller requisitosTaller requisitos
Taller requisitosNando Lopez
 
Unidad I Requerimientos
Unidad I RequerimientosUnidad I Requerimientos
Unidad I Requerimientosguest409adc
 
Ingenieria de requerimientos
Ingenieria de requerimientosIngenieria de requerimientos
Ingenieria de requerimientosChamoChuma Marin
 
Ingenieria de requisitos
Ingenieria de requisitos  Ingenieria de requisitos
Ingenieria de requisitos JCRREYES
 

Similar a Ingeniería de Requisitos vs Requerimientos (20)

Informe
InformeInforme
Informe
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitos
 
Presentación de Sistemas II
Presentación de Sistemas IIPresentación de Sistemas II
Presentación de Sistemas II
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitos
 
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOSINGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
 
Ingenieria de requisitos
Ingenieria de requisitosIngenieria de requisitos
Ingenieria de requisitos
 
Ingenieria de Requerimientos
Ingenieria de RequerimientosIngenieria de Requerimientos
Ingenieria de Requerimientos
 
Ingenieria de Requerimientos
Ingenieria de RequerimientosIngenieria de Requerimientos
Ingenieria de Requerimientos
 
Requerimientos
RequerimientosRequerimientos
Requerimientos
 
Ingeniería de requisitos y la ingeniería de requerimientos
Ingeniería de requisitos y la ingeniería de requerimientos Ingeniería de requisitos y la ingeniería de requerimientos
Ingeniería de requisitos y la ingeniería de requerimientos
 
Centro biotecnologo del sena
Centro biotecnologo del senaCentro biotecnologo del sena
Centro biotecnologo del sena
 
Infografía
InfografíaInfografía
Infografía
 
Carlos figuera-ci-19897276
Carlos figuera-ci-19897276Carlos figuera-ci-19897276
Carlos figuera-ci-19897276
 
Unidad 1 requerimientos del software
Unidad 1 requerimientos del softwareUnidad 1 requerimientos del software
Unidad 1 requerimientos del software
 
Taller requisitos
Taller requisitosTaller requisitos
Taller requisitos
 
Taller requisitos
Taller requisitosTaller requisitos
Taller requisitos
 
Unidad I Requerimientos
Unidad I RequerimientosUnidad I Requerimientos
Unidad I Requerimientos
 
Ingenieria de requerimientos
Ingenieria de requerimientosIngenieria de requerimientos
Ingenieria de requerimientos
 
Ingenieria de requisitos
Ingenieria de requisitos  Ingenieria de requisitos
Ingenieria de requisitos
 
Ingenieria de requisitos
Ingenieria de requisitosIngenieria de requisitos
Ingenieria de requisitos
 

Último

Fichas de Matemática TERCERO DE SECUNDARIA.pdf
Fichas de Matemática TERCERO DE SECUNDARIA.pdfFichas de Matemática TERCERO DE SECUNDARIA.pdf
Fichas de Matemática TERCERO DE SECUNDARIA.pdfssuser50d1252
 
FICHA PL PACO YUNQUE.docx PRIMARIA CUARTO GRADO
FICHA  PL PACO YUNQUE.docx PRIMARIA CUARTO GRADOFICHA  PL PACO YUNQUE.docx PRIMARIA CUARTO GRADO
FICHA PL PACO YUNQUE.docx PRIMARIA CUARTO GRADOMARIBEL DIAZ
 
PÉNSUM ENFERMERIA 2024 - ECUGENIUS S.A. V2
PÉNSUM ENFERMERIA 2024 - ECUGENIUS S.A. V2PÉNSUM ENFERMERIA 2024 - ECUGENIUS S.A. V2
PÉNSUM ENFERMERIA 2024 - ECUGENIUS S.A. V2Eliseo Delgado
 
El PROGRAMA DE TUTORÍAS PARA EL APRENDIZAJE Y LA FORMACIÓN INTEGRAL PTA/F
El PROGRAMA DE TUTORÍAS PARA EL APRENDIZAJE Y LA FORMACIÓN INTEGRAL PTA/FEl PROGRAMA DE TUTORÍAS PARA EL APRENDIZAJE Y LA FORMACIÓN INTEGRAL PTA/F
El PROGRAMA DE TUTORÍAS PARA EL APRENDIZAJE Y LA FORMACIÓN INTEGRAL PTA/FJulio Lozano
 
HISTORIETA: AVENTURAS VERDES (ECOLOGÍA).
HISTORIETA: AVENTURAS VERDES (ECOLOGÍA).HISTORIETA: AVENTURAS VERDES (ECOLOGÍA).
HISTORIETA: AVENTURAS VERDES (ECOLOGÍA).hebegris04
 
describimos como son afectados las regiones naturales del peru por la ola de ...
describimos como son afectados las regiones naturales del peru por la ola de ...describimos como son afectados las regiones naturales del peru por la ola de ...
describimos como son afectados las regiones naturales del peru por la ola de ...DavidBautistaFlores1
 
TEMA 13. LOS GOBIERNOS DEMOCRÁTICOS (1982-2018)
TEMA 13. LOS GOBIERNOS DEMOCRÁTICOS (1982-2018)TEMA 13. LOS GOBIERNOS DEMOCRÁTICOS (1982-2018)
TEMA 13. LOS GOBIERNOS DEMOCRÁTICOS (1982-2018)jlorentemartos
 
libro grafismo fonético guía de uso para el lenguaje
libro grafismo fonético guía de uso para el lenguajelibro grafismo fonético guía de uso para el lenguaje
libro grafismo fonético guía de uso para el lenguajeKattyMoran3
 
PLAN DE TUTORIA- PARA NIVEL PRIMARIA CUARTO GRADO
PLAN DE TUTORIA- PARA NIVEL PRIMARIA CUARTO GRADOPLAN DE TUTORIA- PARA NIVEL PRIMARIA CUARTO GRADO
PLAN DE TUTORIA- PARA NIVEL PRIMARIA CUARTO GRADOMARIBEL DIAZ
 
NUEVO PLAN Y PROGRAMAS DE ESTUDIO 2022.pdf
NUEVO PLAN Y PROGRAMAS DE ESTUDIO  2022.pdfNUEVO PLAN Y PROGRAMAS DE ESTUDIO  2022.pdf
NUEVO PLAN Y PROGRAMAS DE ESTUDIO 2022.pdfEDNAMONICARUIZNIETO
 
EJEMPLO MODELO DE PLAN DE REFUERZO ESCOLAR.docx
EJEMPLO MODELO DE PLAN DE REFUERZO ESCOLAR.docxEJEMPLO MODELO DE PLAN DE REFUERZO ESCOLAR.docx
EJEMPLO MODELO DE PLAN DE REFUERZO ESCOLAR.docxFabianValenciaJabo
 
HISPANIDAD - La cultura común de la HISPANOAMERICA
HISPANIDAD - La cultura común de la HISPANOAMERICAHISPANIDAD - La cultura común de la HISPANOAMERICA
HISPANIDAD - La cultura común de la HISPANOAMERICAJesus Gonzalez Losada
 
Amor o egoísmo, esa es la cuestión por definir.pdf
Amor o egoísmo, esa es la cuestión por definir.pdfAmor o egoísmo, esa es la cuestión por definir.pdf
Amor o egoísmo, esa es la cuestión por definir.pdfAlejandrino Halire Ccahuana
 
Actividades eclipse solar 2024 Educacion
Actividades eclipse solar 2024 EducacionActividades eclipse solar 2024 Educacion
Actividades eclipse solar 2024 Educacionviviantorres91
 
DIGNITAS INFINITA - DIGNIDAD HUMANA; Declaración del dicasterio para la doctr...
DIGNITAS INFINITA - DIGNIDAD HUMANA; Declaración del dicasterio para la doctr...DIGNITAS INFINITA - DIGNIDAD HUMANA; Declaración del dicasterio para la doctr...
DIGNITAS INFINITA - DIGNIDAD HUMANA; Declaración del dicasterio para la doctr...Martin M Flynn
 
Presentación de cita directa según el Manual de APA
Presentación de cita directa según el Manual de APAPresentación de cita directa según el Manual de APA
Presentación de cita directa según el Manual de APAlcolon
 
CUADERNILLO DE EJERCICIOS PARA EL TERCER TRIMESTRE, SEXTO GRADO
CUADERNILLO DE EJERCICIOS PARA EL TERCER TRIMESTRE, SEXTO GRADOCUADERNILLO DE EJERCICIOS PARA EL TERCER TRIMESTRE, SEXTO GRADO
CUADERNILLO DE EJERCICIOS PARA EL TERCER TRIMESTRE, SEXTO GRADOEveliaHernandez8
 
Si cuidamos el mundo, tendremos un mundo mejor.
Si cuidamos el mundo, tendremos un mundo mejor.Si cuidamos el mundo, tendremos un mundo mejor.
Si cuidamos el mundo, tendremos un mundo mejor.monthuerta17
 
Desarrollo de habilidades del siglo XXI - Práctica Educativa en una Unidad-Ca...
Desarrollo de habilidades del siglo XXI - Práctica Educativa en una Unidad-Ca...Desarrollo de habilidades del siglo XXI - Práctica Educativa en una Unidad-Ca...
Desarrollo de habilidades del siglo XXI - Práctica Educativa en una Unidad-Ca...Carol Andrea Eraso Guerrero
 
Fichas de matemática DE PRIMERO DE SECUNDARIA.pdf
Fichas de matemática DE PRIMERO DE SECUNDARIA.pdfFichas de matemática DE PRIMERO DE SECUNDARIA.pdf
Fichas de matemática DE PRIMERO DE SECUNDARIA.pdfssuser50d1252
 

Último (20)

Fichas de Matemática TERCERO DE SECUNDARIA.pdf
Fichas de Matemática TERCERO DE SECUNDARIA.pdfFichas de Matemática TERCERO DE SECUNDARIA.pdf
Fichas de Matemática TERCERO DE SECUNDARIA.pdf
 
FICHA PL PACO YUNQUE.docx PRIMARIA CUARTO GRADO
FICHA  PL PACO YUNQUE.docx PRIMARIA CUARTO GRADOFICHA  PL PACO YUNQUE.docx PRIMARIA CUARTO GRADO
FICHA PL PACO YUNQUE.docx PRIMARIA CUARTO GRADO
 
PÉNSUM ENFERMERIA 2024 - ECUGENIUS S.A. V2
PÉNSUM ENFERMERIA 2024 - ECUGENIUS S.A. V2PÉNSUM ENFERMERIA 2024 - ECUGENIUS S.A. V2
PÉNSUM ENFERMERIA 2024 - ECUGENIUS S.A. V2
 
El PROGRAMA DE TUTORÍAS PARA EL APRENDIZAJE Y LA FORMACIÓN INTEGRAL PTA/F
El PROGRAMA DE TUTORÍAS PARA EL APRENDIZAJE Y LA FORMACIÓN INTEGRAL PTA/FEl PROGRAMA DE TUTORÍAS PARA EL APRENDIZAJE Y LA FORMACIÓN INTEGRAL PTA/F
El PROGRAMA DE TUTORÍAS PARA EL APRENDIZAJE Y LA FORMACIÓN INTEGRAL PTA/F
 
HISTORIETA: AVENTURAS VERDES (ECOLOGÍA).
HISTORIETA: AVENTURAS VERDES (ECOLOGÍA).HISTORIETA: AVENTURAS VERDES (ECOLOGÍA).
HISTORIETA: AVENTURAS VERDES (ECOLOGÍA).
 
describimos como son afectados las regiones naturales del peru por la ola de ...
describimos como son afectados las regiones naturales del peru por la ola de ...describimos como son afectados las regiones naturales del peru por la ola de ...
describimos como son afectados las regiones naturales del peru por la ola de ...
 
TEMA 13. LOS GOBIERNOS DEMOCRÁTICOS (1982-2018)
TEMA 13. LOS GOBIERNOS DEMOCRÁTICOS (1982-2018)TEMA 13. LOS GOBIERNOS DEMOCRÁTICOS (1982-2018)
TEMA 13. LOS GOBIERNOS DEMOCRÁTICOS (1982-2018)
 
libro grafismo fonético guía de uso para el lenguaje
libro grafismo fonético guía de uso para el lenguajelibro grafismo fonético guía de uso para el lenguaje
libro grafismo fonético guía de uso para el lenguaje
 
PLAN DE TUTORIA- PARA NIVEL PRIMARIA CUARTO GRADO
PLAN DE TUTORIA- PARA NIVEL PRIMARIA CUARTO GRADOPLAN DE TUTORIA- PARA NIVEL PRIMARIA CUARTO GRADO
PLAN DE TUTORIA- PARA NIVEL PRIMARIA CUARTO GRADO
 
NUEVO PLAN Y PROGRAMAS DE ESTUDIO 2022.pdf
NUEVO PLAN Y PROGRAMAS DE ESTUDIO  2022.pdfNUEVO PLAN Y PROGRAMAS DE ESTUDIO  2022.pdf
NUEVO PLAN Y PROGRAMAS DE ESTUDIO 2022.pdf
 
EJEMPLO MODELO DE PLAN DE REFUERZO ESCOLAR.docx
EJEMPLO MODELO DE PLAN DE REFUERZO ESCOLAR.docxEJEMPLO MODELO DE PLAN DE REFUERZO ESCOLAR.docx
EJEMPLO MODELO DE PLAN DE REFUERZO ESCOLAR.docx
 
HISPANIDAD - La cultura común de la HISPANOAMERICA
HISPANIDAD - La cultura común de la HISPANOAMERICAHISPANIDAD - La cultura común de la HISPANOAMERICA
HISPANIDAD - La cultura común de la HISPANOAMERICA
 
Amor o egoísmo, esa es la cuestión por definir.pdf
Amor o egoísmo, esa es la cuestión por definir.pdfAmor o egoísmo, esa es la cuestión por definir.pdf
Amor o egoísmo, esa es la cuestión por definir.pdf
 
Actividades eclipse solar 2024 Educacion
Actividades eclipse solar 2024 EducacionActividades eclipse solar 2024 Educacion
Actividades eclipse solar 2024 Educacion
 
DIGNITAS INFINITA - DIGNIDAD HUMANA; Declaración del dicasterio para la doctr...
DIGNITAS INFINITA - DIGNIDAD HUMANA; Declaración del dicasterio para la doctr...DIGNITAS INFINITA - DIGNIDAD HUMANA; Declaración del dicasterio para la doctr...
DIGNITAS INFINITA - DIGNIDAD HUMANA; Declaración del dicasterio para la doctr...
 
Presentación de cita directa según el Manual de APA
Presentación de cita directa según el Manual de APAPresentación de cita directa según el Manual de APA
Presentación de cita directa según el Manual de APA
 
CUADERNILLO DE EJERCICIOS PARA EL TERCER TRIMESTRE, SEXTO GRADO
CUADERNILLO DE EJERCICIOS PARA EL TERCER TRIMESTRE, SEXTO GRADOCUADERNILLO DE EJERCICIOS PARA EL TERCER TRIMESTRE, SEXTO GRADO
CUADERNILLO DE EJERCICIOS PARA EL TERCER TRIMESTRE, SEXTO GRADO
 
Si cuidamos el mundo, tendremos un mundo mejor.
Si cuidamos el mundo, tendremos un mundo mejor.Si cuidamos el mundo, tendremos un mundo mejor.
Si cuidamos el mundo, tendremos un mundo mejor.
 
Desarrollo de habilidades del siglo XXI - Práctica Educativa en una Unidad-Ca...
Desarrollo de habilidades del siglo XXI - Práctica Educativa en una Unidad-Ca...Desarrollo de habilidades del siglo XXI - Práctica Educativa en una Unidad-Ca...
Desarrollo de habilidades del siglo XXI - Práctica Educativa en una Unidad-Ca...
 
Fichas de matemática DE PRIMERO DE SECUNDARIA.pdf
Fichas de matemática DE PRIMERO DE SECUNDARIA.pdfFichas de matemática DE PRIMERO DE SECUNDARIA.pdf
Fichas de matemática DE PRIMERO DE SECUNDARIA.pdf
 

Ingeniería de Requisitos vs Requerimientos

  • 1. 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
  • 2. 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.
  • 3. 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
  • 4. 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).
  • 5. 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
  • 6. 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.
  • 7. • 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
  • 8. 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
  • 9. 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 &
  • 10. 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.
  • 11. • 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
  • 12. 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).
  • 13.  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.
  • 14. 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
  • 15. 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.
  • 16. 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.
  • 17. 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.