Introducción a la Ingeniería de Requerimientos
Parte 1: Qué es y Porqué.
Parte 2: Fundamentos.
Parte 3: Entregables
Sebastian Uchitel 2
(Repaso)
La Ingeniería de Software
• Se ocupa de construir un producto de software de alta calidad bajo restricciones de tiempo y presupuesto.
• Sus dos problemáticas fundamentales son:
– Lidiar con la escala y complejidad de sistemas de software actuales.
– Identificar que significa alta calidad
• Requiere (como todas las ingenierías)
– Rigor, creatividad, documentación y gestión.
Calidad ~ Cumplimiento con Propósito
• Software se desarrolla para un propósito
• El propósito es relativo a actividades humanas
– E.g. El propósito de un sistema bancario se relaciona con los negocios de un un banco y las necesidades de sus clientes.
• El propósito es generalmente complejo.
• Mucha gente y actividades involucradas
• Intereses contrapuestos
• ...
• Ingeniería de Requerimientos trata (en parte) con la
identificación del propósito.
Sebastian Uchitel 4
Qué es Ingeniería de Requerimientos?
Requirements Engineering (RE) is a set of activities concerned with identifying and communicating the
purpose of a software-intensive system, and the contexts in which it will be used. Hence, RE acts as the bridge between the real world needs
of users, customers, and other constituencies affected by a software
system, and the capabilities and opportunities afforded by software-
intensive technologies No es una fase
o etapa!
Comunicación es tan importante como la recolección
y análisis
Calidad signifíca que cumple con su
propósito.
No se puede decir nada acerca de calidad si no se
entiende el propósito.
Diseñadores necesitan saber cómo y donde el
sistema será utilizado.
Requerimientos tratan en parte de lo que se necesita…
…y en parte de lo que es posible Necesidad de indentificar todas las
partes involucradas - no sólo el usario y cliente
(transparencia de Steve Easterbrook)
El Software siempre está embebido
• Si la calidad del software depende del grado de cumplimiento de su propósito, entonces debemos considerar el software como
embebido...
• Embebido en Hardware
– Propiedades de hardware?
– Obvio, pero a veces olvidado...
• Embebido en actividad humana
– Propiedades?
• Embebido en un mundo físico
– Propiedades?
• En este curso hablaremos de Sistemas Intensivos en Software (o
“Sistema”) para referirnos a Software + Hardware + Entorno
• Ingeniería de Requerimientos de Sistemas (Intensivos en Software)
Sebastian Uchitel 6
La voz de la experiencia...
• Poor requirements are ubiquitous ...
"requirements need to be engineered and have continuing review & revision"
(Bell & Thayer, empirical study, 1976)
• RE is hard & critical ...
"hardest, most important function of SE is the iterative extraction & refinement of requirements"
(F. Brooks, 1987)
• Prohibitive cost of late correction ...
"up to 200 x cost of early correction"
(Boehm, 1981)
(transparencia de Emmanuel Letier)
El Costo de Corrección Tardía (Boehm, 1981)
Requerimientos
Diseño
Codigo
Test de Unidad
Test de Aceptaci ón
Mantenimiento
200
50 10 20
1 5
Costo Relativo de Correción de Errores
El costo de un error depende del numero de decisiones que luego se
hacen sobre él
Errores cometidos al entender los
requerimientos tienen el potencial de ser los de mayor costo, porque
muchas decisiones de diseño dependen de
estos.
Sebastian Uchitel 8
Problemas de Desarrollo: Un ejemplo regional...
(transparencia de Miguel Felder)
El Problema de los Requerimientos:
(más recientemente...)
• Relevamiento de proyectos de software en EEUU por el Standish Group
• Causa percibida de éxito y fracaso (Top 3)
28%
31%
Cancelados
46%
53%
Con problemas
26%
16%
Exitosos
1998 1994
3.
2.
1.
Falta de recursos Requerimientos
cambiantes Clara descripción de
requerimientos
Falta de input de los usuarios
Requerimientos incompletos Apoyo de gerencia
ejecutiva
Requerimientos incompletos Falta de input de
los usuarios Usuarios involucrados
Cancelado Con problemas
Exitoso
Sebastian Uchitel 10
Factores que ponen en problemas un proyecto
23.0%
Otros
3.7%
Tecnología nueva 10.
4.3%
Tiempos poco realistas 9.
5.3%
Objetivos poco claros 8.
5.9%
Expectativas no realistas 7.
6.4%
Falta de recursos 6.
7.0%
Incompetencia técnica 5.
7.5%
Falta de apoyo de gerencia ejecutiva 4.
11.8%
Requerimientos y Especificaciones cambiantes 3.
12.3%
Requerimientos y Especificaciones Incompletos
2.
12.8%
Falta de input de los usuarios 1.
Posiblemente anecdótico pero da una indicación de los problemas percibidos en el desarrollo de software
(transparencia de Emmanuel Letier)
Factores que causan una cancelación
9.9%
Otros
4.3%
Incompetencia Tecnológica 10.
6.2%
Falta de gestión 9.
7.5%
“Ya no lo necesitabamos”
8.
8.1%
Falta de planificación 7.
8.7%
Requerimientos y Especificaciones cambiantes
6.
9.3%
Falta de apoyo gerencial 5.
9.9%
Expectativas no realistas 4.
10.6%
Falta de recursos 3.
12.4%
Falta de involucramiento de usuarios 2.
13.1%
Requerimientos incompletos 1.
Sebastian Uchitel 12
Factores que contribuyen al éxito
13.9%
Otros
10.
2.9%
Visión y Objetivos claros
9.
5.3%
Ownership
8.
7.2%
Personal competente
7.
7.7%
Entregas (milestones) mas pequeñas
6.
8.2%
Expectativas realistas
5.
9.6%
Planificación Apropiada
4.
13.0%
Descripción de Requerimientos Clara
3.
13.9%
Apoyo de Gerencia Ejecutiva
2.
15.9%
Involucramiento de Usuarios
1.
(transparencia de Emmanuel Letier)
Resultados similares en otros estudios ...
• Relevamiento de 3800 organizaciones europeas, 17 países
Los problemas mayores en software son...
– Especificación de requerimientos
> 50% respuestas
– Gestión de requerimientos
> 50% respuestas
(European Software Institute, 1996)
Sebastian Uchitel 14
Porqué IR es tan difícil?
• Sistemas compuestos: Gente + Software + Dispositivos físicos.
– Modos de interacción: complejos, de larga duración, iniciativa híbrida, iniciativa mixta, social.
– Software le da forma a la actividad humana de manera compleja.
• Muchos de los problemas que queremos resolver son
“difíciles”
– Formulación definitiva del problema?
– Correctitud de Soluciones no suele ser blanco o negro – Cada problema es único hasta cierto punto
– Cada problema puede ser tratado como síntoma de otro – Problemas suelen tener dimensiones políticas, éticas y y/o
profesionales de peso.
Porqué IR es tan difícil?
• Múltiples sistemas coexisten:
– sistema actual,
– múltiples propuestas de sistema a construir, – familia de sistemas,
– posibles evoluciones del sistema
• Múltiples niveles de abstracción:
– de objetivos de negocios a detalles operativos
• Múltiples aspectos
– Funcional, calidad, desarrollo – aspectos duros y blandos
• Stakeholders (partes interesadas) con antecedentes e intereses diversos
– clientes, usuarios, expertos del dominio, desarrolladores, ...
→ conflictos
Sebastian Uchitel 16
Qué hace un Ingeniero de Requerimientos? (1)
• “Elicitar” Información
– Objetivos, contexto y alcance
– Conocimiento del Dominio y Requerimientos
• Modelado y Análisis
– Objetivos, objetos, casos de uso, escenarios, ...
• Comunicar requerimientos
– resultados del análisis (Feedback), Documento de Especificación de Requerimientos, prototipos, ...
(transparencia adapteda de E. Letier)
Elicit: to evoke or draw out (a response, answer, or fact) from someone in
reaction to one's own actions or questions
Qué hace un Ingeniero de Requerimientos? (1)
• Negociación y acuerdo de requerimientos
– Manejo de conflictos y riesgos
– Ayuda en selección y priorización de requerimientos
• Gestión y Evolución de Requerimientos
– Trazabilidad de requerimientos
– Gestión de pedidos de cambios a requerimientos y sus
impactos
Sebastian Uchitel 18
El rol central de modelos de requerimientos
elicitación y modelado
generación de entregables
stakeholders
documentos sistemas existentes
análisis y validación
Modelos de Requerimientos
Especificación de Requerimientos
(transparencia adapted de E. Letier)
