1. Introducción a la Ingeniería de
INGENIERÍA de
Requerimientos
REQUERIMIENTOS
La Ingeniería de Requerimientos (IR) se
Unidad I – Parte I relaciona con la búsqueda de la situación
futura y el cambio asociado.
Introducción – Ing. De Software – Ing. De
Requerimientos – Ciclo de Vida del Software – Está relacionada con encontrar (capturar)
Crisis del Software – Chaos Report información y considerar posibles
opciones, y con la identificación de lo que
debería ser diseñado en orden a satisfacer
una necesidad futura percibida
1 2
Hito: “No Silver Bullets” Hito: “No Silver Bullets”
(Brooks, 1987) (Brooks, 1987)
• Problemas o dificultades esenciales:
• Paper magistral de Brooks (Abril,1987)
– Complejidad
• Dos tipos de problemas:
• no lineal con el tamaño,
– Esenciales: inherentes a la naturaleza • dependiente de diversos factores,
del software.
• problemas de gestión, de comunicación, …
– Accidentales: relacionadas a la
– Conformidad (complejidad arbitraria, puntos de vista)
producción de software, pero que no
son inherentes a él. – Modificabilidad (presiones constantes al cambio)
– Invisibilidad (no tangible, no visualizable)
3
Brooks, Fred P. (1987). "No Silver Bullet - Essence and Accidents in Software Engineering". IEEE Brooks, Fred P. (1987). "No Silver Bullet - Essence and Accidents in Software Engineering". IEEE
4
Computer, 20(4): 10-19. Computer, 20(4): 10-19.
Hito: “No Silver Bullets” Hito: “No Silver Bullets”
(Brooks, 1987) (Brooks, 1987)
“La parte más difícil de construir un sistema de software es “La parte más difícil de construir un sistema de software es
decidir precisamente qué construir. decidir precisamente qué construir.
Ninguna otra parte del trabajo conceptual es tan dificultosa Ninguna otra parte del trabajo conceptual es tan
como establecer los requerimientos técnicos detallados, dificultosa como establecer los requerimientos técnicos
incluyendo todas las interfases hacia las personas, detallados, incluyendo todas las interfases hacia las
máquinas y otros sistemas de software. personas, máquinas y otros sistemas de software.
Ninguna otra parte del trabajo paraliza el sistema si es mal Ninguna otra parte del trabajo paraliza el sistema si es mal
hecha. Ninguna otra parte es tan difícil de rectificar hecha. Ninguna otra parte es tan difícil de rectificar
después” después”
Brooks, Fred P. (1987). "No Silver Bullet - Essence and Accidents in Software Engineering". IEEE
5 Brooks, Fred P. (1987). "No Silver Bullet - Essence and Accidents in Software Engineering". IEEE
6
Computer, 20(4): 10-19. Luciana C. Ballejos Computer, 20(4): 10-19. Luciana C. Ballejos
CIDISI, Centro de I+D en Ingeniería en Sistemas de Información CIDISI, Centro de I+D en Ingeniería en Sistemas de Información
1

2. Hito: “No Silver Bullets”
Costo relativo de corregir defectos
(Brooks, 1987)
3 ideas fundamentales a considerar:
• La parte más difícil del trabajo: al inicio.
• El impacto perjudicial del error.
• La dificultad de rectificar posteriormente.
El costo de reparar un defecto de software varía de acuerdo
al momento en que se esté dentro del ciclo de vida del
software.
Brooks, Fred P. (1987). "No Silver Bullet - Essence and Accidents in Software Engineering". IEEE
7 Wiegers, Karl E. (2003). Software Requirements, Second Edition. Microsoft Press 8
Computer, 20(4): 10-19. Luciana C. Ballejos
CIDISI, Centro de I+D en Ingeniería en Sistemas de Información
Problemas del Diseño de Soft Problemas del Diseño de Soft
Áreas problemáticas:
Causas de problemas:
• Obtención de información informal,
• funcionalidades implícitas o no establecidas,
• Simplificaciones en los procesos
• suposiciones no fundamentadas o no
• Prácticas usadas para obtener, documentar, comunicadas,
acordar y alterar los requerimientos de los
• requerimientos no adecuadamente documentados
productos.
• cambios casuales en los procesos de
requerimientos.
9 10
Problemas del Diseño de Soft Orientación de la IR
Entre el 40 y el 60 % de los defectos encontrados Trabajo presente Opciones
pertenecen a la etapa de requerimientos. del usuario Tecnológicas
IR: relacionada
Esencialmente la diferencia es “entre lo que los a encontrar la
Diseño del situación futura
desarrolladores piensan que tienen que construir y Sistema
y el cambio
lo que los usuarios o clientes piensan que van a
asociado
obtener”.
Sistema Futuro
t
11 12
2

3. Los ciclos de vida y la IR Los ciclos de vida y la IR
Requerimientos
Diseño
Codificación
Requerimientos en el
modelo de Ciclo de Vida Testeo
en Cascada.
Operación
Requerimientos en el modelo en V.
13 14
Los ciclos de vida y la IR Los ciclos de vida y la IR
Modelo Incremental Modelo Espiral
• Comenzar produciendo una pequeña parte del sistema (pero
completamente funcional).
• Una vez completada, se crea una segunda parte, acoplada a la primera, de
manera de que en cada iteración, se obtiene una versión aumentada del
sistema hasta terminar.
• No hay conocimiento completo a priori de los requerimientos
(incertidumbre)
Cada secuencia produce un “incremento” de software.
Cada iteración o “incremento” produce una versión
operativa se entrega un producto operacional.
15 16
Luciana C. Ballejos
CIDISI, Centro de I+D en Ingeniería en Sistemas de Información
Los ciclos de vida y la IR Requerimientos en CMMi
Requerimientos en el Rational Unified Process (RUP)
Categorías:
- Administración
de Procesos
- Administración
de Proyectos
- Ingeniería
- Soporte
REQM: Administración de Requerim. PI: Integración de Producto.
RD: Desarrollo de Requerimientos. VER: Verificación
17 TS: Solución Técnica. VAL: Validación 18
3

4. La IR en la Ingeniería de Software Crisis del Software: Crónicas
Del Proceso de Producción de Software se encarga la • Nuevo aeropuerto de Denver (’90s)
• El sistema de manejo de equipaje
Ingeniería de Software subterráneo: casi 34 km de cintas
transportadoras y 4000 telecars
¿Cómo surge?: Debido a los problemas ocasionados por errores independientes para 20 aerolíneas.
de software
• Un sistema central de 100 PC en red, 5000
Función: Producción de Software más robusto, proveyendo
sensores eléctricos, 400 receptores de radio
procesos de producción más confiables. y 56 lectores de barra.
19 20
Crisis del Software: Crónicas Crisis del Software: Crónicas
• Por nueve meses no estuvo en funcionamiento por • FAA de EEUU: Reemplazo del sistema de control de
tráfico aéreo por el AAS (Advanced Automation System).
errores en el sistema de control.
• Cuando un sistema es muy complejo no hay un gerente
• 193 millones de dólares, pospuso la apertura del enteramente responsable del mismo.
aeropuerto por 8 meses. De octubre a mayo, el costo • Más de 1 millón de líneas, distribuidas en más de 100
1,1 millón por día. computadoras.
De cada 6 sistemas que se ponen en operación, 2 son • Se eligió a IBM.
cancelados. • Se esperaba pagar 500 U$S por línea de código
El mayor presupuesto promedio estimado siempre es la • Se pagó 700 - 900 por línea
mitad de lo que se paga. • Cada línea de código escrita se reescribió once veces!
Alrededor de ¾ de los grandes sistemas no funcionan • La FAA: canceló dos de las 4 partes solicitadas y rediseñó
(para atrás) otra.
como se intentó o no son usados.
• Costo total del proyecto 144 millones de U$S.
21 22
CHAOS Report (2009)
Crónicas • Exitoso: El proyecto se completa en el tiempo y con el
presupuesto planificado, con todas las funciones y
características especificadas originalmente.
• De cada 6 sistemas que se ponen en • Comprometido/Cuestionado (“Challenged”): El proyecto se
operación, 2 son cancelados. completa y es operacional, pero con tiempos y presupuesto
mayores a los estimados y/o con menor cantidad de
• El mayor presupuesto promedio estimado características y funciones de las especificadas inicialmente.
siempre es la mitad de lo que se paga. • Fallado o Cancelado: El proyecto se cancela antes de ser
completado o nunca es implementado.
• Alrededor del 70% de los grandes sistemas
no funcionan como se intentó o no son
usados.
23 24
The Standish Group. (2009). Chaos Report 2009.
4

5. CHAOS Report (2009) Chaos Report
• Por qué fallan los proyectos?
1. Requerimientos Incompletos 13.1%
2. Pobre Inclusión de los Usuarios 12.4%
3. Planificación y Estrategia 10.6%
4. Expectativas no Realistas 9.9%
5. Falta de Soporte Gerencial 9.3%
6. Requerimientos y Espec. Cambiantes 8.7%
7. Recursos Insuficientes 8.1%
8. Reqs. dejan de ser Necesarios 7.5%
9. Pobre Manejo de IT 6.2%
25
10. Desconocimiento de la Tecnología 4.3% 26
The Standish Group. (2009). Chaos Report 2009.
Chaos Report Introducción: Abstracción vs. Formalismo
Abstracto
• Por qué los proyectos son exitosos?
Muy alto
1. Usuarios involucrados 15.9% (IDEAL)
nivel
2. Soporte Gerencial 13.9% No Alg.
(CONVENCIONAL) + Algorit.
3. Requerimientos Claros 13.0%
4. Planeamiento Apropiado 9.6% Alto
nivel
5. Expectativas Realistas 8.2%
Bajo
6. Milestones Pequeños (hitos/objetivos) 7.7% + nivel
7. Recursos Apropiados 7.2%
Meta Nivel de
8. Metodología y Estrategia 5.3% máquina
9. Visión y Objetivos Claros 2.9% Prosa Especificación Código
Concreto
10. Trabajo Duro, Recursos en Foco 2.4% 27 Informal Nivel Lingüístico Formal 28
¿En qué se relaciona la Ingeniería de Software con Introducción
la Ingeniería en Requerimientos?
Lo que abarca Ingeniería de Requerimientos?
La Ingeniería de Software abarca todo lo concerniente al
desarrollo del Software, ofreciendo métodos y técnicas para las UdI
DEFINICIÓN
?
distintas etapas del ciclo de vida, de manera de desarrollar y
mantener software de calidad:
♣ Definición del Problema
DISEÑO
♣ Estudio de Factibilidad
♣ Análisis CICLO DE IMPLEMEN- SOFTWARE
♣ Diseño del Sistema VIDA TACIÓN
♣ Diseño Detallado DEL SOFT
♣ Implementación
♣ Mantenimiento 29 30
5

6. Introducción Necesidad de Requerimientos
La Ingeniería en requerimientos entra como una subtarea de la
¿Porqué es necesaria una etapa de Requerimientos?
Ingeniería de Software; propone métodos, técnicas y herramientas que
faciliten el trabajo de Definición de lo que se quiere de un software: Determina- Compra Instalación Introducción y Uso Uso
ción de o entrenamiento limitado Total
♣ Definición del Problema Necesidades Desarrollo
Ingeniería de requerimientos:
♣ Estudio de Factibilidad
Rol fundamental
♣ Análisis t
♣ Diseño del Sistema Evaluación y Evaluación de
♣ Diseño Detallado decisión de limitaciones
♣ Implementación etapa siguiente del producto
♣ Mantenimiento
Debido a esta relación se deriva que:
Muy fuerte Desde el punto de vista del cliente una etapa de requerimientos
interacción es necesaria porque le ayuda a entender y expresar las nuevas
Ing. en requerimientos Demandantes del Soft necesidades y a identificar cómo puede satisfacerlas.
31 32
Requerimiento - requisito Requerimiento - requisito
¿Qué es un Requerimiento?
’94 Jones: “Los requerimientos son las sentencias de necesidades
de un usuario que lanzan el desarrollo de un programa o sistema”
• Simplemente... cualquier cosa que un cliente necesite.
’93 Alan Davis: “una necesidad de un usuario o una facilidad
• Desde el punto de vista del diseñador, cualquier cosa necesaria, función o atributo de un sistema que puede ser sensado
que necesite ser diseñada. desde una posición externa al sistema”
En general, el énfasis está en:
Lo que irá en el producto, sus características. No cómo el
producto se diseñará o construirá.
33 34
Requerimiento - requisito Requerimiento - requisito
La más notable de las definiciones es la de la IEEE:
’97 Sommerville and Sawyer: “Requerimientos son... una 1. Una condición o capacidad necesaria para un
especificación de lo que debería ser implementado. Son una usuario para resolver un problema o alcanzar un
descripción de cómo el sistema debería comportarse o de una
propiedad o atributo del sistema. Puede ser una restricción sobre
objetivo.
el proceso de desarrollo del sistema” 2. Una condición o capacidad que debe ser alcanzada
o poseída por un sistema o componente de un sistema
Lo que realmente necesitamos es asegurarnos que todos los para satisfacer un contrato, estándar, especificación, u
stakeholders del proyecto llegan a un entendimiento otro documento formalmente impuesto.
compartido de los términos usados para describir los
requerimientos.
3. Una representación documentada de una condición
o capacidad dada en 1 o 2.
35 36
6

7. Requerimientos Requerimientos
Clasificación de los requerimientos
Clasificación de los requerimientos:
En cuanto al nivel de abstracción
En cuanto al contenido
• requerimientos-c: contienen los requerimientos funcionales,
requerimientos-
• Funcionales: describen las entradas, salidas y funciones de
no funcionales e inversos descriptos en un lenguaje
Funcionales
transformación del Sistema; comprensible al cliente/usuario, utilizando excesivamente el
vocabulario de la aplicación;
• No Funcionales: definen atributos como confiabilidad,
Funcionales
performance, entre otros; • requerimientos-d: contienen también los requerimientos
requerimientos-
funcionales, no funcionales e inversos, siendo, mientras
• Inversos: definen cómo el Sistema de Software nunca se debe tanto, descriptos en un lenguaje orientado al
comportar. analista/desarrollador, evitando al máximo la utilización del
37 vocabulario de la aplicación. 38
Requerimientos Reqs. del
Requerimientos
Otra clasificación Negocio
Relación entre los componentes de
En cuanto al origen Doc. Visión y Alcance requerimientos de software
Reqs. del Atributos de
•Del negocio: objetivos de alto nivel de la organización.
Usuario Calidad
Documentados en la visión o alcance del proyecto.
Otros RNFs
Doc. Casos de Uso
•Del usuario: tareas que los usuarios deben hacer con el producto.
Documentados en los casos de uso o escenarios.
Reqs. del Reqs. Restricciones
•Funcionales: las funcionalidades del soft a construir. Sistema funcionales
•No Funcionales: que responden a estándares, regulaciones,
contratos, interfases, performance, restricciones y atributos de Especificación de
Requerimientos de Software
calidad. (SRS)
39 40
Wiegers, Karl E. (2003). Software Requirements, Second Edition. Microsoft Press
7