República Bolivariana de Venezuela
Ministerio del Poder Popular para la Educación Universitaria
Universidad Territorial Deltaica “Francisco Tamayo”
Programa Nacional de Formación en informática
Tucupita, Estado Delta Amacuro
Tutora: Integrantes:
Irangelys Silva Alejandro Zacarias v-31577721
Bladimir Vegas v-28758438
Jesús Cedeño v-28538583
Jorge Márquez v-17055732
Julio Rodríguez v-31221813
Samuel Arismendi v-28754912
Sección: AM-02 Turno: Mañana Trayecto III – Trimestre I
Introducción
La ingeniería de requisitos es un proceso fundamental en el desarrollo de
software que se encarga de identificar, analizar, documentar y validar las necesidades y
expectativas de las partes interesadas para la construcción de un sistema de software
exitoso. Este proceso consta de diversas fases, como la recolección, análisis,
documentación y validación de requisitos, en las cuales se involucra a un equipo
multidisciplinario que incluye a usuarios, clientes, analistas y desarrolladores. A pesar
de su importancia, la ingeniería de requisitos también presenta desafíos, como la falta
de comunicación efectiva entre los involucrados y la dependencia de su disponibilidad y
participación, lo que puede generar retrasos en el proceso. Para superar estos
obstáculos, se utilizan diversas técnicas de recolección de requisitos, como entrevistas,
cuestionarios, observación y talleres colaborativos como el JAD, que permiten obtener
información precisa y completa. Además, existen metodologías como el Análisis de
Puntos de Función (FPA) que ayudan a medir el tamaño y complejidad de un sistema
de software, lo que facilita la estimación de esfuerzo y recursos necesarios para su
desarrollo. En conjunto, estas herramientas y técnicas contribuyen a garantizar que los
requisitos del sistema sean claros, completos y consistentes, sentando las bases para
el éxito del proyecto de desarrollo de software.
Indice
Introducción .......................................................................................................... 2
Fases de la Ingeniería de Requisitos ................................................................... 4
Obtención de Requisitos ................................................................................... 5
Análisis de requisitos ........................................................................................ 5
Documentación de requisitos ............................................................................ 5
verificación de requisitos ................................................................................... 6
validación de requisitos ..................................................................................... 6
Personal Involucrado en la Ingeniería de Requisitos ............................................ 6
Inconvenientes que se Presentan en el Levantamiento de Requerimientos ........ 8
Técnicas para Obtener Requerimientos de Software ........................................... 9
Ventajas y Desventajas de las Técnicas de Obtención de Requerimientos ....... 11
Metodología JAD & FPA ..................................................................................... 13
Conclusión .......................................................................................................... 15
Bibliografía.......................................................................................................... 17
Fases de la Ingeniería de Requisitos
La ingeniería de requisitos es un conjunto de procesos, tareas y técnicas que
permiten la definición y gestión de los requisitos de un producto de un modo
sistemático. En definitiva, facilita los mecanismos adecuados para comprender las
necesidades del cliente, analizando sus necesidades, confirmando su viabilidad,
negociando una solución razonable, especificando la solución sin ambigüedad,
validando la especificación y gestionando los requisitos para que se transformen en un
sistema operacional.
Llevar a cabo de manera adecuada el proceso de ingeniería de requisitos
disminuye la probabilidad de fracaso de un proyecto. Esto es porque los requisitos bien
definidos permiten conocer de un modo conciso que debe ser capaz de realizar el
software a desarrollar y hace orientar las actividades, recursos y esfuerzos de manera
eficiente permitiendo la disminución de costos y retrasos. Todo ello provoca una mejora
en la calidad del software puesto que los requisitos bien especificados podrán probarse
de manera efectiva y, por tanto, cumplirse.
Para poder llevar a cabo el proceso de ingeniería de requisitos, hay que ejecutar
una serie de pasos o fases:
Análisis de Documentació
Obtención de
Requisitos n de
Requisitos
requisitos
verificación validación
de de
requisitos requisitos
Obtención de Requisitos
La obtención de requisitos es la actividad en la que un grupo especializado
extrae, de cualquier fuente de información disponible (documentos, aplicaciones
existentes, entrevistas, etc.), las necesidades de cubrir dicho sistema. El proceso de
obtención de requisitos puede resultar complejo, debido a esto existen un conjunto de
técnicas que permiten hacer este proceso de una forma más eficiente y precisa,
obteniéndose necesidades y modelos del sistema.
Análisis de requisitos
En esta fase, los requisitos recopilados en la etapa de elicitación se analizan y
se organizan en una estructura coherente. Se identifican posibles conflictos o
inconsistencias entre los requisitos y se priorizan según su importancia y viabilidad.
Documentación de requisitos
En esta fase, los requisitos analizados se documentan de manera detallada y
precisa en un documento formal conocido como especificación de requisitos. Este
documento describe de forma clara y concisa qué funcionalidades debe tener el
sistema, cómo debe comportarse y qué restricciones debe cumplir.
verificación de requisitos
En esta fase, se verifica que los requisitos definidos en la especificación son
correctos, completos y consistentes. Se realizan revisiones y pruebas para garantizar
que los requisitos cumplen con las necesidades del usuario y son factibles de
implementar.
validación de requisitos
La validación de requisitos es el proceso de confirmar que los requisitos
especificados para un sistema de software son correctos, completos y consistentes con
las necesidades y expectativas del usuario. Es una fase crucial en la ingeniería de
requisitos, ya que garantiza que el producto final cumpla con los objetivos del proyecto.
Personal Involucrado en la Ingeniería de
Requisitos
En la ingeniería de requisitos, cada uno de los roles mencionados desempeña
funciones específicas que contribuyen al proceso de definición, validación y gestión de
los requisitos de un sistema de software.
Los roles más importantes pueden clasificarse en el siguiente orden:
Usuario final: Los usuarios finales son las personas que utilizarán el sistema de
software una vez que esté implementado. Su rol es fundamental en la ingeniería de
requisitos, ya que son quienes aportan sus necesidades, expectativas y feedback sobre
cómo debería funcionar el sistema.
Usuario líder: El usuario líder es un representante designado por los usuarios finales
para actuar como intermediario entre ellos y el equipo de desarrollo. Su función
principal es asegurarse de que los requisitos del sistema reflejen adecuadamente las
necesidades del negocio y los usuarios finales
Personal de mantenimiento: El personal de mantenimiento es responsable de
mantener y mejorar el sistema de software una vez que ha sido implementado. En el
contexto de la ingeniería de requisitos, su rol implica participar en la definición de
requisitos de mantenimiento, identificar posibles mejoras y cambios futuros, y asegurar
que los requisitos sean claros y fáciles de entender para facilitar las tareas de
mantenimiento.
Analistas y Programadores: Los analistas son profesionales encargados de analizar,
documentar y gestionar los requisitos del sistema, mientras que los programadores son
responsables de implementar el sistema de software según los requisitos definidos.
Personal de pruebas: El personal de pruebas se encarga de verificar que el sistema
cumpla con los requisitos especificados y funcione correctamente antes de su puesta
en producción.
Inconvenientes que se Presentan en el
Levantamiento de Requerimientos
El levantamiento de requerimientos es una etapa crítica en el proceso de
desarrollo de software, ya que de la correcta identificación y documentación de los
requisitos depende en gran medida el éxito del proyecto. Sin embargo, durante esta
fase pueden surgir diversos inconvenientes como los que se describen a continuación:
Falta de comunicación: La comunicación insuficiente o ineficaz entre los
diferentes actores involucrados el proceso de recolección de requisitos puede llevar a
malentendidos, información incompleta o inconsistente, y a la identificación errónea de
necesidades.
Cambios constantes: Los cambios constantes en los requisitos por parte de los
interesados pueden dificultar la definición y estabilización de los requisitos, lo que
puede provocar retrasos en el proyecto, aumento de costos y desviaciones en el
alcance.
Ambigüedad: La ambigüedad en los requisitos puede generar interpretaciones
erróneas, malentendidos y confusiones durante el proceso de desarrollo. Es importante
ser claro y preciso al documentar los requisitos para evitar malentendidos.
Requisitos contradictorios: En ocasiones, diferentes partes de los interesados
pueden tener requerimientos que entran en conflicto entre sí. Es importante identificar y
resolver estas contradicciones de manera temprana para evitar problemas futuros.
Falta de participación de los interesados clave: Si no se involucra a todos los
interesados relevantes en el proceso de levantamiento de requisitos, es probable que
se pasen por alto necesidades importantes o se tomen decisiones sin tener en cuenta
todas las perspectivas.
Sobreingeniería: Definir requisitos demasiado detallados o complejos puede llevar a
un exceso de funcionalidades innecesarias, aumentando la complejidad del sistema y
el costo del desarrollo.
Subestimación del tiempo y recursos necesarios: No asignar suficiente tiempo y
recursos para el levantamiento de requisitos puede resultar en una recopilación
incompleta o superficial, lo que puede causar problemas durante las etapas posteriores
del proyecto.
Técnicas para Obtener Requerimientos de
Software
Los analistas pueden emplear varias técnicas para obtener los requisitos del
cliente, dichas técnicas son fundamentales para comprender las necesidades de los
usuarios y garantizar que el software desarrollado cumpla con sus expectativas y
requisitos, esto ha incluido técnicas tales como las entrevistas, o talleres en grupos
para crear listas de requisitos, las técnicas más utilizadas son:
Entrevistas: Consiste en reunirse con las partes interesadas, usuarios y otros
involucrados para recopilar información sobre sus necesidades y expectativas con
respecto al software.
Cuestionarios: Se utilizan para recopilar información de un gran número de
personas de manera estandarizada. Pueden ser útiles para obtener una visión general
de los requisitos del software.
Observación: Consiste en observar a los usuarios mientras realizan sus tareas
diarias para identificar problemas, necesidades y oportunidades de mejora que puedan
traducirse en requisitos de software.
Grupos de enfoque: Reunir a un grupo de usuarios representativos para
discutir y compartir sus experiencias, opiniones y necesidades con respecto al
software.
Prototipado: Desarrollar prototipos del software para permitir a los usuarios
experimentar con él y proporcionar retroalimentación sobre sus necesidades y
expectativas.
Casos de Uso: Un caso de uso es una técnica para documentar posibles
requisitos, graficando la relación del sistema con los usuarios u otros sistemas
Ventajas y Desventajas de las Técnicas de Obtención de Requerimientos
Técnicas Ventajas Desventajas
-Permite una interacción directa. -Puede ser costoso en términos de tiempo y
recursos.
Entrevistas -Se puede aclarar dudas y obtener información
detallada. -La información obtenida puede estar
sesgada por la interpretación del
entrevistador.
-Permite recopilar información de un gran número de -Puede haber sesgo en las respuestas debido
-personas de manera eficiente. a la interpretación de las preguntas.
-Facilita la estandarización de las respuestas para su -No permite profundizar en las respuestas ni
Cuestionarios análisis. aclarar dudas.
-Puede ser útil para obtener una visión general de -Puede ser difícil obtener una tasa alta de
los requisitos del software. respuesta.
-Permite identificar problemas, necesidades y -Puede resultar intrusiva para los usuarios.
oportunidades de mejora de manera directa.
-Requiere tiempo y recursos para realizar la
Observación -Proporciona información objetiva sobre cómo los observación.
usuarios interactúan con el software.
-La presencia del observador puede alterar el
-Puede revelar requisitos no expresados por los comportamiento de los usuarios.
usuarios.
-Permite recopilar información de un grupo diverso -Puede haber sesgo en las opiniones
de usuarios en un entorno colaborativo. expresadas por los participantes.
Grupos de -Facilita la generación de ideas y soluciones a través -Algunos usuarios pueden dominar la
enfoque de la discusión grupal. discusión, limitando la participación de otros.
-Puede revelar necesidades y expectativas comunes -Puede ser difícil llegar a un consenso en un
entre los participantes. grupo grande o diverso.
-Permite a los usuarios experimentar con el software -Puede requerir tiempo y recursos adicionales
y proporcionar retroalimentación temprana. para desarrollar prototipos.
-Facilita la validación de requisitos y la detección de -Los usuarios pueden centrarse en aspectos
Prototipado problemas de usabilidad. superficiales del prototipo en lugar de los
requisitos fundamentales.
-Ayuda a visualizar y comunicar las ideas de manera
tangible. -Puede generar expectativas poco realistas
sobre el producto final.
-Los casos de uso son una forma efectiva de -Los casos de uso pueden volverse complejos
comunicar los requisitos del sistema a las partes y difíciles de entender si no se gestionan
interesadas. adecuadamente.
Casos de uso
-Los casos de uso se centran en las interacciones -Los casos de usos pueden ser demasiado
entre el sistema y los usuarios. generales lo cual puede ocasionar falta de
detalle.
Metodología JAD & FPA
Metodología Características Ventajas Desventajas
La Metodología JAD es un -Colaboración: Promueve la -Mayor participación de los -Dependencia de la
enfoque colaborativo que colaboración y la involucrados: Involucra a disponibilidad de las partes
involucra a los participantes comunicación entre las los participantes clave interesadas: Requiere la
clave, como usuarios, diferentes partes interesadas desde el principio, lo que participación constante de
desarrolladores y otros para identificar y validar los ayuda a garantizar que los los involucrados, lo que
expertos, en sesiones de requisitos del sistema. requisitos reflejen con puede ser difícil de
trabajo estructuradas para precisión las necesidades coordinar en entornos
definir y refinar los -Sesiones estructuradas: Se del negocio. donde los horarios son
requisitos del sistema. realizan sesiones de trabajo conflictivos.
estructuradas y guiadas por -Comunicación efectiva:
Consiste en un taller donde un facilitador para discutir, Facilita la comunicación -Posible sesgo en la toma
los empleados de la analizar y documentar los entre los diferentes equipos de decisiones: La influencia
compañía y los técnicos requisitos. y participantes, lo que de ciertos participantes
informáticos se reúnen, reduce malentendidos y puede llevar a decisiones
durante uno o varios días, -Iterativo: Permite la revisión y errores en la definición de sesgadas o no
para definir y revisar los refinamiento continuo de los requisitos. representativas de las
requerimientos de negocio requisitos a lo largo del necesidades generales del
para el sistema. proceso de desarrollo del - Mayor velocidad en la sistema.
sistema. definición de requisitos:
Permite una definición más -Costo y tiempo: Organizar
rápida y precisa de los sesiones de trabajo JAD
requisitos del sistema en puede requerir una
comparación con otros inversión significativa de
enfoques tradicionales. tiempo y recursos, lo que
puede no ser viable en
todos los proyectos.
La Metodología FPA es una -Basada en funciones: Se -Objetividad: Proporciona -Complejidad: La aplicación
técnica de medición del centra en medir el tamaño una medida objetiva y de la Metodología FPA
tamaño funcional de un funcional del sistema en estandarizada del tamaño puede resultar compleja y
sistema informático basada función de las funciones que funcional del sistema, lo requerir un conocimiento
en la identificación y realiza, independientemente que facilita la estimación detallado del sistema y sus
clasificación de las de cómo se implementen. precisa de esfuerzo y funciones para realizar una
funciones que proporciona costos. medición precisa.
el sistema. -Estándar internacional:
Existen estándares -Comparabilidad: Permite -Dependencia de la calidad
Pretende medir la internacionales para la comparar el tamaño de la documentación: La
funcionalidad entregada al aplicación de la Metodología funcional de sistemas precisión de la medición
usuario independientemente FPA, lo que garantiza similares o relacionados, lo FPA depende en gran
de la tecnología utilizada consistencia y comparabilidad que ayuda a identificar medida de la calidad y
para la construcción y en las mediciones. patrones y tendencias en el completitud de la
explotación del software, y desarrollo de software. documentación disponible
también es útil en -Métrica objetiva: Proporciona sobre el sistema.
cualquiera de las fases de una métrica objetiva y -Estimación precisa: Ayuda
vida del software, desde el cuantificable del tamaño del a realizar estimaciones más -Limitaciones en entornos
diseño inicial hasta la sistema, que puede utilizarse precisas del esfuerzo y el ágiles: En entornos ágiles
explotación y para estimar esfuerzo, costos tiempo requeridos para donde los requisitos
mantenimiento. y calidad. desarrollar un sistema cambian con frecuencia, la
informático. Metodología FPA puede no
ser tan efectiva para medir
el tamaño funcional del
sistema.
Conclusión
La ingeniería de requisitos es un proceso fundamental en el desarrollo de
software, ya que establece las bases para la construcción de un sistema que cumpla
con las necesidades y expectativas del cliente, las fases de la ingeniería de requisitos,
como la recolección, análisis, documentación y validación, son críticas para garantizar
que los requisitos sean claros, completos y consistentes. Cada fase tiene su
importancia, ya que la recolección permite entender las necesidades del cliente, el
análisis ayuda a descomponer y priorizar los requisitos, la documentación asegura una
comunicación efectiva y la validación verifica que los requisitos sean correctos, de igual
forma la participación activa del personal involucrado en la ingeniería de requisitos, que
incluye a los participantes clave, como usuarios, clientes, analistas y desarrolladores es
esencial para garantizar que los requisitos reflejen con precisión las necesidades del
negocio y sean factibles de implementar. Sin embargo, la ingeniería de requisitos
también presenta algunos inconvenientes, como la falta de comunicación efectiva entre
los involucrados puede llevar a malentendidos y errores en la definición de requisitos.
Además, la dependencia de la disponibilidad y participación de las partes interesadas
puede generar retrasos en el proceso.
Para superar estos desafíos, existen diversas técnicas de recolección de requisitos que
ayudan a obtener información precisa y completa. Algunas técnicas comunes incluyen
entrevistas, cuestionarios, observación y talleres colaborativos como JAD. Estas
técnicas permiten una comprensión más profunda de las necesidades del cliente y
facilitan la identificación y validación de los requisitos. La ingeniería de requisitos es un
proceso crítico en el desarrollo de software que requiere la participación de los
involucrados y el uso de técnicas adecuadas para garantizar el éxito del proyecto. A
través de sus fases y técnicas, se busca obtener requisitos claros y completos que
sirvan como base sólida para el desarrollo de sistemas exitosos.
Bibliografía
"Requisitos de software" de Karl Wiegers y Joy Beatty.
"Gestión de requisitos de software: un enfoque de casos de uso" de Dean Leffingwell y
Don Widrig.
“CLASIFICACIONES DE TIPOS DE REQUISITOS PARA LA MEJORA DEL PROCESO
DE DESARROLLO DEL SOFTWARE” Adelaida Ramírez Fernández
