PDF de programación - Tema 03 - Ingeniería de Requisitos - Ingeniería del Software

Tema 03 –

Ingeniería de requisitos

Ingeniería del Software

Rubén Fuentes Fernández

Dep. Ingeniería del Software e Inteligencia Artificial

Facultad de Informática

Universidad Complutense Madrid

Trabajando con Antonio Navarro, Juan Pavón y Pablo Gervás

Contenidos

Introducción

•
• Tipología de requisitos
• El proceso de Ingeniería de Requisitos

– Casos de uso
– FAST
IEEE Std. 830‐1998

•

Rubén Fuentes Fernández

Ingeniería del Software

2

Objetivos

• Entender las dificultades de capturar las necesidades del 

cliente

• Determinar qué aspectos clave hay que capturar en los 

requisitos

• Proporcionar pautas para el proceso de captura
• Examinar guías de documentación de requisitos

Rubén Fuentes Fernández

Ingeniería del Software

3

INTRODUCCIÓN

Rubén Fuentes Fernández

Ingeniería del Software

4

El contexto del sistema

• Entender la naturaleza de un problema es por lo general algo 

difícil.
– Implica una interacción entre el grupo desarrollador y el contratante.
– Estos grupos tienen diferentes perspectivas, y una idea imprecisa de 

qué información es relevante y cómo transmitirla.

• Un interesado (stakeholder) es cualquier persona que puede 

tener influencia directa o indirecta sobre los requisitos:
– Clientes  quien contrata o representa a la organización
– Usuarios  quien utilizará el sistema
– Otros  ej. expertos externos

Rubén Fuentes Fernández

Ingeniería del Software

5

Dificultades en la captura de requisitos

• Un sistema tiene muchos usuarios y ninguno tiene una visión de 

conjunto.

Influencia de factores políticos.

• Distintos interesados pueden tener distintos requisitos.
•
• Entorno de negocio dinámico del sistema informático. 
•

•

•

Los clientes no saben qué partes del trabajo pueden transformarse 
en software.
Los interesados pueden desconocer lo que esperan del sistema 
informático.
Los interesados no saben cómo hacer más eficiente la operación en 
su conjunto.
Los interesados no saben detallar lo que saben de forma precisa.

•
• Es posible que los ingenieros de requisitos no conozcan el dominio 

del sistema, familiar para los interesados.

Rubén Fuentes Fernández

Ingeniería del Software

6

Requisitos

• Los requisitos son una descripción de los servicios y 

restricciones del sistema a construir.

• La Ingeniería de Requisitos es el proceso que permite 

identificar dichos requisitos.
– Sistemáticamente
– De una forma apropiada para el proceso de desarrollo

• Discusión con el cliente
• Punto de partida del resto de fases

Rubén Fuentes Fernández

Ingeniería del Software

7

Tipos de requisitos

• Requisitos de usuario

– Describen los servicios que el sistema debe proporcionar y las 

restricciones bajo las que debe operar.

– Ej. el sistema debe hacer préstamos

• Requisitos de sistema

– Determinan los servicios del sistema y las restricciones en detalle.
– Sirven como contrato.
– Pueden ser funcionales, no funcionales y de dominio.
– Ej. función préstamo; entrada: código socio, código ejemplar; salida: 

fecha devolución; ...

• Son los mismos, pero a distinto nivel de detalle.

– Ambos se describen con lenguaje natural, diagramas y otros recursos.

Rubén Fuentes Fernández

Ingeniería del Software

8

Requisitos funcionales vs no funcionales

• Los requisitos funcionales describen:

– Los servicios que proporciona el sistema (funciones).
– La respuesta del sistema ante determinadas entradas.
– El comportamiento del sistema en situaciones particulares.
– En algunos casos, también determinan lo que no debería hacer el 

sistema.

• Los requisitos no funcionales describen:

– Restricciones de los servicios o funciones que ofrece el sistema.

Rubén Fuentes Fernández

Ingeniería del Software

9

Requisitos – función préstamo

•

•

Requisitos funcionales
– prioridad: alta
– descripción: presta un ejemplar a un socio de la biblioteca
– entrada: código socio, código ejemplar
– origen: operador, consola
– necesita: base de datos de socios y ejemplares
– acción: prestar ejemplar
– precondición: usuario y ejemplar dados de alta, usuario sin préstamos pendientes, 

– salida: fecha devolución
– destino: sistema

– estabilidad: alta

usuario sin límite de préstamos alcanzado

– postcondición: ejemplar prestado al usuario
– efectos laterales: retirada del carné durante 7 días si el usuario tiene préstamos 

pendientes de devolución

Requisitos no funcionales
– El tiempo de proceso de una petición será siempre inferior a 1 segundo.
– El sistema de biblioteca debe ser capaz de atender simultáneamente a todas las 

bibliotecas de la universidad, estimadas en picos de 50 peticiones/minuto

Rubén Fuentes Fernández

Ingeniería del Software

10

Requisitos no funcionales: tipos

• Requisitos del producto

– Especifican el comportamiento del producto.
– Ej. prestaciones, memoria o tasa de fallos

• Requisitos organizativos

– Se derivan de las políticas y procedimientos de las organizaciones de 

los clientes y desarrolladores.

– Ej. estándares de proceso o lenguajes de programación

• Requisitos externos

– Se derivan de factores externos al sistema y al proceso de desarrollo.
– Ej. requisitos legislativos o éticos

Rubén Fuentes Fernández

Ingeniería del Software

11

Requisitos del dominio

• Se derivan del dominio de la aplicación y reflejan 

características de dicho dominio.
– Pueden ser funcionales o no funcionales.
– Ej. el sistema de biblioteca de la universidad debe ser capaz de 
exportar datos mediante el Lenguaje de Intercomunicación de 
Bibliotecas de España (LIBE)

– Ej. el sistema de biblioteca no podrá acceder a bibliotecas con material 

censurado

Rubén Fuentes Fernández

Ingeniería del Software

12

PROCESO

Rubén Fuentes Fernández

Ingeniería del Software

13

El proceso de Ingeniería de Requisitos

• La Ingeniería de Requisitos debe centrarse en lo que hay que 

hacer, no en el cómo.

• Para obtener los requisitos es necesario realizar varias tareas.
• También hay que tener en cuenta que los requisitos 

evolucionan.
– Es necesario gestionar su cambio.

• Las actividades anteriores se organizan siguiendo modelos de 

proceso.
– De la misma manera que el proceso de desarrollo de software global.
– Aunque existen variantes de este modelo, vienen a cubrir las mismas 

actividades.

Rubén Fuentes Fernández

Ingeniería del Software

14

Proceso estilo cascada

Estudio de
viabilidad

Obtención y análisis

de requisitos

Informe de
viabilidad

Especificación de

requisitos

Requisitos

Validación de

requisitos

Requisitos
especificados

Requisitos validados

Rubén Fuentes Fernández

Ingeniería del Software

15

Proceso estilo evolutivo

Pese a las figuras,
se debe usar
“requisitos” en
vez de
“requerimientos”.

Rubén Fuentes Fernández

Ingeniería del Software

16

Fases: estudio de viabilidad

• Se trata de una estimación sobre si se puede resolver el 

problema cumpliendo las restricciones establecidas:
– Usando las tecnologías software y hardware disponibles.
– Integrándose en el entorno tecnológico y organizativo.
– Cumpliendo las restricciones económicas del desarrollo.
– Creando un sistema rentable en cuanto a operación y mantenimiento.
• Se origina tras una especificación preliminar de los requisitos.
• El estudio debe responder a las preguntas:

– ¿Contribuye el sistema a los objetivos generales de la organización?
– ¿Se puede implementar el sistema utilizando la tecnología actual y 

dentro de las restricciones de coste y tiempo?

– ¿Puede integrarse el sistema con otros sistemas existentes en la 

organización?

Rubén Fuentes Fernández

Ingeniería del Software

17

Fases: análisis de requisitos

• Proceso en el que se interactúa con los interesados para 

determinar:
– El dominio de la aplicación
– Los requisitos funcionales
– Los requisitos no funcionales

Rubén Fuentes Fernández

Ingeniería del Software

18

Análisis de requisitos: proceso

2º

1º

3º

4º

Rubén Fuentes Fernández

Ingeniería del Software

19

Fases: especificación de requisitos

• Se fija una descripción detallada y precisa de los requisitos.

– Debe servir de base para un contrato entre los clientes y los 

desarrolladores de software.

• En función del ciclo, los requisitos serán preliminares del 

negocio, de usuario o de sistema.
– Dentro de un proceso evolutivo o incremental

• El objetivo es realizar la Especificación de Requisitos Software 

(SRS).

Rubén Fuentes Fernández

Ingeniería del Software

20

Lenguajes de especificación de requisitos

• Pueden utilizarse distintos lenguajes para especificar los 

requisitos:
– Lenguaje natural
– Lenguaje natural estructurado
– Lenguaje de descripción de diseño
– Lenguaje de especificación de requisitos
– Notaciones gráficas
– Especificaciones matemáticas
– Especificaciones lógicas

Rubén Fuentes Fernández

Ingeniería del Software

21

Fases: validación de requisitos

• Se encarga de comprobar si los requisitos se ajustan a los 

deseos y necesidades de los interesados.

• Si la validación es inadecuada, se propagarán errores al diseño 

e implementación.

• Evidentemente, tiene una fuerte repercusión sobre el coste.

Rubén Fuentes Fernández

Ingeniería del Software

22

Verificaciones en la validación de requisitos 
(1/2)
• Corrección

– Cada requisito identificado es un requisito del sistema.

– Cada requisito identificado tiene una única interpretación.

– Comprobar que se pueden implementar los requisitos con las tecnologías 

• No ambigüedad

• Realismo

y plantilla disponibles.

• Completitud

– La SRS debe incluir:

• Todos los requisitos relativos a funcionalidad, prestaciones, restricciones de 

diseño, atributos o interfaces externas.

• Definición de las respuestas del sistema a todos los tipos posibles de datos de 

entrada en todas las posibles situaciones.

• Todas las etiquetas y referencias a todas las figuras, tablas y diagramas en la 

SRS, así como definiciones de todos los términos y unidades de medida.

Rubén Fuentes Fernández

Ingeniería del Software

23

Verificaciones en la validación de requ