INGENIERÍA DE REQUISITOS

Definición

IEEE
 Proceso de estudio de las necesidades

de los usuarios con el objeto de llegar a

una definición del sistema hw/sw.
 Definición de requisito
IEEE
Condición o aptitud necesaria para resolver un
problema o alcanzar un objetivo.
Condición o facilidad que debe proporcionar un
sistema o algunos de sus subsistemas para
satisfacer un contrato, norma, especificación o
cualquier otra condición impuesta
formalmente a través de un documento.
 Tipos de requisitos

Funcionales
Describen los servicios o funciones del
sistema.
No funcionales
Describen las restricciones del sistema o del
proceso de desarrollo: Niveles de servicio,
interfaz, atributos de calidad, etc. En
general, los requisitos no funcionales son más
difíciles de cuantificar.
 Levantamiento de Requisitos
 Definición de requisitos
Expresa en lenguaje natural o con diagramas los servicios
y restricciones operacionales del sistema. Se genera con
la información proporcionada por el cliente.
 Especificación de Requisitos
Documento estructurado que describe con detalle los
servicios del sistema. A veces llamado especificación
funcional. Escrito como contrato con el cliente.
 Especificación de software
Escrito para los diseñadores. Sirve de base para el diseño
y desarrollo del sistema.
 Un poco de historia
Tradicionalmente entendida como una parte
borrosa del ciclo de vida software, en la que se
obtiene una especificación formal de unas ideas
informales. Desde mediados de los 70’s cobra una
especial importancia. Hoy es considerada una
etapa clave en el desarrollo software.
La satisfacción de los clientes se considera la
mejor métrica de la calidad de un sistema.
 REALIDAD
 Boehm afirma que sólo entre un 9% y un 12% de la
duración de un proyecto se invierte en la IR.
Otro estudio más reciente (1996) confirma estos datos:
 Entre el 5% y el 15% de los costos de un proyecto se

dedican a la IR.
 El 15% de la duración del proyecto se emplea en IR.

 Estos porcentajes parecen sorprendentes si se piensa

que los errores más numerosos, más costosos de

reparar y que más tiempo consumen se deben a esta
fase.
 REALIDAD
Los errores en esta fase son los más numerosos:
 Boehm afirma que el 10% de los errores se producen
en IR.
 Estudios más recientes afirman que entre el 44% y el
80% de los errores proceden de IR.
 El coste crece exponencialmente con el retraso en
subsanarlo (efecto bola de nieve):
 Boehm afirma que la reparación de un error en la fase
de codificación cuesta entre 5 y 10 veces más.
 En la fase de mantenimiento cuesta entre 100 y 200
veces más.
 Mejorar esta fase puede reportar grandes beneficios.
PROCESO DE INGENIERÍA DE
REQUISITOS
 Análisis de requisitos.
 Identificación de los requisitos del sistema a partir
de otros sistemas similares, de discusiones con
usuarios, etc.
 Puede suponer la definición de varios modelos.
 Ayuda al analista a entender el sistema.
 Puede ser necesario desarrollar prototipos.
PROCESO DE INGENIERÍA DE
REQUISITOS
Definición de requisitos:
 Es el proceso de plasmar en un documento la

información obtenida en la fase de análisis.

Especificación de requisitos.
 Descripción detallada y precisa de los requisitos del

sistema.
 Deber servir de base para la elaboración de un

CONTRATO entre el cliente y el equipo de

desarrollo.
 Documento de Requisitos
 Establece lo que se espera del sistema.
 Debe incluir tanto la definición como la especificación
de requisitos.
 NO es un documento de diseño. Debe establecer QUÉ
hace el sistema, pero no CÓMO.
 Los requisitos deben establecerse de forma que sea
posible su seguimiento en el sistema final.
 Los requisitos deben ser completos y consistentes.
 Documento de Requisitos
Características de un documento de requisitos
 Debe especificar sólo el comportamiento externo

del sistema.
 Debe especificar las restricciones de
implementación.
 Debe servir como referencia para las tareas de

mantenimiento.
 Debe reflejar consideraciones sobre el ciclo de

vida.
 Debe contener respuestas aceptables a eventos no

deseados.
Documento de Requisitos
Posible Contenido
Introducción
Glosario
Modelos del sistema
Requisitos funcionales
Requisitos no-funcionales
Evolución
Anexos
 VALIDACIÓN
¿EEstamos construyendo el sistema que espera el
cliente?.
 La validación de requisitos tiene como misión

demostrar que la definición de requisitos define el

sistema que quiere el usuario.
 Si no se realiza una adecuada validación los errores

se propagarán a las fases siguientes.

 El coste de depuración de un error en esta fase es

muy alto.
 El prototipado es una técnica muy útil para validar

requisitos.
 VALIDACIÓN
AAspectos de la validación

Validez.
 Los grandes sistemas tienen diferentes usuarios

con lo que un documento de requisitos es

necesariamente una decisión de compromiso.

Consistencia.
 Los requisitos no deben ser contradictorios.
 VALIDACIÓN

Completitud.
 La definición contiene todas las funciones y

restricciones.

Realismo.
 No contiene requisitos inalcanzables.
 REVISIÓN DE REQUISITOS

Aspectos a revisar
 Comprensibilidad

 Verificabilidad

 Trazabilidad

 Adaptabilidad
 Conclusiones
 Los requisitos contienen demasiados errores
 Muchos de estos errores no se detectan al principio.
 Muchos de estos errores podrían ser detectados al
principio.
 No detectar estos errores incrementará los costes
(tiempo, dinero) de forma exponencial
 Recuerde siempre el efecto bola de nieve
 Los requisitos son un CONTRATO
 La satisfacción de los clientes se considera la mejor
métrica de la calidad de un sistema.
 Si un analista hace exactamente lo que el cliente le
indica y el sistema no satisface realmente las
necesidades con toda seguridad NO es responsabilidad
del cliente
 SOFTWARE PARA LA ELICITACIÓN
DE REQUISITOS

http://www.infor.uva.es/~mlaguna/cd/mat.html