Introducción a la Ingeniería de

Requerimientos

Parte 1: Qué es y Porqué.

Parte 2: Fundamentos.
Parte 3: Entregables
 (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.

Sebastian Uchitel 2
 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 (transparencia adaptada de Steve Easterbrook) 3

 Qué es Ingeniería de Requerimientos?

No es una fase
o etapa!
Requirements Engineering (RE) is a
Comunicación set of activities concerned with
Diseñadores
es tan importante identifying and communicating the
necesitan saber
como la recolección purpose of a software-intensive cómo y donde el
y análisis system, and the contexts in which it sistema será
will be used. Hence, RE acts as the utilizado.
bridge between the real world needs
of users, customers, and other Requerimientos
Calidad signifíca constituencies affected by a software tratan en parte de
que cumple con su lo que se necesita…
system, and the capabilities and
propósito.
No se puede decir opportunities afforded by software-
intensive technologies …y en parte de lo
nada acerca de
que es posible
calidad si no se
entiende el Necesidad de indentificar todas las
propósito. partes involucradas - no sólo el usario y
cliente

Sebastian Uchitel (transparencia de Steve Easterbrook) 4

 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 5
 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)

Sebastian Uchitel (transparencia de Emmanuel Letier) 6

 El Costo de Corrección Tardía (Boehm, 1981)

Costo Relativo de Correción de Errores 200

El costo de un error
depende del numero de
decisiones que luego se
hacen sobre él

Errores cometidos al
50 entender los
requerimientos tienen
20 el potencial de ser los
5 10 de mayor costo, porque
1
muchas decisiones de
tos eño i g o a d ión n to diseño dependen de
en is od id ac ie estos.
i D C n p t m
e rim e
U c e e ni
u t d A nt
q s d e a
Re Te s t M
Te

Sebastian Uchitel (transparencia de Emmanuel Letier) 7

 Problemas de Desarrollo: Un ejemplo regional...

(transparencia de Miguel Felder)

Sebastian Uchitel 8
 El Problema de los Requerimientos:
(más recientemente...)
• Relevamiento de proyectos de software en EEUU por el
Standish Group
1994 1998
Exitosos 16% 26%
Con problemas 53% 46%
Cancelados 31% 28%

• Causa percibida de éxito y fracaso (Top 3)

Exitoso Con problemas Cancelado
1. Usuarios involucrados Falta de input de Requerimientos
los usuarios incompletos
2. Apoyo de gerencia Requerimientos Falta de input de
ejecutiva incompletos los usuarios
3. Clara descripción de Requerimientos Falta de recursos
requerimientos cambiantes
Sebastian Uchitel (transparencia de Emmanuel Letier) 9
 Factores que ponen en problemas un proyecto

1. Falta de input de los usuarios 12.8%

2. Requerimientos y Especificaciones 12.3%
Incompletos
3. Requerimientos y Especificaciones cambiantes 11.8%
4. Falta de apoyo de gerencia ejecutiva 7.5%
5. Incompetencia técnica 7.0%
6. Falta de recursos 6.4%
7. Expectativas no realistas 5.9%
8. Objetivos poco claros 5.3%
9. Tiempos poco realistas 4.3%
10. Tecnología nueva 3.7%
Otros 23.0%

Posiblemente anecdótico pero da una indicación de los

problemas percibidos en el desarrollo de software

Sebastian Uchitel (transparencia de Emmanuel Letier) 10

 Factores que causan una cancelación

1. Requerimientos incompletos 13.1%

2. Falta de involucramiento de usuarios 12.4%
3. Falta de recursos 10.6%
4. Expectativas no realistas 9.9%
5. Falta de apoyo gerencial 9.3%
6. Requerimientos y Especificaciones 8.7%
cambiantes
7. Falta de planificación 8.1%
8. “Ya no lo necesitabamos” 7.5%
9. Falta de gestión 6.2%
10. Incompetencia Tecnológica 4.3%
Otros 9.9%

Sebastian Uchitel (transparencia de Emmanuel Letier) 11

 Factores que contribuyen al éxito

1. Involucramiento de Usuarios 15.9%

2. Apoyo de Gerencia Ejecutiva 13.9%
3. Descripción de Requerimientos Clara 13.0%
4. Planificación Apropiada 9.6%
5. Expectativas realistas 8.2%
6. Entregas (milestones) mas pequeñas 7.7%
7. Personal competente 7.2%
8. Ownership 5.3%
9. Visión y Objetivos claros 2.9%
10. Otros 13.9%

Sebastian Uchitel (transparencia de Emmanuel Letier) 12

 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 (transparencia de Emmanuel Letier) 13

 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.

Sebastian Uchitel 14
 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 (transparencia adapteda de A. van Lamsweerde) 15

 Qué hace un Ingeniero de Requerimientos? (1)

Elicit: to evoke or draw out (a response,

answer, or fact) from someone in
• “Elicitar” Información reaction to one's own actions or
questions
– 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, ...

Sebastian Uchitel (transparencia adapteda de E. Letier) 16

 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 (transparencia adapteda de E. Letier) 17

 El rol central de modelos de requerimientos

Modelos de Requerimientos

stakeholders generación de
entregables
elicitación
y modelado
sistemas
existentes
Especificación
de Requerimientos

documentos

análisis
y validación
Sebastian Uchitel (transparencia adapted de E. Letier) 18
 Resumen de Parte 1

• Definición de Ingeniería de Requerimientos

• Importancia y dificultades de IR en el

desarrollo de sistemas

• Actividades del Ingeniero de Requerimientos

• Rol central de modelos en IR

Sebastian Uchitel 19