REPÚBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DEL PODER POPULAR PARA LA EDUCACION UNIVERSITARIA

UNIVERSIDAD NACIONAL EXPERIMENTAL DE LA GRAN CARACAS
PROGRAMA NACIONAL DE FORMACION EN INFORMATICA
NUCLEO ALTAGRACIA

INGENIERIA DE SOFTWARE UNIDAD II

Tutor Académico Autor:

Sánchez Gregory Betancourt José
C.I V-12.258.118 C.I V-30.031.724

CARACAS, JULIO DE 2025

 INDICE
RESUMEN ………………………………………………………………………….. 1
INTRODUCCION …………………………………………..………………….…… 2
¿QUÉ SON REQUISITOS? ……………………….……………………………… 3
TIPOS DE REQUISITOS …………………………………………………. ……... 3
ATRIBUTOS DE CALIDAD ………………………………………………………. 8
NECESIDADES, OBJETIVOS Y ACTORES RELACIONADOS CON LOS 11
REQUISITOS…………………………………………………………..……………..
FASES DE LA INGENIERÍA DE REQUISITOS: ELIMINACIÓN, 16
MODELADO, ANÁLISIS Y GESTIÓN…………………….………………………
TÉCNICAS PARA EL LEVANTAMIENTO Y RECOLECCIÓN DE 17
REQUISITOS…………………………………………………………….…………..
CONCLUSIONES ………………..………………………………………………… 19
RECOMENDACIONES …………………………………………………………… 20
BIBLIOGRAFÍA …………………………………………………………………… 21
 RESUMEN
La ingeniería de requisitos es un proceso fundamental en el desarrollo de
sistemas de software, que garantiza la correcta identificación, análisis y gestión de
las necesidades de los stakeholders. Este informe aborda los conceptos clave,
comenzando con la definición de requisitos y su clasificación en funcionales, no
funcionales y otros tipos. Se explican los atributos de calidad que determinan la
eficacia del software, así como las necesidades, objetivos y actores involucrados en
el proceso.
Además, se detallan las fases de la ingeniería de requisitos: eliminación de
ambigüedades, modelado, análisis y gestión, junto con técnicas como Joint
Application Design (JAD) para el levantamiento de requisitos. El documento
concluye con recomendaciones prácticas para optimizar este proceso en proyectos
reales, destacando la importancia de una comunicación clara y herramientas
colaborativas.

1
 INTRODUCCIÓN
En el ámbito del desarrollo de software, la ingeniería de requisitos es la base
que determina el éxito o fracaso de un proyecto. Un requisito mal definido puede
derivar en costosos retrabajos o productos que no satisfacen las expectativas de los
usuarios. Esta unidad busca proporcionar una comprensión integral de cómo
capturar, documentar y gestionar requisitos de manera efectiva.

Objetivos del informe:

1. Definir qué son los requisitos y su importancia en el ciclo de vida del software.
2. Clasificar los tipos de requisitos (funcionales, no funcionales) y atributos de
calidad.
3. Identificar las necesidades y actores clave en el proceso.
4. Describir las fases de la ingeniería de requisitos y técnicas como JAD.

El cuerpo del trabajo desarrollará cada punto teórico con ejemplos prácticos,
como casos de estudio donde la falta de especificaciones claras llevó al fracaso de
proyectos. Se incluirán diagramas de modelado (por ejemplo, diagramas de casos
de uso) para ilustrar cómo trasladar necesidades técnicas a requisitos tangibles.
La información se basa en estándares internacionales como el IEEE
830 para especificación de requisitos y metodologías ágiles (Scrum, Kanban), que
enfatizan la iteración constante con stakeholders. La inclusión de JAD refleja su
utilidad en entornos colaborativos para reducir brechas de comunicación.

2
 ¿QUÉ SON REQUISITOS?
Un requisito es una circunstancia o condición necesaria para algo. Puede
emplearse en muy diversos ámbitos. Una oferta de trabajo puede establecer como
requisito tener vehículo propio y estudios superiores, excluyendo por tanto a los
aspirantes que no cumplan esas condiciones. Para poder votar en un determinado
país se debe cumplir una serie de requisitos como ser mayor de edad y tener la
nacionalidad en ese país. Igualmente, una discoteca puede establecer
como requisitos de entrada condiciones tales como ser mayor de edad e ir bien
vestido. En ingeniería de sistemas se emplea el término requisito en un sentido
análogo, como una condición necesaria sobre el contenido, forma o funcionalidad
de un producto o servicio.

TIPOS DE REQUISITOS
En el desarrollo de software, los requisitos se clasifican principalmente en
funcionales y no funcionales. Los requisitos funcionales describen lo que el sistema
debe hacer, mientras que los requisitos no funcionales describen cómo debe
funcionar el sistema. Además, existen otros tipos de requisitos que no encajan
estrictamente en estas categorías, como los requisitos de negocio, de
implementación y de calidad.

Requisitos Funcionales
Los requisitos funcionales son declaraciones de los servicios que prestará el
sistema, en la forma en que reaccionará a determinados insumos. Cuando
hablamos de las entradas, no necesariamente hablamos sólo de las entradas de los
usuarios. Pueden ser interacciones con otros sistemas, respuestas automáticas,
procesos predefinidos. En algunos casos, los requisitos funcionales de los sistemas
también establecen explícitamente lo que el sistema no debe hacer. Es importante
recordar esto: un RF puede ser también una declaración negativa. Siempre y
cuando el resultado de su comportamiento sea una respuesta funcional al usuario
o a otro sistema, es correcto. Y más aún, no sólo es correcto, sino que es necesario
definirlo. Y eso nos lleva al siguiente punto.
Muchos de los problemas en la ingeniería de software (hablando sobre el
proceso de desarrollo en sí mismo) comienzan con especificaciones de requisitos
inexactas. Es natural que un Analista de Negocio (o quien sea que esté definiendo
y documentando los requerimientos del sistema) tome algunas suposiciones como
conocimiento universal, o dé por sentado algún comportamiento. Pero recuerde,
también es natural que un desarrollador de sistemas interprete un requisito ambiguo
de la manera más simple posible, para simplificar su implementación.

3
 Un claro ejemplo de estos problemas se puede encontrar en las funciones
comunes relacionadas con la Experiencia de usuario:
• Historia de Usuario: Como usuario, quiero que la aplicación sea fácil de usar,
de modo que no tenga que pasar mucho tiempo aprendiendo a usarla.
• ¿Qué significa ser “fácil de usar”?
• ¿Fácil para quién?
• ¿Cómo se mide?
• ¿Cómo lo rastreas?
• ¿Cómo se prueba? ¿Contra qué criterios?
Esto no es algo contra los desarrolladores, sino más bien contra el
comportamiento humano. Si usted asume algo, otros pueden asumir algo diferente,
y eso está bien. Pero el analista es el responsable de la documentación, por lo que
debe ser el mismo analista el que trate de asegurarse de que no hay lagunas de
comprensión o puntos grises. Esta es también la razón por la que las sesiones de
Pre-Planificación y Presentación de Historias son muy importantes para asegurarse
de que todo el equipo está en la misma página con respecto a los requisitos, su
objetivo de negocio y cómo implementarlos. Volviendo al ejemplo anterior,
podríamos dividir el requisito en varios nuevos, más fáciles de entender, desarrollar,
probar, rastrear y entregar. Uno de ellos podría serlo:
• Historia de usuario: Como usuario, quiero que se muestre un tutorial al iniciar
sesión por primera vez, para que pueda ver para qué se utiliza cada opción
de la pantalla de inicio.
• Ya sabes qué mostrar, un tutorial.
• Ya sabes lo que hay que comprobar, que explica cada opción en la pantalla
de inicio.
• Usted sabe cuando necesita ser mostrado, en el primer inicio de sesión del
usuario (puede explicar más adelante si el tutorial puede ser omitido,
mostrado en otros momentos, accedido desde alguna sección dentro del
menú, etc.)
Volviendo a FR, en principio, la especificación de los requisitos funcionales
de un sistema debe ser completa y coherente. Completar significa que todos los
servicios solicitados por el usuario y/u otro sistema están definidos. La coherencia
significa que los requisitos no tienen una definición contradictoria.

4
Requisitos no Funcionales
Se trata de requisitos que no se refieren directamente a las funciones
específicas suministradas por el sistema (características de usuario), sino a las
propiedades del sistema: rendimiento, seguridad, disponibilidad. En palabras más
sencillas, no hablan de “lo que” hace el sistema, sino de “cómo” lo
hace. Alternativamente, definen restricciones del sistema tales como la capacidad
de los dispositivos de entrada/salida y la representación de los datos utilizados en
la interfaz del sistema.
Los requisitos no funcionales se originan en la necesidad del usuario, debido
a restricciones presupuestarias, políticas organizacionales, la necesidad de
interoperabilidad con otros sistemas de software o hardware, o factores externos
tales como regulaciones de seguridad, políticas de privacidad, entre otros. Existen
diferentes tipos de requisitos y se clasifican según sus implicaciones.
• Requisitos del producto. Especifican el comportamiento del producto,
como los requisitos de rendimiento sobre la velocidad de ejecución del
sistema y la cantidad de memoria necesaria, los requisitos de fiabilidad que
establecen la tasa de fallos para que el sistema sea aceptable, los requisitos
de portabilidad y los requisitos de usabilidad.
• Requisitos organizativos. Se derivan de las políticas y procedimientos
existentes en la organización cliente y en la organización del desarrollador:
estándares en los procesos a utilizar; requisitos de implementación tales
como lenguajes de programación o el método de diseño a utilizar; y requisitos
de entrega que especifican cuándo se entregará el producto y su
documentación.
• Necesidades externas. Se derivan de factores externos al sistema y a su
proceso de desarrollo. Incluyen los requisitos de interoperabilidad que
definen la forma en que el sistema interactúa con los demás sistemas de la
organización; los requisitos legales que deben seguirse para garantizar que
el sistema funciona dentro de la ley; y los requisitos éticos. Estos últimos se
imponen al sistema para asegurar que será aceptado por el usuario.

5
 A veces, en la práctica, la especificación cuantitativa de este tipo de requisitos
es difícil. No siempre es posible para los clientes traducir sus objetivos en requisitos
cuantitativos. Para algunos de ellos, como el mantenimiento, puede que no se
pueda utilizar ninguna métrica; el coste de la verificación objetiva de los requisitos
cuantitativos no funcionales puede ser muy elevado. Y es por eso que también es
muy importante ser muy cuidadoso al documentarlos. Un analista puede utilizar el
apoyo del equipo de desarrollo y del equipo de pruebas para definir criterios
mensurables con el fin de saber cuándo un requisito puede ser marcado con éxito
como “Hecho”.
Al igual que hablamos de requisitos funcionales, la generalización nunca es
buena, pero en este caso es aún más importante. ¿Por qué? Porque el resultado de
un desarrollo de requisitos no funcionales puede no ser explícito para el usuario
final.
• Mal ejemplo de RNF: El sistema debe ser seguro.
• ¿Qué tan seguro es “seguro”?
• ¿En qué situaciones?
• ¿Existe una norma a cumplir?
• ¿En qué secciones?
• ¿Qué debe ocurrir si el sistema no puede funcionar tan rápido como se
requiere?
En estos casos, la aplicación de un requisito no funcional mal definido puede
resultar problemática, costosa y lenta. También porque la mayoría de las veces, una
RNF no es algo que el equipo trabaja aislado en un período fijo de tiempo. El RNF
puede ser abordado durante todo el proyecto (e incluso antes de comenzar o
después de la entrega, en la fase de mantenimiento). Una vez más, el ejemplo
anterior podría dividirse en múltiples requisitos que son más fáciles de rastrear e
implementar.
• Buen ejemplo de RNF: Todas las comunicaciones externas entre los
servidores de datos, la aplicación y el cliente del sistema deben estar cifradas
utilizando el algoritmo RSA.
• Sabes qué tipo de comunicaciones necesitan ser encriptadas.
• Usted sabe qué algoritmo usar y validar.

6
 Los requisitos funcionales y no funcionales deben diferenciarse en el
documento de requisitos, ya sea un SRS, una cartera de productos o cualquier
artefacto que utilice. En la práctica, esto puede resultar difícil. Si se declara un
requisito no funcional por separado de los requisitos funcionales, a veces es difícil
ver la relación entre ellos. Si los RNF se declaran con requisitos funcionales, es
difícil separar las condiciones funcionales de las no funcionales e identificar los
requisitos que se refieren al sistema en su conjunto. Se debe encontrar un equilibrio
adecuado que dependa del tipo de sistema o aplicación que se especifique. Por
ejemplo, si está trabajando con un Product Backlog, podría tener Historias de
Usuario separadas para RNFs, pero añadir un enlace a ellas en las RFs que puedan
ser impactadas por ellas. Esta es una opción común en la mayoría de los sistemas
de seguimiento de billetes utilizados en la actualidad.
En cualquier caso, tanto los RFs como los RNFs deben estar siempre
documentados, incluso si es difícil establecer la relación entre ellos en los artefactos.
Esto ayudará al equipo a reducir las discusiones de ida y vuelta, ahorrar tiempo y
sobre todo, problemas innecesarios con el cliente.

Otros Tipos de Requisitos:

• Requisitos de Negocio: Definen las necesidades y objetivos generales del
negocio que el sistema debe cumplir.
• Requisitos de Usuario: Describen las expectativas y necesidades de los
usuarios finales del sistema.
• Requisitos de Calidad: Especifican los atributos de calidad del sistema,
como la fiabilidad, la seguridad, el rendimiento, la usabilidad, etc.
• Requisitos de Implementación: Definen las restricciones y limitaciones
técnicas para la implementación del sistema, como las tecnologías a utilizar,
las plataformas compatibles, etc.

Es importante considerar todos estos tipos de requisitos para asegurar que

el sistema final satisfaga las necesidades del negocio, los usuarios y las partes
interesadas, además de cumplir con los estándares de calidad y rendimiento
esperados.

7
 ATRIBUTOS DE CALIDAD
La calidad es un concepto aplicable en casi cualquier escenario, y la industria
de software no es la excepción. De acuerdo con la Real Academia Española (RAE),
la calidad se define a partir de un conjunto de propiedades inherentes a algo, que
permiten determinar su valor. Es decir, la calidad es medible en consideración del
contexto y las condiciones en las que se ve implicado el producto o servicio a
evaluar. Sin embargo, ¿Cuáles son los aspectos a considerar al determinar la
calidad de un componente, software, sistema o aplicación? Para resolver esta
pregunta es necesario hablar de los atributos de calidad de software, establecidos
por la industria para evaluar las cualidades de un producto informático.

Relevancia de atributos de calidad de software

Construir un sistema es una tarea compleja, debido a la cantidad de
elementos que intervienen en su totalidad. Cada atributo repercute en el
funcionamiento e impacto del producto final, de ahí la importancia de organizarlos
estratégicamente. La ingeniería de software se basa en estos principios para medir
los sistemas en las distintas etapas de desarrollo, desde la planeación hasta la
evaluación. En la actualidad las empresas requieren de métricas para analizar la
arquitectura de sus productos en función de los parámetros marcados por la
industria a la que pertenecen.
Con esta información, las organizaciones pueden detectar las fortalezas y
debilidades de sus productos, encaminadas a la búsqueda de alternativas para el
mejoramiento de la experiencia de los usuarios (UX). La reducción de riesgos,
costos y tiempo son algunos de los beneficios que se pueden conseguir al evaluar
los diferentes atributos de calidad de software.

¿Cómo se miden los atributos de calidad de software?

De acuerdo con un estudio publicado por la International Journal of Scientific
and Research Publication (IJSRP) la calidad de un software puede evaluarse desde
dos perspectivas: la funcionalidad y la estructura. La funcionalidad hace referencia
al cumplimiento de los requisitos del producto en relación con las necesidades del
negocio. Por su parte, la calidad estructural refleja los aspectos no funcionales del
sistema, como la escalabilidad, rendimiento, seguridad, entre otras.
Al hablar de cualidades no tangibles puede resultar complicado establecer
parámetros para realizar una evaluación. Es por esto que, organizaciones
internacionales entre ellas la Organización Internacional de Normalización (ISO, por
sus siglas en inglés) han propuesto modelos de estandarización de calidad, con el
objetivo de unificar los atributos medibles a nivel global.

8
 El modelo ISO/IEC TR 9126 fue inicialmente propuesto para la evaluación de
la calidad de software. Más tarde fue sustituido por ISO/IEC 25022, en el que se
sugieren características específicas —internas y externas— para satisfacer las
necesidades de los usuarios a través de los sistemas.

¿Cuáles son los atributos de calidad de software?

Ana Ochoa, Practice Manager en Testing IT, comparte cuáles son
los atributos de calidad que se deberían monitorear durante las etapas de desarrollo
y liberación de tu sistema.

• Funcional
o Adecuación.
o Funcionalidad correcta, completa y apropiada.

• Performance
o Eficiencia
o Tiempo de respuesta
o Utilización de recursos
o Capacidad
o Volumen de carga y estrés

• Compatibilidad
o Coexistencia
o Interoperabilidad

• Usabilidad
o Operabilidad
o Aprendizaje
o Look & Feel
o Accesibilidad

9
 o UX/UI
o Protección a errores de usuario

• Fiabilidad
o Madurez
o Disponibilidad
o Fault Tolerance
o Capacidad de recuperación

• Seguridad
o Confidencialidad
o Integridad
o No repudiation
o Accountability
o Authenticity
o Pen Test

• Mantenibilidad
o Modularidad
o Reusabilidad
o Analizabilidad
o Testability

• Portabilidad
o Facilidad de instalación
o Capacidad de ser reemplazado
o Adaptabilidad

10
 NECESIDADES, OBJETIVOS Y ACTORES RELACIONADOS CON LOS
REQUISITOS.
En la gestión de proyectos y desarrollo de software, las necesidades,
objetivos y actores están intrínsecamente relacionados con los requisitos. Las
necesidades son la base, representando las carencias o deseos que motivan la
creación de un producto o sistema. Los objetivos son la meta que se busca alcanzar
al satisfacer esas necesidades, mientras que los actores son las partes interesadas,
como usuarios, clientes y desarrolladores, que influyen en la definición y
cumplimiento de los requisitos. A continuación, se va a profundizar en cada uno de
ellos:

Necesidades
Las necesidades son la motivación inicial para cualquier proyecto,
representan los problemas, deseos o expectativas que los usuarios o el negocio
buscan resolver con el sistema de software. Son la base para definir los requisitos
y deben ser identificadas con precisión para evitar fallos en el desarrollo. Ejemplos
pueden ser la necesidad de un sistema de gestión de inventario, necesidad de una
aplicación móvil para compras en línea.

• Características clave:
o Origen: Surgen de usuarios finales, áreas de negocio o regulaciones
externas.
o Tipos:
➢ Explícitas: Expresadas directamente por el cliente ("Necesito un
sistema de facturación electrónica").
➢ Implícitas: No declaradas pero esenciales ("El sistema debe ser
intuitivo").

➢ Tácitas: Suposiciones basadas en el contexto ( "Se espera que

funcione sin internet ocasionalmente")

11
Objetivos

Los objetivos son metas concretas y medibles que el sistema debe cumplir
para satisfacer las necesidades. Sirven para orientar el desarrollo y la
implementación del proyecto, no son requisitos en sí mismos, sino el "qué" que los
requisitos (el "cómo") deben cumplir.

• Características Clave de los Objetivos

o Jerarquía:

➢ Objetivos estratégicos (alto nivel):

Ejemplo: "Incrementar la retención de clientes en un 15% en 6
meses."
➢ Objetivos tácticos (acciones específicas):
Ejemplo: "Implementar un sistema de fidelización con puntos
redimibles."

o Relación con requisitos:

➢ Cada objetivo puede generar múltiples requisitos funcionales y no

funcionales.
➢ Ejemplo:

▪ Objetivo: "Reducir el tiempo de procesamiento de pedidos

de 24h a 2h."
▪ Requisitos derivados:
▪ Funcional: "Automatizar la asignación de
repartidores."
▪ No funcional: "El sistema debe procesar 100
pedidos/minuto."

12
 • Metodología SMART para Definir Objetivos

El marco SMART asegura que los objetivos sean útiles para la ingeniería de
requisitos:

Ejemplo
Criterio Descripción Ejemplo Correcto
Incorrecto

Enfocado en un área "Reducir errores en

"Mejorar el
Específico clara, sin facturación
sistema."
ambigüedades. electrónica."

Cuantificable con "Disminuir errores del "Disminuir

Medible
métricas. 5% al 1%." errores."

"Implementar 2 "Integrar 10
Factible con los
Alcanzable métodos de pago pasarelas de pago
recursos disponibles.
nuevos." en 1 semana."

"Añadir autenticación
Alineado con "Incluir realidad
biométrica para
Relevante necesidades del aumentada (sin
cumplir con la norma
negocio/usuario. necesidad clara)."
X."

"Lanzar el módulo de
"Lanzar el módulo
Temporal Con plazo definido. devoluciones en Q3
cuando esté listo."
2025."

• Proceso para Derivar Requisitos desde Objetivos

o Identificar el objetivo SMART:

Ejemplo: "Reducir el abandono del carrito de compras del 70% al 40%
en 4 meses."

o Descomponer en sub-objetivos:

▪ "Mostrar costos de envío en la primera pantalla del checkout."

▪ "Guardar automáticamente los carritos abandonados por 7 días."

o Traducir a requisitos:

▪ Funcional: "El sistema debe calcular y mostrar costos de envío

antes de ingresar datos personales."

13
 ▪ No funcional: "La recuperación de carritos abandonados debe
tener un 99.9% de disponibilidad."

Actores (Stakeholders)

Los actores son todas las personas, sistemas u organizaciones que influyen
o son afectados por los requisitos del software. Su identificación es crucial para
evitar omisiones.

• Clasificación:

Tipo de Actor Rol Ejemplo

Interactúan directamente Cajeros, clientes de un

Usuarios finales
con el sistema. banco.

Financian el proyecto y Gerentes de área, dueños

Clientes/Sponsors
definen necesidades. de negocio.

Equipo de Implementan los Programadores,

desarrollo requisitos. arquitectos de software.

Imponen restricciones Gobierno (ej: Ley de

Reguladores
legales o técnicas. Protección de Datos).

APIs de pago
Sistemas externos Interfazan con el software.
(MercadoPago, PayPal).

• Importancia de los actores:

• Perspectivas diversas: Cada actor tiene prioridades distintas (ej:

Usuarios quieren facilidad; reguladores exigen seguridad).
• Técnicas para involucrarlos:
▪ Entrevistas (para usuarios clave).
▪ Talleres colaborativos (como JAD).
▪ Matriz RACI (para definir responsabilidades).

14
 • Ejemplo Integrado (Caso de un E-commerce)

Elemento Descripción

Necesidad "Aumentar las ventas online en un 20% el próximo año."

"Implementar un sistema de recomendación de productos basado

Objetivo
en historial de compras."

- Usuarios: Compradores.
Actores - Cliente: Dueño de la tienda.
- Regulador: Normas de protección de datos.

- Funcional: "Mostrar 3 productos recomendados en el checkout."

Requisitos
- No funcional: "Procesar recomendaciones en <1 segundo."

15
 FASES DE LA INGENIERÍA DE REQUISITOS: ELIMINACIÓN, MODELADO,
ANÁLISIS Y GESTIÓN

La ingeniería de requisitos abarca varias fases interconectadas: eliminación

(o elicitación), modelado, análisis y gestión. Estas fases trabajan juntas para definir,
comprender y gestionar los requisitos de un sistema o producto software.

Eliminación (o Elicitación) de Requisitos:

• Esta fase se centra en descubrir, recopilar y extraer los requisitos de diversas

fuentes, como usuarios, clientes, partes interesadas y el entorno.
• Se utilizan diversas técnicas como entrevistas, encuestas, talleres y análisis
de documentos para identificar las necesidades, expectativas y restricciones
del sistema.
• El objetivo es obtener una comprensión completa de lo que el sistema debe
hacer y cómo debe comportarse.

Modelado de Requisitos:

• En esta fase, los requisitos recopilados se representan de forma visual o

textual, utilizando diferentes tipos de modelos.
• Los modelos pueden ser diagramas de casos de uso, diagramas de flujo de
datos, modelos de estado, modelos de objetos, entre otros.
• El modelado ayuda a visualizar y analizar los requisitos, identificar
inconsistencias y ambigüedades, y facilitar la comunicación entre los
interesados.

Análisis de Requisitos:

• El análisis implica evaluar y validar los requisitos recopilados y modelados.

• Se verifica la coherencia, la completitud, la factibilidad y la trazabilidad de los
requisitos.
• Se identifican y resuelven conflictos o ambigüedades entre los requisitos.
• El análisis también puede incluir la priorización de los requisitos según su
importancia y viabilidad.

Gestión de Requisitos:

• La gestión de requisitos abarca todas las actividades relacionadas con el

ciclo de vida de los requisitos, desde su definición hasta su modificación y
eliminación.

16
 • Incluye la documentación, el control de versiones, la trazabilidad y la gestión
de cambios de los requisitos.
• La gestión de requisitos es crucial para mantener la coherencia y la integridad
de los requisitos a lo largo del desarrollo del proyecto.

En resumen, la ingeniería de requisitos es un proceso iterativo y colaborativo

que implica la identificación, el análisis, la especificación y la gestión de los
requisitos de un sistema para asegurar que el producto final satisfaga las
necesidades de los usuarios y las partes interesadas.

TÉCNICAS PARA EL LEVANTAMIENTO Y RECOLECCIÓN DE REQUISITOS

La técnica Joint Application Design (JAD), o Diseño Conjunto de

Aplicaciones, es un método para recopilar requisitos en el desarrollo de sistemas de
información mediante sesiones de taller intensivas con todas las partes
interesadas. JAD busca involucrar activamente a usuarios, desarrolladores y otros
interesados desde la identificación de necesidades hasta la validación de prototipos,
con el objetivo de reducir el tiempo de desarrollo y mejorar la calidad del sistema.

¿Cómo funciona JAD?

• Planificación: Se define el alcance del proyecto, se identifican los

participantes clave (incluyendo un patrocinador ejecutivo, facilitador y
redactor) y se programa una serie de sesiones de taller.
• Sesiones JAD: Se llevan a cabo reuniones estructuradas, facilitadas por un
experto, donde los participantes discuten y definen los requisitos del sistema,
validan prototipos y toman decisiones.
• Documentación: El redactor documenta las discusiones, acuerdos y
hallazgos de las sesiones para asegurar la trazabilidad y el cumplimiento de
los requisitos.

Ventajas de JAD:

• Mayor participación del usuario: Involucrar a los usuarios desde el inicio

ayuda a asegurar que el sistema final satisfaga sus necesidades y
expectativas.
• Mayor eficiencia: Las sesiones JAD permiten recopilar requisitos de forma
rápida y eficiente, reduciendo el tiempo de desarrollo.
• Mejora en la comunicación: La colaboración entre usuarios y
desarrolladores durante las sesiones JAD mejora la comunicación y reduce
malentendidos.

17
 • Resultados de mayor calidad: La participación activa de todas las partes
interesadas y la colaboración en la definición de requisitos conducen a un
producto final de mayor calidad.

Ejemplos de técnicas usadas en JAD:

• Reuniones de taller: Sesiones intensivas con todos los participantes para

discutir y definir requisitos.
• Tormenta de ideas: Sesiones para generar ideas y soluciones de forma
colaborativa.
• Prototipos: Creación de versiones preliminares del sistema para obtener
retroalimentación y validar requisitos.
• Entrevistas: Conversaciones individuales con usuarios clave para obtener
información detallada sobre sus necesidades.
• Análisis de la documentación: Revisión de documentación existente para
identificar requisitos y contexto.
• Observación: Estudio del entorno y procesos del usuario para identificar
necesidades no explícitas.

En resumen, JAD es una técnica valiosa para el levantamiento de requisitos que

promueve la colaboración, la eficiencia y la calidad en el desarrollo de sistemas.

18
 CONCLUSIONES

La ingeniería de requisitos constituye el pilar fundamental para el éxito de

cualquier proyecto de desarrollo de software, actuando como un puente crítico entre
las necesidades de los stakeholders y la solución técnica implementada. A lo largo
de esta unidad, se ha evidenciado que la identificación, análisis y gestión adecuada
de requisitos —tanto funcionales como no funcionales— no solo previene fallos
costosos en etapas posteriores, sino que también asegura que el producto final
cumpla con los estándares de calidad y las expectativas de los usuarios.

Uno de los hallazgos clave es la importancia de clasificar y priorizar los

requisitos desde las primeras fases del proyecto. Los requisitos funcionales
definen qué debe hacer el sistema, mientras que los no funcionales
establecen cómo debe hacerlo, garantizando atributos como usabilidad, seguridad
y rendimiento. Asimismo, técnicas como Joint Application Design (JAD) facilitan la
colaboración entre equipos multidisciplinarios, reduciendo ambigüedades mediante
talleres estructurados y prototipos iterativos.

Las fases de la ingeniería de requisitos —eliminación de ambigüedades,

modelado, análisis y gestión— destacan la necesidad de un enfoque sistemático.
Por ejemplo, el modelado mediante diagramas de casos de uso o historias de
usuario permite visualizar interacciones complejas, mientras que la gestión asegura
la trazabilidad ante cambios inevitables durante el desarrollo.

En conclusión, dominar la ingeniería de requisitos es esencial para mitigar

riesgos, optimizar recursos y entregar software que agregue valor real. Como
reflejan estudios del Standish Group, proyectos con requisitos bien definidos tienen
un 70% más de probabilidades de éxito. Por ello, se recomienda integrar estas
prácticas con metodologías ágiles, fomentando la comunicación continua y
adaptabilidad, para transformar desafíos en oportunidades de innovación.

19
 RECOMENDACIONES

1. Involucrar a todos los actores desde el inicio: Realizar talleres con

usuarios finales, desarrolladores y clientes para alinear expectativas.
2. Priorizar requisitos no funcionales: Atributos como seguridad,
escalabilidad y rendimiento son críticos y deben documentarse junto con los
funcionales.
3. Utilizar herramientas visuales: Diagramas UML o prototipos para validar
requisitos antes de la codificación.
4. Implementar JAD en proyectos complejos: Esta técnica reduce
ambigüedades mediante sesiones estructuradas con moderadores.
5. Revisión iterativa: Actualizar requisitos en cada sprint (en metodologías
ágiles) para adaptarse a cambios.
6. Documentar trazabilidad: Mantener un registro de cómo cada requisito se
vincula con objetivos del negocio.

20
 BIBLIOGRAFÍA

Libros y Normativas

1. IEEE. (1998). IEEE Std 830-1998: Recommended Practice for Software

Requirements Specifications. IEEE Computer Society.
2. Pohl, K. (2010). Requirements Engineering: Fundamentals, Principles, and
Techniques. Springer.
3. Sommerville, I. (2011). Ingeniería de Software (9ª ed.). Pearson Educación.
4. Pressman, R. S. (2010). Software Engineering: A Practitioner's Approach (7ª
ed.). McGraw-Hill.

Artículos y Fuentes en Línea

5. Requeridos Blog. (2023). Requerimientos funcionales y no funcionales:

Ejemplos y tips. Medium.

Disponible en: https://medium.com/@requeridosblog/requerimientos-

funcionales-y-no-funcionales-ejemplos-y-tips-aa31cb59b22a

6. Wikipedia. (2023). Requisito.

Disponible en:
https://es.wikipedia.org/wiki/Requisito#:~:text=Un%20requisito%20es%20un
a%20circunstancia,que%20no%20cumplan%20esas%20condiciones

7. TestingIT. (2022). Atributos de calidad de software.

Disponible en: https://www.testingit.com.mx/blog/atributos-de-calidad-de-

software