Ingeniería de Requerimientos #1
CAPÍTULO 1

Ricardo Antonio Bermúdez Osorio
DOCENTE

Ingeniero de sistemas y computación
Universidad Tecnológica de Pereira, 2008
Especialista en ingeniería del software
Universidad Autónoma de Manizales, 2012
tusk@utp.edu.co
Objectivos
- Modelado de requerimientos mediante diagramas de actividades
- Clasificar, evaluar y priorizar requerimientos de un sistema de información
- Especificar requerimientos de software
- Revisar y conocer estándares para la gestión de requisitos de software
Introducción
- 1969: Se crea el término "Ingeniería del Software"
- 1993: Se crea el término Ingeniería de Requerimientos (RE por sus siglas en inglés)
Algo de historia
Introducción
“El grado en que un producto, proceso o sistema cumple con sus requerimientos” (IEEE 610.12)
Definiciones
“El porcentaje de defectos que se originan durante la ingeniería de requerimientos se estima en un 50%” (Karl Wiegers, 2001)
"Los analistas reportan que cerca del 71% de los proyectos de software que fracasan, lo hacen por un pobre manejo de los requerimientos" (CIO Magazine, 2005)
Introducción
Reporte CHAOS
El reporte CHAOS presenta la causa raíz del rendimiento del proyecto de software. El informe también incluye datos clásicos de CHAOS en diferentes formas con muchos gráficos. La mayoría de los datos provienen de la base de datos CHAOS de más de 50,000 perfiles de proyectos detallados año tras año.
Introducción
Reporte CHAOS

Introducción
- 1969: Se crea el término "Ingeniería del Software"
- 1993: Se crea el término Ingeniería de Requerimientos (RE por sus siglas en inglés)
Algo de historia
Introducción
- Involucrar al usuario
- Apoyo de directivos
- Clara definición de requerimientos
Factores clave para éxito de proyectos
- Requerimientos o especificaciones incompletas
Factores de reto en los proyectos
The standish group "Report CHAOS", 1995
Introducción
- Como muchos requerimientos se escriben en lenguaje natural, los directivos a menudo piensan que cualquier persona puede hacer ingeniería de requerimientos

- Pero en realidad:
“ … Obtener un buen conjunto de requerimientos es un proceso muy difícil.”

Introducción
- Debemos entender que vamos a desarrollar antes de desarrollarlo.
- Las estadísticas muestran que esto todavía no se cumple
Deb Jacobs, CrossTalk, 2006
Introducción
Se han hecho grandes avances en Ingeniería del software
- Estándares, como UML
- Metodologías formales y métodos ágiles
- Modelos de calidad, como CMMI
- Herramientas para automatizar procesos de desarrollo
Pero...

Estamos desarrollando el software correcto?
Introducción
- Todavía hay dificultades en los procesos relacionados con requerimientos:
- Pobre trabajo al especificar qué se desea.
- Los requerimientos a menudo son ambiguos, incompletos o poco claros.
- La mayoría de las veces los desarrolladores adivinan o suponen lo que se desea.
Introducción
- Una falla en los requerimientos afecta la gestión del proyecto, la arquitectura, el diseño, la implementación, el aseguramiento de calidad, la capacitación,…
- ¡Pueden causar muchas fallas en el proyecto!
Introducción
- Algunos beneficios de los buenos requerimientos:
- Acuerdo entre desarrolladores, clientes y usuarios sobre el trabajo que se debe realizar y los criterios de aceptación del sistema
- Tener elementos básicos para mejores estimaciones
- Mejoras en atributos de software (los “ilities”).
- Alcanzar los objetivos con los recursos justos (pocas omisiones, menos malentendidos y menos cambios)
Introducción
-
Cada aplicación de software tiene usuarios que confían en ella para mejorar sus vidas. El tiempo que se pasa entendiendo las necesidades de los usuarios es una inversión de alto nivel en el éxito del proyecto.
Karl Wiegers, 2001
Requisitos #1
By Ricardo Bermúdez
Requisitos #1
- 211