La ingeniería de requerimientos es esencial para garantizar la calidad de un sistema de información, alineándose con las expectativas de los usuarios. Este proceso incluye actividades como extracción, análisis, especificación y validación de requerimientos, tanto funcionales como no funcionales. Se enfrenta a desafíos como la ambigüedad del lenguaje y la interrelación de los requerimientos a lo largo del ciclo de desarrollo.

1. Ingeniería de
requerimientos
Participantes:
Mauricio Carrillo Coto
Daniel Víquez
Tatiana Herrera
Alejandro Fernández
Michael Porras

2. ¿Qué es ingeniería de
requerimientos?
• Es una pieza clave para proporcionar un sistema de
información con calidad.
• Esta calidad debe entenderse como la satisfacción del
usuario ante el sistema de información
proporcionado, que cubre las expectativas, deseos y
necesidades que los usuarios manifestaron.

3. ¿Qué es ingeniería de requerimientos
según la IEEE?
La IEEE lo define como:
• “La condición o capacidad que debe poseer un
sistema o un componente de un sistema para
satisfacer un contrato, un estándar, una especificación
u otro documento impuesto.”

4. ¿Qué es la definición de
requerimientos?
• Es un conjunto estructurado de actividades, con las
cuales se obtiene, se analiza, se negocia, se valida y
mantiene el documento de especificación de
requerimientos.

5. Actividades Dentro de
la Ingeniería de
Requerimientos.

6. • Extracción :Extracción es el nombre comúnmente dado a
las actividades involucradas en el descubrimiento de los
requerimientos del sistema.
• 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.

7. • Especificación: En esta fase se documentan los
requerimientos acordados con el cliente, en un nivel
apropiado de detalle.
• Validación: La validación es la etapa final de la Ingeniería
de Requerimientos. 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.

8. Dificultades para definir
los requerimientos.

9. • Los requerimientos no son obvios y vienen de muchas fuentes.
• Son difíciles de expresar en palabras de lenguaje ambiguo.
• Existen muchos tipos de requerimientos y diferentes niveles de detalle.
• La cantidad de requerimientos en un proyecto pueden ser difíciles de
manejar.
• Nunca son iguales, algunos son más difíciles, más riesgosos, mas
importantes o más estables que otros.
• Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
• Los requerimientos están relacionados unos con otros, y a su vez se
relacionan con otras partes del proceso.
• Cada requerimiento tiene propiedades únicas y abarcan áreas
funcionales específicas.
• Son difíciles de cuantificar, ya que cada conjunto de requerimientos es
particular para cada proyecto.

10. Requerimientos
Funcionales y no
funcionales

11. Requerimientos Funcionales
Los requerimientos funcionales de un sistema, son aquellos que
describen cualquier actividad que este deba realizar, en otras
palabras, el comportamiento o función particular de un sistema o
software cuando se cumplen ciertas condiciones.
Por lo general, estos deben incluir funciones desempeñadas por
pantallas específicas, descripciones de los flujos de trabajo a ser
desempeñados por el sistema y otros requerimientos de negocio,
cumplimiento, seguridad u otra índole.

12. Ejemplos:
• El sistema controlará el acceso y lo permitirá solamente a
usuarios autorizados.
• La base de datos será implementada con trazas de auditoría.
• Las hojas de cálculo aseguraran los datos usando firmas
electrónicas.

13. Requerimientos No Funcionales
Los requerimientos no funcionales representan
características generales y restricciones de la aplicación o
sistema que se esté desarrollando.
Suelen presentar dificultades en su definición dado que su
conformidad o no conformidad podría ser sujeto de libre
interpretación, por lo cual es recomendable acompañar su
definición con criterios de aceptación que se puedan
medir.

14. Ejemplos:
• Toda funcionalidad del sistema y transacción de negocio
debe responder al usuario en menos de 5 segundos.
• El sistema debe ser capaz de operar adecuadamente con
hasta 100.000 usuarios con sesiones concurrentes.
• El sistema no continuará operando en caso de fuego. (Ej.
Un ascensor).

15. GRACIAS