2/24/16
1. Introducción
Ingeniería de Requerimientos
Israel Antezana R., Mgr. Lic.
1. Introducción
“La parte más dificil de construir un sistema de
software es precisamente decidir ‘que construir’…
por lo tanto, la función más importante que el
desarrollador realiza para el cliente son la
extracción y refinamiento interativos de los
requerimientos”
F.P.Brooks “No silver bullet: Esscence and Accidents of Software
Engineering” IEEE Computer 20(4), April 1987
“Si no entiendes los requerimientos de los usuarios, no
importa como los implementes”.
Ed Yourdon
•  La primera etapa del desarrollo de
software se centra en comprender las
necesidades de los usuarios.
•  Que se supone que debe hacer el
sistema.
•  Este proceso se conoce como Ingeniería
de Requerimientos (IR)
2. Ingeniería de Requerimientos
•  El proceso de establecer los servicios que los usuarios
requieren de un sistema y las restricciones bajo las
cuales opera y es desarrollado. [Ian Sommerville]
•  ”La ingeniería de Requerimientos es el proceso que
consiste en analizar las necesidades y especificar su
comportamiento” [Roel Wieringa]
•  La Ingeniería de Requerimientos Es la aplicación
disciplinada de principios científicos y técnicas para
desarrollar, comunicar y gestionar requisitos [Christel &
Kang].
1

2. Ingeniería de requerimientos
Sentencias individuales
y difusas de requerimientos IR
Especificación coherente,
lo más completa posible,
y comprensible
•  La entrada para el proceso de IR consite de muchas sentencias
individuales informales y difusas de requerimientos, que tienen que
ser transformados en una especificación coherente (formal) que sea
tan completa como sea posible y que sea entendida y acordada
(despues de concertaciones posible) por todos los involucrados.
3. El proceso de IR
•  3.1 Elicitación de Requerimientos
•  Entender el problema y su contexto
•  Identificar las fuentes de información (expertos del
dominio, literatura del dominio, sistemas de
software existentes, sistemas similares,
estándares nacionales-internacionales, y varias
otras personas de la organizacion)
•  El conocimiento adquirido puede representarse
por
lenguaje Natural y/o modelos conceptuales
•  La elicitación debe considerarse como un proceso
que se lleva a cabo con otros procesos del
desarrollo de software, como el diseño
2/24/16
2. Ingeniería de Requerimientos
•  La IR puede verse como un proceso de
descubrimiento y comunicación de las
necesidades de clientes y usuarios y la
gestión de los cambios en dichas
necesidades:
3. El proceso de IR
•  3.2 Especificación de Requerimientos
•  Describir el problema, de forma precisa, creando modelos
que serán usados en etapas posteriores
•  La entrada es el conocimiento adquirido en la anterior
fase, que puede estar expresada en el doc. de
requerimientos
•  Un modelo no puede capturar todo lo necesario. Varios
modelos son usados para describir el problema
(correspondientes a diferentes vistas del problema)
•  Modelos orientados al usuario especifican las
caraterísticas de comportamiento y no funcionales del
sistema, y sirven para comunicación analista-usuario
•  Modelos orientados al desarrollador especifican las
propiedades funionales y no funcionales del sistema, como
restricciones en recursos, de diseño, etc. Y sirven como
bosquejos para etapas posteriores
2
 2/24/16

3. El proceso de IR El proceso de IR
•  3.4 Validación de Requirementos
•  3.3 Verificación de Requerimientos •  Lograr un acuerdo sobre la naturaleza del
•  Verificar si los modelos cumplen ciertas propiedades, usando problema
las reglas de las técnicas aplicadas.
•  Si se expresaron las reglas formalmente y cuando son
•  Para certificar que los reqs. son consistentes con
computables, esta verificación puede ser automática las intenciones de los usuarios
•  Consistencia, no existe información conflictiva en o entre los •  Todo modelo de reqs., formal o informal debe ser
modelos validado.
•  Completitud, no falta información esencial para que los •  El resultado usualmente es un acuerdo de lo que
modelos sean válidos (como nombres de entidades u
objetos) se puede lograr bajo las restricciones del proyecto
•  Correctitud, solo se presentan en los modelos •  Algunas técnicas de validación son:
combinaciones de construcciones válidas de las técnicas de –  Prototipos
modelaje. –  Animación
–  Método basado en escenarios

Tipos de Requerimientos Tipos de Requerimientos

•  Req. Funcionales •  Req. No funcionales
–  Describen lo que el sistema trata de hacer –  De desempeño
•  “Para cualquier viga, el analizador de tensión debe producir
–  Especifican los servicios que debe proporcionar la un informe del tipo 5 en menos de un minuto”
aplicación –  Confiabilidad y disponibilidad
–  Ej: “La aplicación debe calcular el valor del portafolio •  “La aplicación del radar del aeropuerto debe experimentar no
de inversión del usuario” más de dos fallas de nivel uno por mes”
–  No es un req. funcional: “La aplicación debe terminar –  Manejo de errores
el cálculo del valor de cada portafolio en menos de un –  Requerimientos de interfaz
segundo” –  Restricciones
•  No especifica un servicio dado “Los cálculos de daños deben tener una exactitud de un
centímetro”
•  Califica un servicio o servicios (especifica algo sobre ellos)