Unidad II

UNIDAD II: INGENIERIA DE
REQUISITO
Dr. Hernan Rodriguez

INGENIERIA DEL SOFTWARE UPT Bolívar
Contenido
Ingeniería de Requisito ........................................................................................................... 2
Evaluación ............................................................................................................................... 7
Ingeniería de Requisito
La ingeniería de requisitos es el proceso de recopilación, análisis y documentación
de los requisitos de un sistema de software. Es una parte fundamental del proceso de
desarrollo de software, ya que garantiza que el producto final satisfaga las necesidades del
cliente. El proceso de ingeniería de requisitos suele comenzar con una fase de recopilación
de requisitos, en la que se obtienen los requisitos del sistema de las partes interesadas. A
continuación, se analizan y priorizan estos requisitos y se crea un documento de requisitos.
Este documento se utiliza para guiar el desarrollo del software. La ingeniería de requisitos
es un proceso iterativo, ya que los requisitos de un sistema pueden cambiar con el tiempo.
Es importante mantener el documento de requisitos actualizado para que refleje con
precisión el estado actual del sistema.
El papel del ingeniero de requisitos es analizar, formular y documentar los requisitos

de un sistema de software, así como gestionar los cambios y validar los requisitos. El
ingeniero de requisitos actúa como un puente entre las necesidades de los usuarios, clientes
y otras partes interesadas y las capacidades del software. Algunas de las responsabilidades
del ingeniero de requisitos son:
1. Realizar análisis de requisitos

2. Formular y crear especificaciones de requisitos
3. Examinar y determinar especificaciones de requisitos o historias de usuarios e
identificar formas de mejorar
4. Aplicar medidas de acuerdo de los requisitos especificados
5. Documentar los requisitos del sistema
6. Garantizar el cumplimiento de los estándares industriales (por ejemplo,
automoción con ISO 26262 y SPICE)
El ingeniero de requisitos debe tener habilidades de comunicación, negociación,

análisis, modelado, verificación y gestión. Además, debe conocer las técnicas, métodos y
herramientas de la ingeniería de requisitos, así como el dominio del sistema y el contexto
de uso. La ingeniería de requisitos es un proceso iterativo y colaborativo que requiere la
participación activa de todos los involucrados en el desarrollo del software.
Un ingeniero de requisitos y un analista de negocios son dos roles diferentes que se

relacionan con el proceso de desarrollo de software. Ambos trabajan con datos, pero tienen
distintas funciones y objetivos. A continuación, te explico las principales diferencias entre
ellos:
1. Un ingeniero de requisitos se encarga de analizar, formular y documentar los

requisitos de un sistema de software, es decir, las condiciones o capacidades que
el software debe cumplir o poseer para satisfacer las necesidades del cliente o
usuario. El ingeniero de requisitos también se ocupa de gestionar los cambios y
validar los requisitos a lo largo del ciclo de vida del software. Su objetivo es
asegurar que el software se ajuste a las expectativas y especificaciones del
cliente o usuario.
2. Un analista de negocios se encarga de entender las necesidades del negocio y
traducirlas en requisitos, es decir, las metas, objetivos y resultados esperados
que describen por qué se está desarrollando el software. El analista de negocios
también se ocupa de diseñar y planear estrategias de mejora para el negocio,
basándose en la interpretación de los datos y la información proporcionada por
el analista de datos. Su objetivo es aportar valor al negocio y a los interesados.
El ingeniero de requisitos y el desarrollador son dos roles que colaboran

estrechamente en un proyecto de software. El ingeniero de requisitos se encarga de definir,
documentar y validar los requisitos del sistema, mientras que el desarrollador se encarga
de implementar, probar y desplegar el software que cumpla con esos requisitos. La relación
entre ambos roles implica una comunicación constante, un intercambio de información y
un feedback mutuo. Algunas de las actividades que realizan conjuntamente son:
➢ Revisar y acordar los requisitos del sistema

➢ Establecer los criterios de aceptación y verificación del software
➢ Diseñar la arquitectura y el diseño del software
➢ Resolver los problemas y los cambios que surjan durante el desarrollo
➢ Realizar pruebas y validaciones del software
➢ Entregar y mantener el software
La relación entre el ingeniero de requisitos y el desarrollador es fundamental para

el éxito de un proyecto de software, ya que permite asegurar la calidad, la funcionalidad y
la satisfacción del cliente. Para lograr una buena relación, ambos roles deben tener
habilidades de comunicación, negociación, análisis, modelado y gestión. Además, deben
conocer las técnicas, métodos y herramientas de la ingeniería de requisitos y el desarrollo
de software, así como el dominio del sistema y el contexto de uso.
Los requisitos funcionales y no funcionales son dos tipos de requisitos que se utilizan
para especificar las características y restricciones de un sistema de software. Los requisitos
funcionales describen lo que el sistema debe hacer, es decir, las funciones, servicios o
comportamientos que el sistema ofrece o realiza. Los requisitos no funcionales describen
cómo debe hacerlo el sistema, es decir, las propiedades, cualidades o atributos que el
sistema posee o cumple.
Algunos ejemplos de requisitos funcionales son:
➢ El sistema debe permitir al usuario iniciar sesión con su nombre de usuario y

contraseña.
➢ El sistema debe generar una factura al finalizar una compra.
➢ El sistema debe enviar una alerta al administrador cuando se detecte un error.
Algunos ejemplos de requisitos no funcionales son:
➢ El sistema debe ser fácil de usar y tener una interfaz intuitiva.

➢ El sistema debe ser seguro y proteger los datos de los usuarios.
➢ El sistema debe tener un tiempo de respuesta menor a 5 segundos.
Los requisitos funcionales y no funcionales se complementan entre sí y son

esenciales para definir el alcance, la calidad y el éxito de un proyecto de software.
Las fases de la ingeniería de requisitos son las siguientes:
➢ Elicitación: Es el proceso de recopilar los requisitos del sistema de las partes

interesadas, los usuarios y otras fuentes. Se utilizan diferentes técnicas de
elicitación, como entrevistas, cuestionarios, observación, prototipos, etc. El objetivo
es obtener una comprensión clara y completa de las necesidades y expectativas de
los involucrados en el proyecto.
➢ Modelado: Es el proceso de representar los requisitos de forma gráfica, textual o
formal. Se utilizan diferentes técnicas de modelado, como diagramas, casos de uso,
historias de usuario, etc. El objetivo es facilitar la comunicación, el análisis y la
validación de los requisitos.
➢ Análisis: Es el proceso de verificar, validar y priorizar los requisitos. Se utilizan
diferentes técnicas de análisis, como revisión, inspección, prueba, etc. El objetivo es
asegurar que los requisitos sean correctos, completos, consistentes, claros y
trazables.
➢ Gestión: Es el proceso de controlar los cambios, el alcance y la calidad de los
requisitos. Se utilizan diferentes técnicas de gestión, como identificación,
documentación, seguimiento, etc. El objetivo es mantener los requisitos alineados
con las necesidades del negocio y los objetivos del proyecto.
Una de las técnicas para el levantamiento y recolección de requisitos es el Joint

Application Design (JAD), que consiste en un proceso de trabajo colaborativo entre los
usuarios, los desarrolladores y otros interesados en el desarrollo de un sistema de software.
El objetivo de esta técnica es obtener un consenso sobre los requisitos del sistema, reducir
el tiempo de desarrollo y mejorar la calidad de las especificaciones.
El JAD se basa en la realización de talleres o sesiones de trabajo, donde los

participantes se reúnen para definir y revisar los requisitos del negocio y del sistema. Estas
sesiones son moderadas por un líder JAD, que facilita la comunicación, el análisis y la
resolución de conflictos. Durante las sesiones, se utilizan diferentes técnicas de elicitación,
como la tormenta de ideas, los cuestionarios, la observación, los prototipos, etc. También
se emplean herramientas CASE para modelar y documentar los requisitos de forma gráfica,
textual o formal.
El JAD es una técnica que requiere una buena preparación, planificación y

seguimiento. Antes de iniciar las sesiones, se debe definir el alcance y la estructura del
proyecto, el material necesario, el lugar, la agenda y los participantes. Durante las sesiones,
se debe identificar, verificar, validar y priorizar los requisitos, así como gestionar los cambios
y obtener el feedback de los participantes. Después de las sesiones, se debe validar la
información obtenida y generar los productos de salida, como el documento de requisitos,
los modelos, los prototipos, etc.
El JAD es una técnica que ofrece varias ventajas, como:
➢ Mejorar la participación y el compromiso de los usuarios y los desarrolladores

➢ Aumentar la comprensión y el consenso sobre los requisitos
➢ Reducir la ambigüedad y la incertidumbre sobre los requisitos
➢ Acelerar el proceso de desarrollo y reducir los costes
➢ Mejorar la calidad y la satisfacción del producto final
Sin embargo, el JAD también presenta algunos inconvenientes, como:
➢ Requerir una alta disponibilidad y dedicación de los participantes

➢ Depender de la habilidad y la experiencia del líder JAD
➢ Ser menos efectivo en proyectos grandes y complejos
➢ Generar una gran cantidad de información que puede ser difícil de gestionar
➢ Poder provocar conflictos o resistencias al cambio entre los participantes
Evaluación
1. Defina los requisitos funcionales y no funcionales y de ejemplo de cada uno.
2. ¿Cuál es el papel del Ingeniero de requisitos?
3. ¿Cuáles son las técnicas para el levantamiento y requisición de requisitos?
4. ¿explique en 100 palabras cuál es la diferencia entre un ingeniero de requisitos y un
analista de negocios?
5. Resuma en 100 palabras. Las fases de la ingeniería de requisitos.
6. ¿Cómo se relaciona el Ingeniero de requisito y el desarrollador de un proyecto?

Unidad II

Cargado por

Copyright:

Formatos disponibles

Unidad II

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Unidad II

Cargado por

Copyright:

Formatos disponibles

UNIDAD II: INGENIERIA DE

Dr. Hernan Rodriguez

El papel del ingeniero de requisitos es analizar, formular y documentar los requisitos

1. Realizar análisis de requisitos

El ingeniero de requisitos debe tener habilidades de comunicación, negociación,

Un ingeniero de requisitos y un analista de negocios son dos roles diferentes que se

1. Un ingeniero de requisitos se encarga de analizar, formular y documentar los

El ingeniero de requisitos y el desarrollador son dos roles que colaboran

➢ Revisar y acordar los requisitos del sistema

La relación entre el ingeniero de requisitos y el desarrollador es fundamental para

Algunos ejemplos de requisitos funcionales son:

➢ El sistema debe permitir al usuario iniciar sesión con su nombre de usuario y

Algunos ejemplos de requisitos no funcionales son:

➢ El sistema debe ser fácil de usar y tener una interfaz intuitiva.

Los requisitos funcionales y no funcionales se complementan entre sí y son

➢ Elicitación: Es el proceso de recopilar los requisitos del sistema de las partes

Una de las técnicas para el levantamiento y recolección de requisitos es el Joint

El JAD se basa en la realización de talleres o sesiones de trabajo, donde los

El JAD es una técnica que requiere una buena preparación, planificación y

El JAD es una técnica que ofrece varias ventajas, como:

➢ Mejorar la participación y el compromiso de los usuarios y los desarrolladores

Sin embargo, el JAD también presenta algunos inconvenientes, como:

➢ Requerir una alta disponibilidad y dedicación de los participantes

También podría gustarte